SC-63: Make OCSP Optional and Incentivize Automation

The ballot is proposed by the Chrome Root Program (Ryan Dickson and Chris Clements) and endorsed by Microsoft (Kiran Tummala) and Sectigo (Tim Callan).

Summary: 

This pull request 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 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. As described in this ballot, short-lived certificates (sometimes called “short-term certificates” in ETSI specifications) 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.

Background and Justification:

• Make OCSP Optional: OCSP requests reveal details of individuals’ browsing history to the operator of the OCSP responder. These can be exposed accidentally (e.g., via data breach of logs) or intentionally (e.g., via subpoena). Due to privacy concerns, several certificate consumer products represented in the CA/Browser Forum do not perform online OCSP checks by default - or have signaled interest in transitioning to privacy-preserving methods of communicating revocation status. Beyond privacy concerns, OCSP use is accompanied by a high volume of routine incidents and issues (1 and 2). Concern surrounding OCSP is further elevated considering the disproportionately high cost of offering these services reliably at the global scale of the Web PKI.

• Require CRLs: Given this ballot makes operating OCSP services optional for CAs, allow relying party software applications and certificate consumer user agents to consistently and reliably evaluate certificate revocation status using a privacy-preserving check. While many certificate consumer user agent installations do not rely on the processing of data contained in the CRL Distribution Points extension by default (i.e., they instead rely on custom status-checking mechanisms like CRLSets or CRLite that aggregate and communicate revocation status), the broader ecosystem impact of making the presence of both OCSP and CRLDP optional in Web PKI certificates is not yet understood and is not being considered at this time.

• Short-Lived Certificates: Subscriber certificate expiration is broadly and reliably enforced across major certificate consumers, while the same is not for certificate revocation. From a security perspective, short-lived certificates may reduce the aperture of an attack where subscriber private keys are compromised - limiting the maximum attack window to just a few days. Short-lived certificates also present an opportunity to further reduce the size of Certificate Revocation Lists, which are being relied upon by many certificate consumers represented in the Forum and introduced as required by this proposal.

Proposed Transition Period:

The proposed effective date for this ballot is 2024-03-15. However, CAs must consider the following:

• OCSP: CAs must continue supporting existing OCSP services for as long as the corresponding HTTP URI exists within a valid, unrevoked certificate.

• CRLs: CAs may begin including the CRL Distribution Points extension in subscriber certificates at any time. However, all non-short-lived subscriber certificates issued after the effective date MUST include the CRL Distribution Points extension as described in the ballot text.

• Short-Lived Certificates: May optionally be issued without CRLDP or OCSP pointers, as described in this proposed ballot, once these changes have been made effective.

Additional Areas Considered:

• Impact on Certificate Transparency Log Operators: Depending on the number of short-lived certificates issued, Certificate Transparency log operators may need to reduce the temporal sharding period of logs from one year to a shorter period. Although log operators already have to manage the size and capacity of their CT logs, short-lived certificates would be an additional growth factor that needs to be considered. Since presenting this proposal in October 2022, we have not heard concerns from CT log operators related to the impact of short-lived certificates on logs.

• Impact on Certificate Consumers/Relying Party Software: It’s possible that not all user agents that rely on certificates issued from the Web PKI support CRLs, given the expectation that the Baseline Requirements require OCSP. Since presenting this proposal in October 2022, we have not heard concerns from certificate consumers or relying party software developers regarding CRL support.

• Opportunity for OCSP Stapling / “must-staple”: In the months leading to this ballot, Server Certificate Working Group discussion focused on the value of OCSP Stapling and future opportunity for usage of the “must-staple” extension to contend with the privacy concerns related to “online” OCSP checks. At that time (February 2023) it was estimated that:

• the “must-staple” extension was only present in approximately .0622% of time-valid TLS server certificates that assert a CA/Browser Forum policy OID.
• that approximately 8% of connections in Firefox 110 Beta served a stapled response (only known public telemetry).

Independent of usage statistics, relying parties can’t consistently depend on OCSP stapling for security unless responses are stapled on all connections. Further, even if the web server ecosystem had improved support for OCSP-stapling and we could require the use of the “must-staple” extension, we’d remain dependent upon robust and highly-reliable OCSP services, which have been an ongoing ecosystem challenge (1 and 2).

• Adoption of SC-61: SC-61 introduced requirements related to revocation reason codes into Section 7.2.2 of the Baseline Requirements. These requirements were integrated into the proposed updates to Section 7.2 (CRL Profile). This doc presents a mapping of the SC-61 language as it is presented in this proposal, given some language was changed.  

Summarizing Comments and Questions Resulting from Server Certificate Working Group Public Discussion

(last updated May 3, 2023 at 7:30 AM ET):

Comments:

1. Dimitris:

• emphasized the ballot changes existing CRL requirements, and that CAs should be aware of these changes.
• questioned whether the newly proposed issuance frequency (at least once every 24 hours) makes sense for CAs that aren’t actively issuing certificates.
• questioned whether the newly proposed issuance frequency (at least once every 24 hours) makes sense for CAs that are actively issuing certificates, given the Apple Root Store Policy implies Apple checks for new CRLs every 4 hours.
• proposed changes to the issuance frequency depending on whether or not leaf certificates were revoked during the period between the last CRL’s “thisUpdate” time and the expected subsequent publication (which may not be the same time as described in the last CRL’s “nextUpdate” time.)
• Aaron proposed an alternative approach to address the concerns related to CRL issuance frequency, and indicated, instead, a preference for a “carve-out” for CAs that have not issued any certificates
• Dimitris offered clarification on prior comments (re: new CRLs every 4 hours), and appeared to agree with Aaron’s carve-out proposal.
• Aaron requested further clarification related to the 4 hour requirement and how it would be meaningfully measured.
• Dimitris offered clarification. He also reinforced that increasing CRL issuance frequency when there are no changes to the contents of the revoked certificates list does not increase security.
• Aaron emphasized the value of automation, and described how a set schedule is easier, safer, and more reliable than a variable schedule based on additional criteria. Aaron expressed a preference for the 24 hour timeline.
• Dimitris emphasized the BRs are the minimum requirements and are not meant to be overly prescriptive. CAs should be free to choose how they satisfy the minimum requirements. Agrees that CRL issuance frequency is meant to be automated.
• [Ryan attempted to address the concerns above in an updated branch [PR with diffs].]

2. Aaron:

• added some editorial comments on the PR

1. [ryan still needs to address these]

• expressed concern related to the required inclusion of the CRLDistributionPoints extension in subscriber certificates, specifically related to how its inclusion will result in “a number of certificate consumers will begin executing old codepaths and downloading them directly.”

3. Wayne:

•  re-highlighted past concern re: potential effects on the broader ecosystem, specifically clients that rely only on OCSP for revocation checking.
• expressed concern that 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.
• Asked Is there some other reason to begin requiring cRLDPs if the CA chooses to operate an OCSP service after this ballot goes into effect?

Unanswered Questions:

1. [Aaron] Can CA owners share:

• How many certificates you have which embed a CRLDP?

1. While not a CA, Chrome Root Program shared some data via Censys query re: use of CRLDP today. Interpretation of the results is that ~35% of all time-valid leafs asserting a BR certificate policy OID contain a CRLDP, and that ~88% of the issuing CAs issuing those leafs include CRLDP by default on 100% of certs issued (that contain a BR policy OID). Feedback on the queries to offer more accurate results are welcome.

• How many requests-per-second you receive for that CRLDP as a result?

Summarizing GitHub Comments & Adjudication