Thanks Tim. It’s deeply reassuring to see DigiCert tackling this problem responsibly and head-on.
And thank you for particularly calling attention to the fact that blindly adding id-pkix-ocsp-nocheck to these ICAs introduces worse security problems. This is why RFC 6960 warns so specifically on this. What does a robust design look like? - Omit the EKU for ICAs. You can work around the ADCS issue using Sectigo’s guidance. - For your actual delegated responders, omitting OCSP URLs can help “some” clients, but not all. A sensible minimum profile is: - basicConstraints:CA=FALSE - extKeyUsage=id-kp-OCSPSigning (and ONLY that) - validity period of 90 days or less (30?) - id-pkix-ocsp-nocheck basicConstraints is to guarantee it works with Firefox. EKU so it’s a delegated responder (and only that). Short lived because nocheck means it’s high risk. Invariably, any profile (e.g. in the CABForum) would also need to ensure that these keys are protected to the same assurance level as CA keys, because of the similar function they pose. I had previously proposed both the lifetime and protection requirements in CABF, but met significant opposition. This still lives in https://github.com/sleevi/cabforum-docs/pull/2/files , although several of these changes have found their way in through other ballots, such as SC31 in the SCWG if the CABF. On Thu, Jul 2, 2020 at 6:37 PM Tim Hollebeek <tim.holleb...@digicert.com> wrote: > So, from our perspective, the security implications are the most important > here. > We understand them, and even in the absence of any compliance obligations > they > would constitute an unacceptable risk to trustworthiness of our OCSP > responses, > so we have already begun the process of replacing the ICAs we are > responsible for. > There are already several key ceremonies scheduled and they will continue > through > the holiday weekend. We're prioritizing the ICAs that are under the > control of third > parties and/or outside our primary data centers, as they pose the most > risk. We are > actively working to mitigate internal ICAs as well. Expect to see > revocations start > happening within the next day or two. > > I understand the attraction of using a BR compliance issue to attract > attention to > this issue, but honestly, that shouldn't be necessary. The BRs don't > really adequately > address the risks of the OCSPSigning EKU, and there's certainly lots of > room for > improvement there. I think, especially in the short term, it is more > important to > focus on how to mitigate the security risks and remove the inappropriate > EKU from > the affected ICAs. We can fix the BRs later. > > It's also important to note that, much like SHA-1, this issue doesn't > respect the > normal assumptions about certificate hierarchies. Non-TLS ICAs can have a > significant > impact on their TLS-enabled siblings. This means that CA review needs to > extend > beyond the certificates that would traditionally be in scope for the BRs. > > I would also caution CAs to carefully analyze the implications before > blindly adding the > pkix-ocsp-nocheck extension to their ICAs. That might fix the compliance > issue, > but in the grand scheme of things probably makes the problem worse, as ICAs > have fairly long lifetimes, and doing so effectively makes the inadvertent > delegated > responder certificate unrevokable. So while the compliance problems might > be > fixed, it makes resolving the security issues much more challenging. > > -Tim > > > -----Original Message----- > > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org > > > > On Behalf Of Ryan Sleevi via dev-security-policy > > Sent: Thursday, July 2, 2020 12:31 AM > > To: Peter Gutmann <pgut...@cs.auckland.ac.nz> > > Cc: r...@sleevi.com; Mozilla <mozilla-dev-security- > > pol...@lists.mozilla.org> > > Subject: Re: SECURITY RELEVANT FOR CAs: The curious case of the > > Dangerous Delegated Responder Cert > > > > On Wed, Jul 1, 2020 at 11:48 PM Peter Gutmann > > <pgut...@cs.auckland.ac.nz> > > wrote: > > > > > Ryan Sleevi via dev-security-policy > > > <dev-security-policy@lists.mozilla.org> > > > writes: > > > > > > >Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST > > > include > > > >an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP Delegated > > > >Responder within Section 4.2.2.2 as indicated by the presence of the > > > id-kp- > > > >OCSPSigning as an EKU. > > > > > > Unless I've misread your message, the problem isn't the presence or > > > not of a nocheck extension but the invalid presence of an OCSP EKU: > > > > > > >I've flagged this as a SECURITY matter [...] the Issuing CA has > > > >delegated > > > the > > > >ability to mint arbitrary OCSP responses to this third-party > > > > > > So the problem would be the presence of the OCSP EKU when it shouldn't > > > be there, not the absence of the nocheck extension. > > > > > > Not quite. It’s both. > > > > The BR violation is caused by the lack of the extension. > > > > The security issue is caused by the presence of the EKU. > > > > However, since some CAs only view things through the lens of BR/program > > violations, despite the sizable security risk they pose, the compliance > incident > > is what is tracked. The fact that it’s security relevant is provided so > that CAs > > understand that revocation is necessary, and that it’s also not > sufficient, > > because of how dangerous the issue is. > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
