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

Thu Apr 27 16:35:45 UTC 2023

Dear Members,

While ballot SC-063 focuses on OCSP and short-lived certificates, it 
also affects the requirements for CRL. I just want to highlight these 
changes because they may not be very clear to Members.

  * Issuing CRLs from all intermediate CAs becomes mandatory for all
    cases, regardless if these CAs issue "short-lived" Subscriber
    Certificates or not. This is not required today in the BRs but it is
    a requirement by at least two Root Store programs.
  * The current BRs state that if a CA that issues Subscriber
    Certificates, produces CRLs, they need to re-issue those CRLs at
    least once every 7 days. The ballot changes that frequency to 24 hours.

For a CA that actively issues/revokes Subscriber Certificates, this 
frequency makes sense. However, for CAs that are being "phased-out" or 
no certificates are revoked, perhaps it doesn't.

The goal of issuing a CRL is to signal Relying Parties that a Subscriber 
Certificate should no longer be trusted. Issuance of that CRL should 
happen as soon as a certificate is marked "revoked" by the CA. With that 
said, even 24h seems to be a long time, considering that Apple implies 
(via their Root Store Policy 
<https://www.apple.com/certificateauthority/ca_program.html>) that they 
check for new CRLs every 4 hours.

Wouldn't it be better if Relying Parties were able to easily check that 
a CRL has not changed and keep the information of the previous one 
(cache), rather than downloading a new CRL, parsing it only to discover 
that the contents are exactly the same as the previous one?

We already have a requirement in section 4.9.7 that triggers the 
issuance of a CRL within 24 hours if a Subordinate CA Certificates is 
revoked, otherwise the frequency to issue such a CRL is once every 12 
months.

If people agree, I would like to keep the language for "online CAs" to 
issue CRLs at least once every 7 days but issue and publish within 4 
hours if a Subscriber Certificate is revoked. That approach would 
propagate the "revocation message" sooner to Relying Parties and would 
also remove the unnecessary "cost" of issuing CRLs unnecessarily (i.e. 
if no revocations take place).

Thoughts?

Dimitris.

On 27/4/2023 4:30 μ.μ., 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 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:
>
>      o
>
>         a full and complete CRL; OR
>
>      o
>
>         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 eitherthe full and
>     complete orpartitioned/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 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>.
>
>
>
> 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..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/20230427/7b8f198e/attachment-0001.html>