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

[XolphinMartijn]

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, unless the CA can reasonably claim the report is spam.

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.

Thank you to the Chrome Root Program for drafting the majority of this ballot

[aarongable]

The number of comments I've left below might seem to suggest that I don't like this draft -- on the contrary, I think this is taking the BRs in a really good direction. I just have lots of nits to pick about exact organization and phrasing.

[dzacharo]

Great effort and great discussion. I am very optimistic that this ballot will solve a lot of practical problems caused by the current language.

[XolphinMartijn]

@dzacharo I can't reply to your comments for some reason, so here's a separate comment.

What if the CPR doesn't include the population of affected certificates and is a claim that the CA has violated its CP/CPS, e.g. in a certificate profile section? While this proposed language covers cases like "compromised keys" or "incorrect subject information" or "invalid CAA or DCV", there are CPRs that claim that all issued certificates are invalid.
Strictly following this definition, unless the reporter enumerates all certificates, the CPR may be considered "non-actionable".

I don't agree here. In such a case, a single enumarated certificate is enough for the CA to determine the report is actionable (which does not by default mean there is a compliance issue)

For the cases of CPRs claiming23 mass-revocation (i.e. the CPR claims that a very large number or % of the CA's issued certificates need to be revoked), 24 hours is hardly enough to reach a safe conclusion about whether a CPR is actionable or not. Perhaps create a separate category where if the CPR claims the revocation of more than X% (25%?) of the CA's currently non-expired, non-revoked certificates, allow 72 hours (just a suggestion) to make the determination whether it's actionable or not.

This seems to confuse classing a report as "actionable", against "having to take each and every action related to the report" within 24 hours.

If such a report comes in and contains a single certificate reference, the report itself is actionable. That then starts the 24 hour clock for a preliminary response. If a CA needs more time to determine if all certificates are affected or not, they have time for any certificates who's identifiers were not included in the report.

[romanf]

From our experience, we also don't see any support questions or other things (apart from spam/phishing) on the CPR mailbox. Of course, I still would include a CAPTCHA in a webform. 😉

[ChristopherRC]

Suggested change

Within twenty four (24) hours after determining a Certificate Problem Report is not actionable, the CA MUST provide a report on its findings to the entity who filed the Certificate Problem Report if contact details have been provided and request the information necessary to satisfy the above requirements of an actionable Certificate Problem Report, unless the CA can reasonably claim the Certificate Problem Report is unrelated to the compliance or security of certificates it issued.

Within twenty-four (24) hours after determining a Certificate Problem Report is not actionable, the CA MUST provide a report on its findings to the entity who filed the Certificate Problem Report if contact details have been provided and request the information necessary to satisfy the above requirements of an actionable Certificate Problem Report, unless the CA can reasonably claim the Certificate Problem Report is unrelated to the compliance or security of certificates it issued.

[ryancdickson]

Suggested change

Within one hundred twenty (120) hours after determining a Certificate Problem Report is actionable, the CA MUST evaluate all time-valid and unrevoked Certificates issued by the CA to detect additional instances of the non-compliance described in the report. The period from the time the additional affected Certificates were first identified to published revocation MUST NOT exceed the time frame set forth in [Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate).

Within one-hundred-twenty (120) hours after determining a Certificate Problem Report is actionable, the CA MUST evaluate all time-valid and unrevoked Certificates issued by the CA to detect additional instances of the non-compliance described in the report. The period from the time the additional affected Certificates were first identified to published revocation MUST NOT exceed the time frame set forth in [Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate).

[ryancdickson]

(nit, for consistency with other numerical spellings in the BRs (e.g., "Within twenty-four (24) hours of issuing its first Certificate, the CA MUST generate and publish either:")

[ryancdickson]

(Forgive me if we've already discussed the following.)

Beyond improving Certificate Problem Reporting, this ballot also intends to address #252.

One aspect of revocation raised in #252 is ensuring that revocation status is reliably and consistently communicated across all serving infrastructure. Issue #252 specifically called out how CDNs and multi-point distribution can undermine that reliability if edge caches are out of sync.

Example:

A CA uses a CDN to serve its CRLs and OCSP responses across 5 globally distributed edge POPs. Following a revocation event:

• 3 of the endpoints serve updated responses reflecting the revocation (e.g., CRL number 101 or OCSP certStatus: revoked).
• 2 of the endpoints serve cached, stale responses (e.g., CRL number 100 or OCSP certStatus: good).

As the definition is written ("a CRL is available", "an OCSP request results in..."), a CA could technically argue compliance because the updated status is available at that URI if routed to POPs 1, 2, or 3. However, any Relying Party routed to POPs 4 or 5 would receive stale status and continue to trust a compromised or misissued certificate.

(Note: This is strictly about the CA's serving infrastructure and CDNs. Client-side caching by browsers/user agents should be considered governed separately by validity periods and HTTP caching directives, as local client cache hits do not actually reach the URI).

To ensure a certificate is only considered revoked when the status is consistently visible across all serving endpoints, I suggest updating the definition:

From

Revoked: Effective 2027-02-15, the following conditions must be met for a Certificate to be considered revoked:

• if the certificate contains a CRL Distribution Point URI: a CRL containing the certificate serial number is available for consumption by Relying Parties at that URI.
• if the certificate contains an Authority Information Access OCSP URI: an OCSP request to that URI for the certificate serial number results in a response with a certStatus value of revoked.

To

Revoked: Effective 2027-02-15, the following conditions must be met for a Certificate to be considered revoked:

• if the Certificate contains a CRL Distribution Point URI: any request to that URI for the CRL (regardless of network perspective or serving endpoint) returns a CRL containing the Certificate's serial number.
• if the Certificate contains an Authority Information Access OCSP URI: any OCSP request to that URI for the Certificate's serial number (regardless of network perspective or serving endpoint) results in a response with a certStatus value of revoked.

If others feel we need to explicitly clarify in the text that client-side caching does not constitute a 'request to that URI,' I'm open to that, though it seems naturally implied.

Also, I know the group typically does not like stuffing requirements-like language in definitions, but this seems sort of unavoidable.

[dzacharo]

ETSI EN 319 411-1 addresses this issue with the following requirements:

"When a TSP supports multiple methods (CRL and OCSP) to provide revocation status:

• CSS-6.3.10-08 [CONDITIONAL]: If a TSP supports multiple methods (CRL and on-line certificate status service) to provide revocation status, any updates to revocation status shall be available for all methods;

• CSS-6.3.10-09 [CONDITIONAL]: If a TSP supports multiple methods (CRL and on-line certificate status service) to provide revocation status, the information provided by all services shall be consistent over time taking into account different delays in updating the status information for all the methods.

NOTE 5: Consistency over time allows for the difference in delays to be taken into account provided that the status of the certificate is ultimately the same and provided REV-6.2.4-03C can be respected. This can be done on the basis of the information provided under CSS-6.3. 10-9A.

EXAMPLE: If OCSP can be updated immediately, OCSP and CRL may differ, until the new CRL has been generated.

• CSS-6.3.10-9A [CONDITIONAL]: If a TSP supports multiple methods (CRL and on-line certificate status service) to provide revocation status and delays in updating the status information for all the methods exist or are possible, the TSP shall document in its CPS the origin of such delays and how to interpret the results in case of differences.

• CSS-6.3.10-10: The revocation status information shall be publicly and internationally available."

Hope this is helpful.

[aarongable]

Dimitris, I don't think that does address the concern. That language is about whether and how quickly OCSP and CRLs become in-sync with each other, not about how quickly just CRLs become consistent with themselves when fetched from multiple different locations.

[ryancdickson]

Suggested change

	1. at least one valid identifier for a time-valid and unrevoked Certificate issued by the CA. The CA MUST support the use of a serial number and SHOULD support the use of a SHA-256 fingerprint of the Certificate and/or Precertificate as an identifier; and"
	1. at least one valid identifier for a time-valid and unrevoked Certificate issued by the CA. The CA MUST support the use of a serial number and SHOULD support the use of a SHA-256 fingerprint of the Certificate and/or Precertificate as an identifier; and

nit: delete lingering quote

[ryancdickson]

Suggested change

Within one hundred twenty (120) hours after determining a Certificate Problem Report is actionable, the CA MUST evaluate all time-valid and unrevoked Certificates issued by the CA to detect additional instances of the non-compliance described in the report. The period from the time the additional affected Certificates were first identified to published revocation MUST NOT exceed the time frame set forth in [Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate).

Within twenty-four (24) hours after determining a Certificate Problem Report is actionable, the CA SHOULD evaluate all time-valid and unrevoked Certificates issued by the CA to detect additional instances of the non-compliance described in the report, and MUST complete this evaluation within one hundred twenty (120) hours of that determination. The period from the time the additional affected Certificates were first identified to published revocation MUST NOT exceed the time frame set forth in [Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate).

---

[This is probably something we’ll raise during the public discussion period, as we think it’s important for everyone to understand what, if passed, this ballot allows. We remain supportive of the improvements introduced by this ballot, but do think there’s some room to further minimize risk, as suggested here.]

I want to make sure we're being completely honest about what this text does in practice.

This ballot takes a huge step forward by closing a significant, long-standing loophole in the BRs. Today, there is no explicit requirement in the BRs to evaluate the corpus when a CPR is received. A CA could technically revoke a single reported serial within 5 days and argue that the BRs imposed no obligation or timeline to scan the rest of its database - forcing community members to enforce corpus-wide discovery entirely through incident response expectations. Codifying a requirement that CAs MUST evaluate their corpus is a major improvement, and one of the reasons we strongly support this effort.

However, while this ballot successfully closes that open-ended loophole, the current drafting introduces a new, bounded variant of the exact same problem. Specifically, granting 120 hours to evaluate the corpus and then starting the revocation clock for additional certificates from the moment they are "first identified" creates a perverse incentive to delay that discovery. This allows for an arbitrary extension to the remediation window or the "schmearing" of revocations over a longer period. The point of this comment is not to debate the merits or likelihood of these practices, but to point out that they are enabled by this text.

Illustrative Scenario

A researcher discovers a systemic certificate profile problem (e.g., an encoding bug or invalid extension - a 5-day revocation reason under Section 4.9.1.1) and submits a Certificate Problem Report citing one serial number. Unknown to the reporter, the CA's database contains thousands of other certificates with the exact same problem.

If we consider today’s BRs compared to “tomorrow’s” (where PR #622 is merged as is):

Milestone	Today (Current BRs)	Tomorrow (PR #622)
CPR Sent & Received (1 serial)	Mon 2026-10-05 09:00 UTC (T+0h)	Mon 2026-10-05 09:00 UTC (T+0h)
Determination that CPR is Actionable	N/A (investigate within 24h)	Tue 2026-10-06 09:00 UTC (T+24h)
Initial Certificate Revocation Due	Sat 2026-10-10 09:00 UTC (T+120h / 5 days)	Sun 2026-10-11 09:00 UTC (T+144h / 6 days)
Corpus Evaluation Deadline	N/A (while this might be a root program expectation, there is no explicit BR requirement)	Sun 2026-10-11 09:00 UTC (T+144h / 120h from actionable)

Currently, under this draft, the revocation clock for additional certificates begins "from the time the additional affected Certificates were first identified." Because the CA has 120 hours to perform the evaluation, the timing of the investigation dictates when the clock starts.

There is also risk depending on when the corpus query occurs:

Behavior	When is Corpus Query Run? ("First Identified")	Revocation Due for Additional Certificates	Total Time from Initial CPR Receipt
Prompt CA (queries immediately)	Tue 2026-10-06 10:00 UTC (T+25h)	Sun 2026-10-11 10:00 UTC	~6 days (145 hours)
Delayed CA (waits until end of 120h window)	Sun 2026-10-11 08:00 UTC (T+143h)	Fri 2026-10-16 08:00 UTC	~11 days (263 hours)
"Schmearing" CA (runs queries in batches)	• Batch 1: Wed Oct 7 (T+48h) • Batch 2: Fri Oct 9 (T+96h) • Batch 3: Sun Oct 11 (T+143h)	• Batch 1: Mon Oct 12 (T+168h) • Batch 2: Wed Oct 14 (T+216h) • Batch 3: Fri Oct 16 (T+263h)	Rolling revocations across Days 7 through 11

Depending on your perspective, this approach could be interpreted as:

1. rewarding procrastination. A CA that immediately investigates and queries its database on Day 1 has to revoke everything by Day 6. A CA that waits until the last minute gets until Day 11. We are effectively rewarding the subscribers of “slow to investigate” CAs with an extra 5 days of validity for misissued certificates.

2. legitimizing revocation "schmearing." A CA can intentionally stagger queries across the 120-hour window to create rolling "first identified" dates, stretching revocations out over a longer period.

3. being really hard to audit. As far as I can tell, there is no reliable way for an auditor to verify when internal scripts were run or when a to-be-revoked certificate was "first identified" in the corresponding output.

If we want to give CAs dedicated time to run queries/investigate issues, we should be honest about these risks (and, we should state them plainly in the ballot’s preamble). In my view, the corpus-level evaluation should be completed within 24 hours of determining a report is actionable. Querying an issuance database for known profile attributes shouldn't take 5 days, and tightening that window removes this perverse incentive. I acknowledge that not all misissuance is as clear-cut as “the CPS says this extension MUST NOT exist, and these certificates contain it” (hence a recommendation of should not must). Updating the CCADB IRGs (e.g., adding CA incident analysis to the “Expected Timeline elements” list) could help better illuminate instances of query delay.

Alternatively, we should anchor the revocation clock for all additional certificates to a single fixed milestone tied to the evaluation window (e.g., within 120 hours of the expiration of the 24 hour evaluation period), rather than tying it to the subjective moment of "first identification."