Thanks for raising this issue Ryan, I'm trying to update http://revocationcheck.com/ to cover this issue.
From my understanding: The OCSPnocheck extension is only required for a delegated OCSP responder certificate as it can't provide answers for itself. For a CA certificate in (CA signed responses) the OCSPnocheck extension MUST NOT be present as it's not authorized to create a status for itself. A CA certificate MUST NOT include the OCSPsigning EKU, even when using CA signed responses. When using CA signed responses the EKU digitalSignature MUST be set. Delegated OCSP signing certificates MUST only have the OCSPsigning EKU set (Microsoft A12) Delegated OCSP signing certificates MUST be issued directly by the CA that is identified in the request as the issuer of the EE certificate (RFC6960 4.2.2.2) But as Pedro also mentioned, the EKU extension in intermediate certificates acts as a constraint on the permitted EKU OIDs in end-entity certificates, which means you won't be able to use delegated OCSP signing certificates with strict EKU validation on the path? While not every client might have strict validation on this, it would be really confusing if it's required for one EKU and forbidden for the other. On Thu, 2 Jul 2020 at 08:19, Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hello, > Our understanding when creating this SubCA was that the CA certificate > should include the EKUs that would be allowed to issue, and therefore, as > it would generate certificates for the OCSP responders, it should include > such EKU, the same it would include the EKU for clientAuthentication, for > example. > Can you please clarify why this is not correct and what is the security > problem it creates? > Thanks, > Pedro > > El jueves, 2 de julio de 2020, 6:31:16 (UTC+2), Ryan Sleevi escribió: > > 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 > -- Regards, Paul van Brouwershaven http://linkedin.com/in/pvanbrouwershaven http://facebook.com/p.vanbrouwershaven http://twitter.com/vanbroup _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
