Sections 4.9.9 and 4.9.10 of version 2.0.2 of the BRs say that they apply "for communicating the status of Certificates which include an Authority Information Access extension with an id-ad-ocsp accessMethod." My reading of that is very simple: if the cert doesn't have an OCSP URI in it, you don't need to operate OCSP services for it.
The end of Section 4.9.10 does have particular rules about how OCSP responders can behave for "unused" and "reserved" serials. But it does not state that an OCSP responder must provide answers for all "assigned" certificates -- instead, that is implied by the requirements above, which again do not apply to certificates without an OCSP URI. Similarly, the MRSP conditions its OCSP requirements behind "if the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service...". It sounds to me like it would be acceptable for an OCSP responder to not provide status information for short-lived serials, in which case it is not providing revocation information via OCSP, and the MRSP requirements do not apply. Aaron On Fri, Feb 16, 2024, 12:55 Seo Suchan <[email protected]> wrote: > I reached same conclusion that in effect all OCSP responder need to know > all certificate the CA signed, making mixed CA that do both short-lived > and long-lived leaf doesn't get much benefit CA side and better to make > different intermediate > > 2024-02-17 오전 7:44에 Matt Palmer 이(가) 쓴 글: > > On Fri, Feb 16, 2024 at 09:05:39AM -0800, Suchan Seo wrote: > >> 1. a CA issues both long life leaf cert with OCSP endpoint and 5 day > one > >> without any OCSP AIA in it, what OCSP reponsder can/should answer for > short > >> life certificate? > > By my reading of the BRs (as of v2.0.2, anyway) and the Mozilla root > > store policy, OCSP responders for short-lived certificates still have to > > return "good". Does your reading of the relevant documents produce a > > different interpretation? > > > >> 2. Can a intermediate CA run two sharded OCSP responder, splited by last > >> bit of serial number and fill AIA with currect one? if allowed, can > >> odd.ocsp.ca.com answer "unused" at all even serial number and not > >> considered bindingly revorked? > > Well, an OCSP response that said a particular serial was "unused" > > (technically it's "unknown", but I presume we're referring to the same > > thing) wouldn't be considered bindingly revoked, because if an OCSP > > responder wants to indicate a certificate is revoked, it returns a > "revoked" > > response. > > > > However, I very much doubt it would be reasonable to operate OCSP in the > way > > you describe. An OCSP response isn't "bound" to the responder that > produced > > it (you can use separate responder certs, but I don't know of any way to > > constrain the set of serial numbers that a responder cert is valid for), > so > > an OCSP response that returned "unknown" would still chain to the > > intermediate that *did* issue that certificate, and that would be... not > > great. > > > > If, for some reason, you wanted to "shard" OCSP responses like that, > > presumably the correct approach would be to issue from multiple > > intermediates. > > > > - Matt > > > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b0906da8-043e-422d-ad65-bc185a24eed5%40gmail.com > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErfkCg4dBEQurQSuARqFLvw36st3be9PAqrKn8iR%3DsH_rg%40mail.gmail.com.
