Sorry, my message was incomplete... please read the las part as: Can you please clarify why this is not correct and what is the security problem it creates if the CA is not operated externally?
El jueves, 2 de julio de 2020, 8:19:34 (UTC+2), Pedro Fuentes escribió: > 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
