Ryan, I have read through this thread and am also somewhat perplexed.
I want to be clear, I'm posting only for myself, as an individual, not on behalf of any current or former employers. On Fri, Jul 3, 2020 at 4:26 AM Ryan Sleevi via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > On Fri, Jul 3, 2020 at 3:24 AM Pedro Fuentes via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > > > > > > Yes. But that doesn't mean we blindly trust the CA in doing so. And that's > > > the "security risk". > > > > But the point then is that a delegated responder that had the required > > "noCheck" extension wouldn't be affected by this issue and CAs wouldn't > > need to react, and therefore the issue to solve is the "mis-issuance" > > itself due to the lack of the extension, not the fact that the CA > > certificate could be used to do delegated responses for the same operator > > of the Root, which is acceptable, as you said. > > > I don’t understand why this is difficult to understand. If you have the > noCheck extension, then as RFC 6960, you need to make that certificate > short lived. The BRs require the cert have the extension. I think this is difficult to understand because you are adding requirements that don't currently exist. There is nothing in the BRs or other obligations of the CA to make a delegated OCSP responder certificate short-lived. From 6960: "CAs may choose to issue this type of certificate with a very short lifetime and renew it frequently." 6960 explicitly says "may" is defined in RFC 2119, which says: "MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional." Contrast with "should" which is "This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." While it may be viewed as best practice to have short lived responder certificates, it must not be viewed as a hard requirement for the BRs or for the Mozilla program. As you have pointed out previously, a browser could make this a requirement, but I am unaware of any publicly available requirement ot do so. > Similarly, if something goes wrong with such a responder, you also have to > consider revoking the root, because it as-bad-as a root key compromise. I think we can all agree to this point. > In fact the side effect is that delegated responders operated externally > > that have the required no check extension don't seem to be affected by the > > issue and would be deemed acceptable, without requiring further action to > > CAs, while the evident risk problem is still there. > > > The “nocheck” discussion extension here is to highlight the compliance > issue. > > The underlying issue is a security issue: things capable of providing OCSP > responses that shouldn’t be. > > It seems you understand the security issue when viewing external sub-CAs: > they can now impact the security of the issuer. > > It seems we’re at an impasse for understanding the issue for > internally-operates Sub CAs: this breaks all of the auditable controls and > assurance frameworks, and breaks the security goals of a “correctly” > configured delegated responder, as discussed in the security considerations > throughout RFC 6960. This is where I disagree. Currently CAs can create as many delegated OCSP responder certificates as they like with as many distinct keys as they like. There are no public requirements from any browser on the protection of OCSP responder keys, as far as I know. The few requirements on revocation information are to provide accurate information and provide the information within 10 seconds "under normal operating conditions" (no SLO if the CA determines it is not operating under normal conditions). For the certificates you identified in the beginning of this thread, we know they have a certain level of key protection - they are all required to be managed using cryptographic modules that are validated as meeting overall Level 3 requirements in FIPS 140. We also know that there CAs are monitoring these keys as they have an obligation in BR 6.2.6 to "revoke all certificates that include the Public Key corresponding to the communicated Private Key" if the "Subordinate CA’s Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subordinate CA". I agree with Pedro here. If the CA has control over the keys in the certificates in question, then I do not see that there is a risk that is greater than already exists. The CA can determine that these are approved OCSP responders and easily assess whether they have controls in place since the creation of the certificate that provide assurance that all OCSP responses signed using the key were accurate (if any such responses exist). They can also easily validate that they have controls around these keys to provide assurance that any future OCSP responses signed using the key will be accurate, the same that they presumably do for their other OCSP responders. So, from my personal view, what needs to happen here is that each CA needs to acknowledge each of the keys in the certificats as a valid OCSP responder key, according to their internal procedures for such, if they have not already done so. Then they need to revoke the certificates and issue new certificates with different serial numbers that do not have the OCSP EKU to correct the certificate profile issue. While not required, they should also consider having controls in place for the lifetime of the key (until destruction) to provide assurance that any OCSP responses it signs are accurate, as we know some certificate status consumers may not check the validity of the response signer certificate. This situation does suggest that root programs should consider adding public requirements around: 1) Delegation of OCSP response generation to third parties 2) Maximum validity period of OCSP responder certificates 3) Use of CA private keys, specifically requirements for data they sign I also will not that any CA that determines that a key that has been included a certificate usable for OCSP response signing but that key is not authorized for OCSP response generation should immediately ensure destruction of that key and should document their consideration to revoke the CA that issued such certificate so their auditor can verify that they considered the risks of doing so. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
