"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"... +
I understood finally: + ... regardless to the fact, that the affected CA cannot issue OCSP responses in BRG-compliant manner. Thanks! Peter On Thu, Jul 2, 2020 at 2:10 PM Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
