Re: Summary of Camerfirma's Compliance Issues

[Filippo Valsorda via dev-security-policy]

2021-01-19 18:01 GMT+01:00 Andrew Ayer via dev-security-policy 
:
> It's troubling that even at this stage, Camerfirma still doesn't seem
> to grasp the seriousness of their compliance problems. Today,
> they are arguing that there was no security threat from a certificate
> issued for a domain without authorization because the subdomain
> in the certificate "does not exist": 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1672409#c8

In my personal capacity, I want to stress how worrying this response by 
Camerafirma is. Arguing that a certificate doesn't present any risk if it's 
issued for a name that doesn't exist in DNS betrays a deep misunderstanding of 
the web platform, which the WebPKI serves. (For example, an attacker in a 
privileged network position can fake a DNS response for that domain, and use it 
to set Secure cookies on the whole site.)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Filippo Valsorda via dev-security-policy]

2020-07-15 12:30 GMT-04:00 Chema López via dev-security-policy 
:
> El martes, 14 de julio de 2020 a las 9:02:01 UTC+2, Filippo Valsorda escribió:
> 
> 
> > This whole argument seems to lose track of the difference between CAs and 
> > RPs. CAs have strict responsibilities to follow all the rules of the 
> > policies they committed to in order to be trusted by RPs. Full stop. There 
> > is no blaming RPs for a CA's failure to follow those rules. RPs, 
> > themselves, only have a responsibility to their users—not to the CAs—and 
> > uphold it as they see fit. 
> > 
> 
> I utterly agree with you at this point, Filippo. Especially when you state 
> that "RPs, themselves, only have a responsibility to their users—not to the 
> CAs—and uphold it as they see fit. ". If the RP does not check what they 
> shall to be sure if a specific item is trustworthy, it is up to them and 
> their clients. But, again,  if the RP does not check what they shall to be 
> sure if a specific item is trustworthy, it is not CA's fault. Do we agree on 
> that?

What the RPs do have little direct bearing on the CAs responsibilities, yes. 
(Indirectly, RPs forge policies that allow them to operate safely.) The CAs 
have to follow the policies regardless of whether the RPs are behaving 
correctly or not, and regardless of whether it impacts the RPs or not. RPs are 
also allowed to rely on all and any parts of the policies, because CAs are 
supposed to follow them all.

It seems we agree on that, but disagree on the interpretation of the rules, so 
I'll skip ahead.

> > RPs trust the CAs to do exactly what they say in the policies, not to do 
> > something that is sort of the same as long as the RPs follow the 
> > specification correctly. That's not the deal. We trust the CAs only because 
> > and as long as they show they can precisely follow those policies.
> 
> And, in general, CAs show that they can precisely follow those policies. 
> 
> For example, let's see the beginning of this thread: 
> - "Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST 
> include an id-pkix-ocsp-nocheck extension."
> - but BR also state:  Section  7.1.2.2. Subordinate CA Certificate   " e. 
> keyUsage This extension MUST be present and MUST be marked critical. Bit 
> positions for keyCertSign and cRLSign MUST be set. If the Subordinate CA 
> Private Key is used for signing OCSP responses, then the digitalSignature bit 
> MUST be set. ". This section is align with RFC5280 and RFC6960
> 
> So, an ICA or SCA cert. without keyUsage set to digitalSignature is not an 
> OCSP Responder. Full stop. We can agree that this would be kind of a weird 
> certificate, but it is not a valid OCSP responder certificate and RPs 
> shouldn't trust their responses.

I implement and sometimes write RFCs as a day job, and this interpretation of 
"MUST" is new to me.

Let me pull up an RFC I am familiar with, for example RFC 8446. Section 4.1.4. 
Hello Retry Request states:

> The server's extensions MUST contain "supported_versions".

By your interpretation if a TLS client receives a Hello Retry Request message 
that does not contain a "supported_versions" extension, then it's not an HRR 
message, the client should not consider it a HRR message, and... ignore it? All 
of the other rules that apply to HRR messages don't apply anymore?

This is such a mismatch in the understanding of how policies _work_ between you 
and most* *(as Ryan pointed out) RPs that I don't think it matters who's right. 
If we are not on the same page on how to fundamentally read the rules, there is 
no way to communicate and trust each other. Needless to say, that's _a problem_ 
and RPs don't have a lot of pleasant ways to fix it.

