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

[Yoshiro YONEYA]

JPRS votes YES to Ballot SC-063 V4.

-- 
Yoshiro YONEYA <yoshiro.yoneya at jprs.co.jp>

On Thu, 6 Jul 2023 15:59:31 +0000 Ryan Dickson via Servercert-wg <servercert-wg at cabforum.org> wrote:

> Purpose of Ballot SC-063
> 
> This Ballot proposes updates to the Baseline Requirements for the Issuance
> and Management of Publicly-Trusted Certificates related to making Online
> Certificate Status Protocol (OCSP) services optional for CAs. This proposal
> does not prohibit or otherwise restrict CAs who choose to continue
> supporting OCSP from doing so. If CAs continue supporting OCSP, the same
> requirements 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:
>    -
> 
>       a full and complete, or
>       -
> 
>       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…
>    -
> 
>       within twenty-four (24) hours after recording a Certificate as
>       revoked; and
>       -
> 
>       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 not be 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
>    optionally revoke 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
>    presented here <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 Tummala of Microsoft
> and Tim Callan of 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
> 
> 
> 
> ― 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