I agree with Aaron’s assessment.
In addition to the reasons from a compliance standpoint that Aaron outlined, I struggle to see the value provided to a Relying Party by mandating that the CA operate an OCSP responder that responds authoritatively for serials corresponding to short-lived certificates. This discussion is a bit hypothetical currently, as Microsoft still requires the inclusion of an AIA OCSP pointer in end-entity TLS serverauth certificates regardless of validity period even if the BRs permits its omission. Thanks, Corey From: 'Aaron Gable' via [email protected] <[email protected]> Sent: Tuesday, February 20, 2024 4:45 PM To: Seo Suchan <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: OCSP responde for serial number that exist but out of scope of OCSP reponder? 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] <mailto:[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 <http://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] <mailto:[email protected]> " group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:dev-security-policy%[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] <mailto:[email protected]> " group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[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 <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErfkCg4dBEQurQSuARqFLvw36st3be9PAqrKn8iR%3DsH_rg%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- 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/DM6PR14MB218664736B10D7C74F3F094B92572%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
