<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">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>