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

From: Stefan Santesson <[email-masked]>
Date: Sun, 28 Feb 2021 20:27:14 +0100

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?

Stefan Santesson

---

From: Joel Kazin <[email-masked]>
Date: Sun, 28 Feb 2021 14:59:28 -0500

I agree.

On 2/28/2021 2:27 PM, Stefan Santesson wrote:
>
> Came across this question on OCSP where I wander how various 
> implementers chose to interpret the requirements.
>
>   * Sign the OCSP response itself, or
>   * Explicitly delegate OCSP signing to another entity
>
> 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.
>
>  1. Do people here agree with my interpretation
>  2. Do implementations in general agree with this interpretation, or
>     do they all enforce id-kp-OCSPSigning always?
>
> Stefan Santesson
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 28 Feb 2021 15:01:42 -0500

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

>    - Sign the OCSP response itself, or
>    - Explicitly delegate OCSP signing to another entity
>
>
>
> required if the CA issues OCSP responses itself using the same key as was
> used to sign the certificate.
>
>    2. 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.

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 28 Feb 2021 21:10:58 +0100

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 <[email-masked]>
Reply to: <[email-masked]>
Date: Sunday, 28 February 2021 at 20:52
To: Stefan Santesson <[email-masked]>
Cc: IETF PKIX <[email-masked]>
Subject: Re: [pkix] Authorised responders OCSP and id-kp-OCSPSigning

So I wander:

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.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 28 Feb 2021 16:49:44 -0500

Stefan,

To add some color to EKU part, if the EKU was required that would mean the parent CA is  delegating the child CA to be authoritative for the revocation status of the certificates issued by the parent CA.  Clearly, we do not want that unless parent truly intends that.

From: pkix [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Sunday, February 28, 2021 3:11 PM
To: [email-masked]
Cc: IETF PKIX <[email-masked]>
Subject: Re: [pkix] Authorised responders OCSP and id-kp-OCSPSigning

Thanks Ryan.

Stefan Santesson 

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

On Sun, Feb 28, 2021 at 2:27 PM Stefan Santesson <[email-masked] <mailto:[email-masked]> > wrote:

So I wander:

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

As worded, no to both.