Doug, BR 4.9.9 says: "...the OCSP signing Certificate MUST contain an extension of type id-pkix-ocsp-nocheck, as defined by RFC6960."
The certificates that Ryan has identified are OCSP signing Certificates, because they contain the id-kp-OCSPSigning EKU. However, they have been misissued because they don't "contain an extension of type id-pkix-ocsp-nocheck". The fact that these certificates are also CA certificates is unfortunate, because revoking a CA certificate tends to have more impact to users than revoking a leaf certificate. Policy-wise, apparently it's OK for a certificate to be both a CA certificate and a (correctly issued!) delegated OCSP signing certificate, which is I think what Ryan's earlier post was talking about. So if the affected CAs could go back in time and add the id-pkix-ocsp-nocheck extension to these certificates then those certificates arguably wouldn't have been misissued(*). To repeat: the policy violation here is the omission of the id-pkix-ocsp-nocheck extension in certificates that contain the id-kp-OCSPSigning EKU. (*) They might still have been "Dangerous" though, even if they hadn't been misissued. Quoting Ryan... "For example, consider this certificate https://crt.sh/?id=21606064 . It was issued by DigiCert to Microsoft, granting Microsoft the ability to provide OCSP responses for any certificate issued by Digicert's Baltimore CyberTrust Root. We know from DigiCert's disclosures that this is independently operated by Microsoft." ________________________________ From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> on behalf of douglas.beattie--- via dev-security-policy <dev-security-policy@lists.mozilla.org> Sent: 02 July 2020 12:38 To: mozilla-dev-security-pol...@lists.mozilla.org <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Ryan, Given the recent announcement "SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responded Cert", how does you discussion in this thread relate to this? Are your responses here to a different question, because it appears (likely my misinterpretation) from this thread it's OK to include OCSP-signing into a CA certificate? https://groups.google.com/d/msg/mozilla.dev.security.policy/EzjIkNGfVEE/XSfw4tZPBwAJ On Wednesday, September 4, 2019 at 11:01:36 AM UTC-4, Ryan Sleevi wrote: > On Wed, Sep 4, 2019 at 9:47 AM Peter Mate, Erdosi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > My question is the following: is it allowed to issue an OCSP Responder > > certificate with "id-kp-OCSPSigning" EKU from a technically constrained CA > > if the "id-kp-OCSPSigning" EKU is not listed in the CA certificate, > > > This will fail, not because of policy reasons, but because of technical > reasons (not Firefox). > > The code (for Firefox) is > https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#819-888 > , > with the most salient logic at > https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#873-884 > , > although the explanation in > https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#863-869 > explains > the technical reasons. > > > > in other words, is the inclusion of the "id-kp-OCSPSigning" EKU a > > possible, mandatory or forbidden option for such CAs? > > > > This is not forbidden by policy. That is, a technically constrained > subordinate CA certificate can have id-kp-OCSPSigning and id-kp-serverAuth. > > As I see in the practice, if a technically constrained CA signs the OCSP > > response itself, it can be done without the "id-kp-OCSPSigning" EKU but > > with the "digitalSignature" KU bit in the CA certificate. > > > > Correct, if the id-kp-OCSPSigning EKU is missing from the technically > constrained intermediate, direct signing still works. _______________________________________________ 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
