> No, this isn’t specified/required for Delegated Reaponders (at least, by > 6960), and the client implementations I looked at did not check.
>From RFC 5280, section 4.2.1.12: If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions. … id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } -- Signing OCSP responses -- Key usage bits that may be consistent: digitalSignature -- and/or nonrepudiation If clients aren’t checking for digitalSignature keyUsage when verifying OCSP responses signed by a delegated responder, that seems like a client implementation bug. > RFC 6960 is clear that the EKU indicates a designated responder, and you > can’t “take back” that by suggesting the lack of the KU, as required by 5280, > or the lack of nocheck, as required by the BRs, makes it “not a Responder”. > It just makes it “not a correctly issued responder”. I don’t think it’s that clear-cut, as there’s an impedance mismatch between the use of EKU in CA certificates to enforce policy and IETF work products. In other words, several Root Programs/the BRs have used EKU in CA certificates to denote policy scope, whereas the IETF in its various standards have the assumption that EKU is generally only expressed in end-entity certificates. I think that this interplay needs to be kept in mind when reading RFC 6960 and asserting whether or not the sole determiner on whether a CA certificate is an OCSP responder certificate is the presence of the ocspSigning EKU. Thanks, Corey From: Ryan Sleevi <r...@sleevi.com> Sent: Thursday, July 2, 2020 9:57 AM To: Corey Bonnell <cbonn...@securetrust.com> Cc: r...@sleevi.com; Neil Dunbar <ndun...@trustcorsystems.com>; 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 9:36 AM Corey Bonnell <cbonn...@securetrust.com <mailto:cbonn...@securetrust.com> > wrote: (Sorry Ryan and Neil for the double-email, I accidentally omitted the list on the first email) > As others have rightfully pointed out, if the EKU is present, it is a > delegated responder, full stop. For the certificate to be used as a delegated responder (as opposed to an issuer of OCSP responder certificates), wouldn't they also need a keyUsage value of digitalSignature? No, this isn’t specified/required for Delegated Reaponders (at least, by 6960), and the client implementations I looked at did not check. I suspect you’re thinking about RFC 5280, Section 4.2.1.3’s normative requirement on the issuer of such certificates needing to include the KU? If so, that just seems to be arguing yet another way these certificates violate the requirements/profile. RFC 6960 is clear that the EKU indicates a designated responder, and you can’t “take back” that by suggesting the lack of the KU, as required by 5280, or the lack of nocheck, as required by the BRs, makes it “not a Responder”. It just makes it “not a correctly issued responder”.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy