Let's Encrypt votes Yes on Ballot SC-076v2. On Thu, Sep 26, 2024 at 12:01 PM Aaron Gable via Servercert-wg < servercert-wg@cabforum.org> wrote:
> *Purpose of Ballot* > > This is v2 of this ballot; you can see the discussion thread for v1 here: > https://lists.cabforum.org/pipermail/servercert-wg/2024-August/004798.html > > 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/a8a36690802250cdbe508a6c1f99f700a5357bd3/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...a8a36690802250cdbe508a6c1f99f700a5357bd3 > > *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 29, 2024 19:00 UTC > End: September 26, 2024 19:00 UTC > > *Voting Period (7 days)* > > Start: September 26, 2024 19:00 UTC > End: October 3, 2024 19:00 UTC > _______________________________________________ > Servercert-wg mailing list > Servercert-wg@cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg >
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
