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
  • SECURITY RELEVANT FOR CAs: ... Ryan Sleevi via dev-security-policy
    • Re: SECURITY RELEVANT ... Ryan Sleevi via dev-security-policy
    • Re: SECURITY RELEVANT ... Peter Gutmann via dev-security-policy
      • Re: SECURITY RELEV... Ryan Sleevi via dev-security-policy
        • Re: SECURITY R... Pedro Fuentes via dev-security-policy
          • Re: SECURI... Pedro Fuentes via dev-security-policy
          • Re: SECURI... Paul van Brouwershaven via dev-security-policy
            • Re: S... Pedro Fuentes via dev-security-policy
              • R... Neil Dunbar via dev-security-policy
                • ... Paul van Brouwershaven via dev-security-policy
                • ... Ryan Sleevi via dev-security-policy
                • ... Paul van Brouwershaven via dev-security-policy
                • ... Ryan Sleevi via dev-security-policy
                • ... Paul van Brouwershaven via dev-security-policy
                • ... Paul van Brouwershaven via dev-security-policy

Reply via email to