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

[Ryan Sleevi <[e-mail]>]

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:
>
>
>
>    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?
>
>
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.