<div dir="ltr">Ryan,<div><br></div><div>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.</div><div><br></div><div>Our Let's Encrypt Authority X3 (<a href="https://crt.sh/?caid=16418">https://crt.sh/?caid=16418</a>) 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thank you again for the reply,</div><div>Aaron</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 22, 2021 at 11:28 AM Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Aaron,</div><div><br></div><div>Thanks for raising this! A few comments inline below.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 19, 2021 at 7:48 PM Aaron Gable via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello all,<div><br>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:</div><div><br>    An intermediate that is unexpired, with all end-entity certs it signed expired, and the CA is no longer going to issue from it.<br></div></div></blockquote><div><br></div><div>Just to make sure I follow the problem statement:</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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?<br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Your main requirement should be from 4.10.1 of the BRs, but after that, it seems to be flexible.</div></div></div>
</blockquote></div>