(Because of course, RPs owe it to their users to only trust CAs they can 
effectively communicate with, so that they can agree on a set of mutually 
understood policies they can trust the CAs to follow, in order to protect the 
users. When there's a mismatch, incidents like this happen.)

We can discuss here what "MUST" means in our personal capacities, but when 
speaking in your professional capacity, my personal advice is to acknowledge 
how RPs interpret the language in the policies and try to demonstrate you can 
understand and abide by that. Anything else is unworkable, I'm afraid.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Filippo Valsorda via dev-security-policy]

2020-07-13 13:39 GMT-04:00 Chema Lopez via dev-security-policy 
:
> From my point of view, the arguments at
> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13642.html
> are
> as incontestable as the ones stated by Corey Bonnell here:
> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13541.html
> .
> 
> 
> RFC5280 and RFC6960 have to be considered and thus, a certificate without
> KU digitalSignature is not an OCSP Responder. We can not choose what to
> comply with or what is mandatory or if a RFC is mandatory but BR "profiles"
> the RFC. And when I say "we" I mean all the players, especially the ones in
> the CA / Browser forum.
> 
> 
> And yes, relying parties need to check this. For its own benefit, relying
> parties need to understand how a proper OCSP response is made and check it
> properly.
> 
> 
> It is astonishing how what looks like a bad practice of (some) relying
> parties has mutated into a security risk at CAs side.

This whole argument seems to lose track of the difference between CAs and RPs. 
CAs have strict responsibilities to follow all the rules of the policies they 
committed to in order to be trusted by RPs. Full stop. There is no blaming RPs 
for a CA's failure to follow those rules. RPs, themselves, only have a 
responsibility to their users—not to the CAs—and uphold it as they see fit.

RPs trust the CAs to do exactly what they say in the policies, not to do 
something that is sort of the same as long as the RPs follow the specification 
correctly. That's not the deal. We trust the CAs only because and as long as 
they show they can precisely follow those policies. "No, you see, it's actually 
your fault" is the least trustworthy reaction I can possibly imagine to being 
caught not following the policy.

As an outsider (because again I speak in my personal capacity, and at most I 
work on a non-browser RP, Go's crypto/x509) it's puzzling to see the CA/Browser 
forum regularly lose track of the different roles of the participants.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Filippo Valsorda via dev-security-policy]

2020-07-11 13:17 GMT-04:00 Oscar Conesa via dev-security-policy 
:
> f) For CAs that DO have sole control of the keys: There is no reason to 
> doubt the CA's ability to continue to maintain the security of these 
> keys, so the CA could reuse the keys by reissuing the certificate with 
> the same keys. If there are doubts about the ability of a CA to protect 
> its own critical keys, that CA cannot be considered "trusted" in any way.

In this section, you argue that we (the relying party ecosystem, I am speaking 
in my personal capacity) should not worry about the existence of unrevokable 
ICAs with long expiration dates, because we can trust CAs to operate them 
safely.

> g) On the other hand, if the affected certificate (with EKU OCSPSigning) 
> does not have the KU Digital Signature, then that certificate cannot 
> generate valid OCSP responses according to the standard. This situation 
> has two consequences: (i) the CA cannot generate OCSP responses by 
> mistake using this certificate, since its own software prevents it, and 
> (ii) in the event that an attacker compromises the keys and uses 
> modified software to generate malicious OCSP responses, it will be also 
> necessary that the client software had a bug that validated these 
> malicious and malformed OCSP responses. In this case, the hypothetical 
> scenarios involving security risks are even more limited.

In this section, you argue that we can't trust CAs to apply the 
id-kp-OCSPSigning EKU correctly and it's then our responsibility to check the 
rest of the profile for consistency.

These two arguments seem at odds to me.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Filippo Valsorda via dev-security-policy]

2020-07-02 10:40 GMT-04:00 Ryan Sleevi via dev-security-policy 
:
> On Thu, Jul 2, 2020 at 10:34 AM Paul van Brouwershaven via
> dev-security-policy  wrote:
> 
> > I did do some testing on EKU chaining in Go, but from my understand this
> > works the same for Microsoft:
> >
> 
> Go has a bug https://twitter.com/FiloSottile/status/1278501854306095104

Yep. In fact, Go simply doesn't have an OCSP verifier. We should fix that! I 
filed an issue: https://golang.org/issues/40017 


The pieces are there (OCSP request serialization and response parsing, 
signature verification, a chain builder) but the logic stringing them together 
is not. That includes building the chain without requesting the EKU up the 
path, and then checking the EKU only on the Responder itself.

It's unfortunate that the Mozilla requirement (that the Responder must be an 
EE) is not standard, because that would have allowed the OCSP EKU to work like 
any other, nested up the chain, but that's just not how it works and it's too 
late to change, so it has to be special-cased out of the chain nesting 
requirement, or it wouldn't be possible to mint an Intermediate that can in 
turn mint Responders, without making the Intermediate a Responder itself.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Filippo Valsorda via dev-security-policy]

I am also personally surprised and confused by this announcement.

I could imagine of course incident reports being handled with more
leniency when the details reveal that the health emergency contributed
to the issue. I thought that was the point of the no exceptions policy,
to push the CAs to handle the situation as well as possible, and force a
learning process out in the open.

With an opaque exception, the ecosystem is not learning anything about
the circumstances that put the CAs in this situation, and about the
challenges imposed by something that might be a long-term emergency,
giving no opportunity or incentive to improve and avoid similar issues
in the future.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy