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

[Aaron Gable]

Ryan,

Thanks for your reply! Yes, your understanding of the question is correct.
In fact, I can narrow the scope of the questions even further, thanks to
our simple issuing intermediate setup.

Our Let's Encrypt Authority X3 (https://crt.sh/?caid=16418) intermediate is
represented by two certificates; one (from DST Root CA X3) has already
expired, and the other (from ISRG Root X1) expires later this year. We
ceased issuance from this intermediate in December of last year, and only
ever issued 90-day end-entity certificates from it, so that all of its
issued certificates would expire prior to the expiration of either of its
certificates.

However, our OCSP responder for Let's Encrypt Authority X3 has still been
receiving small amounts of traffic, querying for the status of expired
certificates. We simply wanted to get a second opinion on the matter before
taking down this OCSP responder, in case there was a requirement we had
missed to keep it active throughout the lifetime (all possible lifetimes)
of the issuing intermediate.

For our practical purposes, the second question is a subset of the first --
we do not issue end-entity certificates which expire after the issuing
intermediate, so an OCSP responder for an expired intermediate is also an
OCSP responder for an intermediate with no unexpired issued certificates,
and is covered by the response you gave above. (Obviously this is not true
in general, but is for our case here.) We were asking primarily to cover
the case where maintaining an OCSP responder for the above case was
required, in order to determine when that requirement would cease.

Thank you again for the reply,
Aaron

On Mon, Mar 22, 2021 at 11:28 AM Ryan Sleevi <sleevi at google.com> wrote:

> 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/e2cb9e2e/attachment.html>