Threatening distrust over a discussion about applicability of requirements seems contrary to Mozilla's open discussion policy, and I don't think that should be an answer while there are still open questions about the language in 4.9.9. Separating out the security risk from the applicability of the BRs is useful because it highlights potentially poor language in the BRs. For example:
Section 4.9.9: OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either: 1. Be signed by the CA that issued the Certificates whose revocation status is being checked, or 2. Be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked. In the latter case, the OCSP signing Certificate MUST contain an extension of type id-pkix-ocsp-nocheck, as defined by RFC6960 The requirement for no-check only applies in the latter case, which is if the OCSP response is signed by an OCSP responder. How would the no-check requirement apply if no OCSP responses are being signed by the responder. If the ICAs aren't signing, why does it apply? Should the OCSP issue be fixed? Definitely. The security issues are apparent. Should the BR language be modified for clarity? I think that conversation is still ongoing and shutting that down with threats of distrust is counter productive. -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Ryan Sleevi via dev-security-policy Sent: Thursday, July 2, 2020 11:05 AM To: Rob Stradling <r...@sectigo.com> Cc: Mozilla <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs On Thu, Jul 2, 2020 at 12:51 PM Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 02/07/2020 17:13, Ryan Sleevi via dev-security-policy wrote: > > On Thu, Jul 2, 2020 at 11:36 AM Corey Bonnell wrote: > <snip> > >> If there’s no digitalSignature KU, then the certificate is not a > >> OCSP responder certificate due to the technical inability to sign > >> OCSP > responses > >> that would be accepted by clients conforming to RFC 5280, section > 4.2.1.12. > >> Therefore, section 4.9.9 is not applicable for those certificates > >> that > not > >> express the digitalSignature KU. This is directly relevant to the > >> topic > at > >> hand. > > > > Alternatively: If the OCSPSigning EKU is present, and it lacks > > DigitalSignature, it's misissued by containing an invalidEKU. > > As Ryan already mentioned, RFC6960 very clearly says: > "OCSP signing delegation SHALL be designated by the inclusion of > id-kp-OCSPSigning in an extended key usage certificate extension > included in the OCSP response signer's certificate." > > The presence or absence of the DigitalSignature Key Usage bit does not > alter this fact. > > RFC6960 doesn't mention the Key Usage extension at all, AFAICT. > > https://tools.ietf.org/html/rfc5280#section-4.2.1.12 doesn't use any > RFC2119 keywords when it says: > "id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } > -- Signing OCSP responses > -- Key usage bits that may be consistent: digitalSignature > -- and/or nonRepudiation" > > The BRs say... > "If the Root CA Private Key is used for signing OCSP responses, then > the digitalSignature bit MUST be set." > and > "If the Subordinate CA Private Key is used for signing OCSP responses, > then the digitalSignature bit MUST be set" > ...but this is obviously intended to refer to OCSP responses signed > directly by the CA (rather than OCSP responses signed by a CA that > also masquerades as a delegated OCSP response signer!) > Even if a CA wanted to argue that there's no 4.9.9 BR violation (which, as I suggested, I would strongly advocate for their distrust, due to the logical consequences of such an argument), the KU violation itself can be argued a Mozilla violation, using the exact language Corey highlighted. Recall Section 5.2 of Mozilla Root Policy 2.7: https://github.com/mozilla/pkipolicy/blob/66ac6b888965aefc88a8015b37d2ee6b5b095fba/rootstore/policy.md#52-forbidden-and-required-practices """ CAs MUST NOT issue certificates that have: ... * incorrect extensions """ While a list of possible incorrect extensions is included, if the argument is that the EKU doesn't matter because the KU is incorrect for that EKU, then it's an argument that the CA has issued a certificate with incorrect extensions. Which is still a Mozilla Root Store Policy violation. _______________________________________________ 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
