Re: [pkix] Authorised responders OCSP and id-kp-OCSPSigning

[Stefan Santesson <[e-mail]>]

Thanks Ryan.

 

For all practical uses I meant what you first stated. That is, the OCSP response is validated directly by the CA certificate.

The OCSP standard does not explicitly say anything about the CA certificate and from my perspective that is not strictly needed. As long as the OCSP response and the certificate is signed with the same key, I can validate the response using the CA certificate.

 

So in all important aspects of this, you confirm my assumptions.

 

Stefan Santesson 

 

From: Ryan Sleevi <[e-mail]>
Reply to: <[e-mail]>
Date: Sunday, 28 February 2021 at 20:52
To: Stefan Santesson <[e-mail]>
Cc: IETF PKIX <[e-mail]>
Subject: Re: [pkix] Authorised responders OCSP and id-kp-OCSPSigning

 

 

 

On Sun, Feb 28, 2021 at 2:27 PM Stefan Santesson <[e-mail]> wrote:

Came across this question on OCSP where I wander how various implementers chose to interpret the requirements.

And shamefully I can’t recall how we thought when we published this.

 

The text says that a CA can choose to either:

 
Sign the OCSP response itself, or
Explicitly delegate OCSP signing to another entity
 

It then states that delegation SHALL be indicated by inclusion of the id-kp-OCSPSigning extended key usage

 

So, as I read this, the id-kp-OCSPSigning extended key usage is NOT required if the CA issues OCSP responses itself using the same key as was used to sign the certificate.

This because there is no delegation taking place.

 

So I wander:

 
Do people here agree with my interpretation
Do implementations in general agree with this interpretation, or do they all enforce id-kp-OCSPSigning always?
 

As worded, no to both.

 

This may seem like a minor nit, but is an incredibly important and meaningful detail: it's not sufficient to say "same key", because that allows for (implicitly) the existence of a responder certificate that shares the same key, but otherwise different attributes, than the issuing CA.

 

If you meant "OCSP response directly signed by the CA certificate that signed the certificate being verified", then yes, there is no need for id-kp-OCSPSigning on the issuing CA certificate. I realize that keys sign, not certificates, but for purposes of this discussion, I mean the same (DN+SPKI) tuple, with the same X.509 issuer, serialNumber, and attributes as used to issue the certificate (i.e. the same certificate).

 

Given the recent confusion around intermediate/subordinate and the somewhat confused attempt to read organization distinctions rather than technical into terms like "CA", it seems an important bit to correct, to make sure we're talking about the same thing, unambiguously.

 

As to your second question, the answer is that there is significant divergence in what attributes are seen as essential with a directly-delegated responder (i.e. a certificate directly signed by the CA certificate that issued the certificate being verified). I am not aware of implementations that enforce id-kp-OCSPSigning always when the OCSP response is directly signed by the issuing CA certificate of the certificate being verified, but whether or not implementations consistently enforce id-kp-OCSPSigning, or require other, additional properties (e.g. the absence of a basicConstraints/the cA boolean being false, the presence of certain keyUsage attributes, direct-or-transitively signed) varies for those responses-issued-by-a-responder-issued-by-the-issuing-CA.

 

There is further variance for when systems allow local policy to locally configure responder certificates (i.e. without the CAs direct knowledge/participation/issuance), as this is expanded upon in RFC 6960, 4.2.2.2. From the RFC 6960 perspective, such locally configured responders are not required to present the EKU, but implementations may vary and otherwise require it.