OCSP response issuance latency for certificates/pre-certificates
Opened this issue · 9 comments
Mozilla policy requires that a CA be able to serve validation information for precertificates - see https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#54-precertificates, but no timeframe is specified for when OCSP responses must be available. My understanding is that many CAs distribute OCSP responses via CDN, and depending on the CDN's infrastructure and where you are in the world, you might get an "unauthorized" response to an OCSP request.
A few bugs have been filed for OCSP "unauthorized" responses for certificates / precertificates. See https://bugzilla.mozilla.org/show_bug.cgi?id=1903823 and https://bugzilla.mozilla.org/show_bug.cgi?id=1905419. For cross-reference, some OCSP data is available through OCSP Watch, https://sslmate.com/labs/ocsp_watch/ and https://crt.sh. One proposal is that CA operators be given 15 minutes between the CT logging of the precertificate and having an OCSP response available. A result of this proposed 15-minute initial window would be to clarify the issue for compliance purposes.
Hi @BenWilson-Mozilla Then you'd be removing the allowed 4-day update period off the policy?
@pfuentes69 I interpret the 4-day update period as something else (the renewal cycle of OCSP responses). This proposal is to address initial issuance of OCSP responses.
It seems odd to target this proposal at Precertificates specifically. Precertificates are used in most cases, but it's also possible to issue a Certificate without ever issuing a corresponding Precertificate. (RFC6962 provides three different mechanisms for SCT distribution, only one of which uses Precertificates).
ISTM that the proposed 15-minute window for publication of a first OCSP response should begin whenever the serial number transitions from the "unused" state to either of the other states ("assigned" or "reserved").
@pfuentes69 I interpret the 4-day update period as something else (the renewal cycle of OCSP responses). This proposal is to address initial issuance of OCSP responses.
@BenWilson-Mozilla If I understand well what you say:
- When a pre-certificate is created, the CA has 15 minutes to update the OCSP DB, so it responds properly
- When a certificate changes status (i.e. good to revoked), the CA has 4 days to update the OCSP DB, so it could provide improper responses during 4 days
If I got that well, I'd have some difficulties to see this as a balanced approach... specially now that CAs must update the CRL in 24-hours max after revocation.
When a certificate changes status (i.e. good to revoked), the CA has 4 days to update the OCSP DB, so it could provide improper responses during 4 days
@pfuentes69 Actually, you need to update (refresh) your OCSP responses every 4 days, period. From the BRs:
"For OCSP responses with validity intervals greater than or equal to sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate."
That means that at least every 4 days your OCSP response needs to be updated (refreshed), even if the nextUpdate of the current response is still X days away.
Unlike for CRLs, I don't believe the BRs state anything about how soon a new OCSP response must be signed upon a status change, though several people have indicated that a certificate isn't really revoked until the new CRL and/or OCSP responses have been published, thus affecting the 24 hour / 5 day revocation rules.
I think for Subscriber certificates, we should have language added that OCSP responses should be refreshed within XX minutes upon a status change, but that would be a CAB discussion
@pfuentes69 Actually, you need to update (refresh) your OCSP responses every 4 days, period. From the BRs:...
@XolphinMartijn I was highlighting a "worst case scenario", stating that something is wrong here...
An important consideration is web servers with deficient OCSP stapling implementations, such as Apache, that will happily staple an invalid response from an OCSP responder, causing Firefox to reject the TLS connection. The invalid response may remain stapled even after the OCSP response is propagated through the CDN, until the web server decides to refresh the staple.
Most CAs, including some very high-volume ones, already publish OCSP responses for new certificates immediately. If a 15 minute grace period is defined and these CAs switch their implementations to take advantage of it, there would be regression in reliability for Firefox users.
To avoid that, CAs should be forbidden from delivering the certificate to the subscriber until the OCSP response for it is available worldwide.
I will work on a GitHub pull request and ballot in the CABF Server Certificate Working Group.
See https://lists.cabforum.org/pipermail/servercert-wg/2024-September/004925.html (Voting ends 10/3/2024 on Ballot SC-076v2 "Clarify and Improve OCSP Requirements")
cabforum/servercert@929d9b4...a8a3669