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
