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

Mon May 1 22:49:20 UTC 2023

I had previously expressed my concern with the potential effects of this
ballot on the broader ecosystem, meaning clients that still rely on OCSP
for revocation checking. I realize that revocation checking via OCSP is not
reliable, but judging by OCSP traffic volumes there are still many clients
that think it's worth doing. The linked justification document leads me to
believe that requiring CAs to include the CRL Distribution Points extension
in all end-entity certificates is intended to mitigate this concern.
Unfortunately, I have more concerns with this approach.

The ballot does not prevent CAs from sharding CRLs to the point that
individual sites are easily or exclusively identified, so even allowing
cRLDPs in end-entity certificates seems to violate the purpose of this
ballot. Moreover, OCSP is generally a more efficient mechanism for
delivering status information for end-entity certificates, and - while I
acknowledge that OCSP availability is a big weakness of the Web PKI - CAs
have heavily invested in building scalable infrastructure to deliver OCSP
responses. The same is not always true for CRLs, since they are currently
optional. While I believe that clients often prioritize OCSP over CRLs, I
have no data to prove that is mostly/always the case, and in my [admittedly
very outdated] experience plenty of clients will download CRLs if they are
available alongside OCSP.

Is there some other reason to begin requiring cRLDPs if the CA chooses to
operate an OCSP service after this ballot goes into effect?

Thanks,

Wayne

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/20230501/251cc1f3/attachment-0001.html>