Draft Ballot SC-XX: Improve Certificate Problem Reports and Clarify the Meaning of Revocation

13 views

Skip to first unread message

Martijn Katerbarg

unread,

5:24 AM (10 hours ago) 5:24 AM

to 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum)

All,

The topic of changes around CPRs was discussed briefly at the last F2F. Already last year, there were a few discussions on proposing a ballot to improve the CPR language and clarify the meaning of revocation.

I’ve just created a PR with proposed language. The PR can be found at https://github.com/cabforum/servercert/pull/622

First of all, thank you to the Chrome Root Program for drafting the majority of this ballot. The draft ballot proposed an effective date for 2026-05-15.

Purpose:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to promote high-quality and actionable Certificate Problem Reports. To align community expectations, reduce ambiguity within the TLS BRs, and promote consistent practices across the Web PKI, the ballot also clarifies the meaning of “revocation.”

Background:
This ballot intends to accomplish two objectives.

Objective 1: Improve the usefulness of Certificate Problem Reports and create opportunities for improved CA Owner response.

Justification:
Public incident reporting has identified some challenges with Certificate Problem Reports. For example, an Incident Report [1] identified a scenario where a Certificate Problem Report was delivered to a CA Owner and problematic certificate serial #’s, though known, were intentionally withheld by the third party reporter. Other Incident Reports [2][3] identified scenarios where Certificate Problem Report mechanisms did not allow for the submission of suspected Private Key Compromise.
The absence of actionable detail in Certificate Problem Reports impedes upon their intended function and needlessly slows CA Owner response, representing risk to the ecosystem.
Defining minimum expectations for the contents of Certificate Problem Reports creates opportunities to improve CA Owner response and promotes more effective and efficient report investigation.

Approach:
This ballot separates the concepts of revocation requests and Certificate Problem Reports, which may or may not require certificate revocation.
This ballot establishes a threshold for the minimum set of data included in a Certificate Problem Report for it to be considered “actionable.”
Actionable reports include:
at least one serial number or hash of a time-valid and unrevoked Certificate issued by the CA, either directly or transitively (e.g., by attaching a Certificate file);
AND, EITHER:
a description of either how the Certificate(s) in question violate the TLS BRs or a CA's own policies; OR
a reason for Certificate revocation (e.g., a demonstration of key compromise, or a Subscriber request aligned with Section 4.9.1).
This ballot further introduces:
Within 24 hours of receiving any Certificate Problem Report, the CA must determine if it’s actionable.
Within 24 hours after determining a Certificate Problem Report is actionable, the clock for the set of existing activities described in Sections 4.9.5 and 4.9.1 (if applicable) are considered to start.
Within 24 hours after determining a Certificate Problem Report is NOT actionable, the CA MUST provide a preliminary report on its findings to the entity who filed the report and request the information necessary to satisfy the above requirements of an actionable Certificate Problem Report.

Benefits of adoption:
This approach introduces an additional, but well-defined period of time for the CA Owner to investigate actionable reports before upholding existing Certificate Problem Reporting expectations.
CAs are provided with more meaningful Certificate Problem Report information to aid in investigation.
CAs are provided a window of time to ensure a Certificate Problem Report is actionable before the timeframes specified in Section 4.9.1.1 become effective.

Objective 2: Clarify the meaning of revocation.

Justification:
At least one past conversation on thread [4] has expressed the need to clarify the TLS BRs to convey that revocation is the act of publishing information that reflects the status of the certificate.

Benefits of adoption:
A clear statement of what it means for a certificate to be considered revoked that can be used to correlate the obligations on revocation timelines.