[Servercert-wg] OCSP Responder Requirements for Unexpired, Not-in-Use Intermediates

[Ryan Sleevi]

Aaron,

Thanks for raising this! A few comments inline below.

On Fri, Mar 19, 2021 at 7:48 PM Aaron Gable via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Hello all,
>
> We (Let's Encrypt) are interested in any requirements, recommendations, or
> CA ecosystem best practices for turning off an Intermediate OCSP responder
> in the following scenario:
>
>     An intermediate that is unexpired, with all end-entity certs it signed
> expired, and the CA is no longer going to issue from it.
>

Just to make sure I follow the problem statement:

There is an OCSP Responder A, at some Defined URL, which provides status
for a number of issued certificates. All of those issued certificates have
expired, and so your question is "If there is no unexpired certificate for
that responder URL, does that responder URL need to continue functioning".
Is that correct? The clarifying distinction I'm making here is that it's
not just end-entity certs, it's that all issued certs that have that URL
are expired.

We think fully decommissioning OCSP responders for an intermediate in this
> scenario is not a violation of the Baseline Requirements. However, it might
> be best to return some kind of fully-formed unauthorized response until the
> intermediate is expired or a set time after expiry.
>

So, the main requirements for OCSP come from 9.6.1 of the BRs ("That the CA
maintains a 24x7 publicly-accessible Repository with current information
regarding the status (valid or revoked) of **all unexpired Certificates**")
and 4.10.2 ("The CA SHALL maintain an online 24x7 Repository that
application software can use to automatically check the current status of
**all unexpired Certificates** issued by the CA"), with emphasis added by
**. This, of course, is in addition to 7.1.23(c), which requires the OCSP
Responder URL be included in the issued certificates.

Is there any situation in which that responder URL may still be used? If
not, then I think all of the expiration means it should be safe, from the
BRs point of view, to turn down, although the obligations of 4.9.10 will
still continue for the lifetime of the CA (and its inclusion in the
relevant audits), so it does support your remark that providing a
well-formed response gives you at least some determinism to make sure
there's no "good" response ever issued.


>
> Additionally, we're interested to know the recommendations related to an
> expired intermediate. How long should an OCSP responder exist after the
> intermediate issuer is expired?
>

This one is a bit trickier.  I would say the expiration of the intermediate
is largely orthogonal, the question is about the expiration of the issued
certificates. This becomes a bit clearer when you consider the same issuing
intermediate may have multiple certificate paths, so the expiration of a
single intermediate does not necessarily mean those existing certificates
are invalidated, or that the obligation for providing a response goes away.

Your main requirement should be from 4.10.1 of the BRs, but after that, it
seems to be flexible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210322/fc8a3a23/attachment.html>