[Servercert-wg] Discussion Period Begins - Ballot SC-063: “Make OCSP Optional and Incentivize Automation”

Aaron Gable aaron at letsencrypt.org
Wed May 10 00:09:15 UTC 2023


Hi Ryan,

In reviewing this ballot, I've noticed another aspect of it that I believe
is unintended.

The ballot amends Section 1.2.2 Relevant Dates to say that "CAs MUST
generate and publish CRLs" effective 2024-03-15.

However, it also amends 7.1.2.7.6 Subscriber Certificate Extensions to say
that the crlDistributionPoints extension MUST be included in all
non-Short-Lived Subscriber Certificates. This section was introduced in
ballot SC-062, and (as noted in Section 7.1 Certificate Profile) has an
effective date of 2023-09-15.

Therefore this ballot would actually require CAs to include CRLDP URLs (and
therefore to generate and publish CRLs) as soon as September of this year,
which I do not believe is this ballot's intent.

Thanks,
Aaron

On Thu, Apr 27, 2023 at 6:30 AM 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
> to include:
>
>    -
>
>    Establishing a detailed CRL profile, consistent with the certificate
>    profiles introduced in Version 2.0.0 of the Baseline Requirements.
>    -
>
>    CAs MUST generate and publish either:
>    -
>
>       a full and complete CRL; OR
>       -
>
>       partitioned CRLs (sometimes called “sharded” CRLs), that when
>       aggregated, represent the equivalent of a full and complete CRL.
>       -
>
>    CAs MUST include the corresponding HTTP URI for either the full and
>    complete or partitioned/sharded CRL in the CRL Distribution Point
>    extension of subscriber certificates.
>    -
>
>    CRLs MUST be updated and reissued once daily.
>
>
> 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>
> .
>
>
>
> 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..6ff4a7b332f46a8a54cc36e16d1299373d31efe9
>
>
>
> — Motion Ends —
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
>
> Discussion (14+ days)
>
>    -
>
>    Start time: 2023-04-27 13:30:00 UTC
>    -
>
>    End time: Not before 2023-05-11 13:30:00 UTC
>
>
> Vote for approval (7 days)
>
>
>    -
>
>    Start time: TBD
>    -
>
>    End time: TBD
>
> _______________________________________________
> 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/20230509/cc6bb83c/attachment-0001.html>


More information about the Servercert-wg mailing list