[Servercert-wg] Discussion Period Begins: Ballot SC-076 "Clarify and Improve OCSP Requirements"

[Ponds-White, Trev]

Hi Aaron G.,

We have some feedback on the ballot.

Can you add the word “first” into the sentence about 15 minutes to reinforce that we are discussing just the first published response. Not responses associated with status changes. We think this will improve clarity and future litigation of this requirements. So the new sentence would read “starting no more than 15 minutes after the Certificate or Precertificate is first published or otherwise made available.”

Do we need “using any current or previous key associated with that CA subject;”? What is additional clarity is that trying to provide? It kind of reads as an endorsement of reusing keys for new CAs.

When we read the lines starting at line 1391 we thought it might be more clear if there was a line break after the first sentence. So it would look like this instead:

“If the OCSP responder receives a request for the status of a certificate serial number that is "unassigned", then the responder SHOULD NOT respond with a "good" status.

If the OCSP responder is for a CA that is not Technically Constrained in line with [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), the responder MUST NOT respond with a "good" status for such requests."

Thanks!
Trevoli Ponds-White

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Aaron Gable via Servercert-wg
Sent: Thursday, August 22, 2024 9:28 AM
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: [EXTERNAL] [Servercert-wg] Discussion Period Begins: Ballot SC-076 "Clarify and Improve OCSP Requirements"


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


Purpose of Ballot

This ballot attempts to address three concerns:
- The confusion around "reserved" serials, which do not actually exist because all Precertificate serials are assumed to also exist in corresponding Certificates and are therefore actually "assigned";
- Confusion around whether, and how quickly, OCSP responders must begin providing authoritative responses for Certificates and Precertificates; and
- Confusion around whether and how the OCSP requirements apply to Certificates which do not contain an AIA OCSP URL, but for which the CA's OCSP responder is still willing to provide responses.

These concerns have been previously discussed in this Mozilla policy bug<https://github.com/mozilla/pkipolicy/issues/280>, this ServerCert WG bug<https://github.com/cabforum/servercert/issues/422>, and this Bugzilla incident<https://bugzilla.mozilla.org/show_bug.cgi?id=1905419>.

It addresses these concerns by:
- Stating that OCSP responses must be available within 15 minutes of signing a certificate containing an AIA OCSP URL;
- Removing the concept of a "reserved" serial entirely;
- Moving all OCSP requirements into Section 4.9.9, leaving Section 4.9.10 (which RFC 3647 says is meant to place requirements on relying parties, not on CAs) empty; and
- Organizing the requirements in Section 4.9.9 into three clusters:
  - Definitions of "validity interval", "assigned", and "unassigned";
  - Requirements on OCSP Responders, which apply only to responses from AIA OCSP URLs found in issued certs; and
  - Requirements on OCSP Responses, which apply to all responses regardless of whether the certificate in question has an AIA OCSP URL.

GitHub PR representing this ballot: https://github.com/cabforum/servercert/pull/535
Rendered view of the resulting text: https://github.com/cabforum/servercert/blob/f61814473a1340774aec4022a6cbfe1fa2616458/docs/BR.md#499-on-line-revocationstatus-checking-availability

Motion

The following motion has been proposed by Aaron Gable (Let's Encrypt / ISRG), and is endorsed by Ben Wilson (Mozilla) and Antonis Eleftheriadis (HARICA).

Motion Begins

Modify the "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates", based on Version 2.0.6, as specified in the following redline:

https://github.com/cabforum/servercert/compare/929d9b4a1ed1f13f92f6af672ad6f6a2153b8230...f61814473a1340774aec4022a6cbfe1fa2616458

Motion Ends

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

Discussion Period (at least 7 days)

Start: August 22, 2024 16:30 UTC
End: on or after August 29, 2024 16:30 UTC

Voting Period (7 days)

Start: TBD
End: TBD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240828/c2b2e30a/attachment.html>