> 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 <[email protected]>
Sent: Thursday, July 2, 2020 9:57 AM
To: Corey Bonnell <[email protected]>
Cc: [email protected]; Neil Dunbar <[email protected]>;
[email protected]
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 <[email protected]
<mailto:[email protected]> > 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
