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!)
--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
