[Servercert-wg] Voting Period Begins - Ballot SC-063 V4: “Make OCSP Optional, Require CRLs, and Incentivize Automation”

Fri Jul 7 08:58:29 UTC 2023

HARICA votes "yes" to ballot SC-063.

On 6/7/2023 6:59 μ.μ., Ryan Dickson via Servercert-wg wrote:
>
> Purpose of Ballot SC-063
>
> This Ballot proposes updates to the Baseline Requirements for the 
> Issuance and Management of Publicly-Trusted Certificatesrelated to 
> making Online Certificate Status Protocol (OCSP) services optionalfor 
> CAs. This proposal does notprohibit or otherwise restrict CAs who 
> choose to continue supporting OCSP from doing so. If CAs continue 
> supporting OCSP, the samerequirements apply as they exist today.
>
>
> Additionally, this proposal introduces changes related to CRL 
> requirements including:
>
>  *
>
>     CRLs must conform with the proposed profile.
>
>  *
>
>     CAs must generate and publish either:
>
>      o
>
>         a full and complete, or
>
>      o
>
>         a set of partitioned CRLs (sometimes called “sharded” CRLs),
>         that when aggregated, represent the equivalent of a full and
>         complete CRL.
>
>  *
>
>     CAs issuing Subscriber Certificates must update and publish a new CRL…
>
>      o
>
>         within twenty-four (24) hours after recording a Certificate as
>         revoked; and
>
>      o
>
>         Otherwise:
>
>          +
>
>             at least every seven (7) days if all Certificates include
>             an Authority Information Access extension with an
>             id-ad-ocsp accessMethod (“AIA OCSP pointer”), or
>
>          +
>
>             at least every four (4) days in all other cases.
>
>
> Finally, the proposal revisits the concept of a “short-lived” 
> certificate, introduced in Ballot 153 
> <https://cabforum.org/2015/11/11/ballot-153-short-lived-certificates/>. 
> As described in this ballot, short-lived certificates (sometimes 
> called “short-term certificates” in ETSI specifications 
> <https://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.04.04_60/en_31941201v010404p.pdf>) 
> are:
>
>  *
>
>     optional. CAs will notbe required to issue short-lived
>     certificates. For TLS certificates that do not meet the definition
>     of a short-lived certificate introduced in this proposed update,
>     the current maximum validity period of 398 days remains applicable.
>
>  *
>
>     constrained to an initial maximum validity period of ten (10)
>     days.The proposal stipulates that short-lived certificates issued
>     on or after 15 March 2026 must not have a Validity Period greater
>     than seven (7) days.
>
>  *
>
>     not required to contain a CRLDP or OCSP pointer and are not
>     required to be revoked. The primary mechanism of certificate
>     invalidation for these short-lived certificates would be through
>     certificate expiry. CAs may optionallyrevoke short-lived
>     certificates. The initial maximum certificate validity is aligned
>     with the existing maximum values for CRL “nextUpdate” and OCSP
>     response validity allowed by the BRs today.
>
>
> Additional background, justification, and considerations are outlined 
> here 
> <https://docs.google.com/document/d/180T6cDSWPy54Rb5d6R4zN7MuLEMShaZ4IRLQgdPqE98/edit>.
>
>
> Proposal Revision History:
>
>  *
>
>     The set of updates resulting from the first round of discussion
>     are presentedhere
>     <https://github.com/ryancdickson/staging/pull/3/files>.
>
>  *
>
>     The set of updates resulting from the second round of discussion
>     are presented here
>     <https://github.com/ryancdickson/staging/pull/5/files>.
>
>  *
>
>     The set of updates resulting from the third round of discussion
>     are presented here
>     <https://github.com/ryancdickson/staging/pull/7/files>.
>
>
> The following motion has been proposed by Ryan Dickson and Chris 
> Clements of Google (Chrome Root Program) and endorsed by Kiran 
> Tummalaof Microsoft and Tim Callanof Sectigo.
>
>
>
> — Motion Begins —
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and 
> Management of Publicly-Trusted Certificates” (“Baseline 
> Requirements”), based on Version 2.0.0.
>
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
> https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3..b8a0453e59ff342779d5083f2f1f8b8b5930a66a 
> <https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3..b8a0453e59ff342779d5083f2f1f8b8b5930a66a>
>
>
>
> — Motion Ends —
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for 
> approval of this ballot is as follows:
>
>
> Discussion (13+ days)
>
>  *
>
>     Start time: 2023-06-22 20:30:00 UTC
>
>  *
>
>     End time: 2023-07-06 15:59:59 UTC
>
>
> Vote for approval (7 days)
>
>  *
>
>     Start time: 2023-07-06 16:00:00 UTC
>
>  *
>
>     End time: 2023-07-13 16:00:00 UTC
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230707/caf6ecbd/attachment-0001.html>