OCSP responde for serial number that exist but out of scope of OCSP reponder?

[Suchan Seo]

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?

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?

[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

[Seo Suchan]

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 이(가) 쓴 글:

[Aaron Gable]

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

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
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.

[Corey Bonnell]

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

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.