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. 😉

[aww-aww]

nit: s/receiving a/receiving a properly submitted and complete/

[ryancdickson]

I’d respectfully push back on this one, for a few reasons:

1. The ballot intentionally establishes an objective definition of what makes a report "actionable", rather than relying on subjective or undefined terms like "complete."

2. CAs are already required to disclose clear CPR submission instructions in Section 1.5.2 of their CPS, and this update explicitly permits CAs to use input control validation (e.g., on a web form) to prevent the submission of incomplete/non-actionable reports at intake. IMO, those seem like the “right” tools for managing intake quality.

3. The purpose of this initial 24-hour window is to assess the report for actionability - and if it is not actionable (i.e., incomplete), it requires the CA within 24 hours to notify the reporter and request the missing information. If the 24-hour clock only started after a report was already "complete," an incomplete report would never trigger the 24-hour review or the obligation to request the missing details from the reporter.

If the concern is that spam or malformed submissions shouldn't each start a 24-hour investigation, I'd rather address that in the "A CA MAY take measures to prevent submission of non-actionable Certificate Problem Reports..." sentence if you feel it’s not already covered.

[ryancdickson]

In response to discussion, consider adding something like:

Suggested change

	**Certificate Problem Report**: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates. A revocation request submitted by the Subscriber of the identified Certificate, or by a party authorized to act on that Subscriber's behalf, is not a Certificate Problem Report.

[ryancdickson]

In response to discussion, consider adding something like

Suggested change

	A revocation request submitted by the Subscriber of the identified Certificate, an entity with demonstrated access to the Certificate's Private Key, or an account key (e.g., an ACME account key) authorized to make requests on behalf of the Subscriber is considered a Subscriber revocation request and NOT a Certificate Problem Report. Where a report is received through the CA's Certificate Problem Report channel and the CA authenticates the requester as the Subscriber (or as possessing the Certificate's Private Key or an authorized account key), the CA SHALL handle it as a Subscriber revocation request under [Section 4.9.5](#495-time-within-which-ca-must-process-the-revocation-request). This does not affect the CA's obligations with respect to Key Compromise, including where the demonstration of access is itself evidence of Key Compromise, or the CA's obligations under this Section where the report also describes how a Certificate violates these Requirements or the CA's own policies.

[trevolipamzn]

Is the intent of this to remove the 24 hour investigation in section 4.9.5? Is there a thought that today a subscriber request is 24 hours to investigate + 24 hours to revoke? If so I think we should probably rework the sections in general to consolidate processing times to that section.
React

[ryancdickson]

Is the intent of this to remove the 24 hour investigation in section 4.9.5?

I’m not sure I follow - can you please explain? What 24-hour investigation period currently exists for Subscriber initiated revocation?

I read 4.9.1.1 (“Reasons for Revoking a Subscriber Certificate”) to state that all Subscriber initiated revocation (e.g., points 1 and 2) must be completed within 24 hours from the time of request - there is no investigation period.

While 4.9.5 (today) commingles Subscriber initiated revocation requests and Certificate Problem Reports, this proposed ballot attempts to separate them. I also read the 24 hour requirement in 4.9.5 to be specific only to Certificate Problem Reports - not Subscriber initiated revocation (mostly because of the “Within 24 hours after receiving a Certificate Problem Report” lead-in”).

Is there a thought that today a subscriber request is 24 hours to investigate + 24 hours to revoke? If so I think we should probably rework the sections in general to consolidate processing times to that section.

Though addressed above - no, there is no thought that there’s a 24 hour investigation period for Subscriber initiated revocation requests. If a Subscriber initiates their own revocation (e.g., through a customer portal or using ACME) - it’s unclear what needs to be investigated.

The proposed 24 hour investigation period is for Certificate Problem Reports (e.g., somebody reports via the CPS’ defined problem reporting mechanism “Your policy says X, your certificates do Y”) - where the CA Owner needs (and deserves) time to corroborate the claim and scope next steps.

[ryancdickson]

In response to discussion:

Suggested change

	- a reason for Certificate revocation (e.g., a demonstration of Key Compromise, or a Subscriber request aligned with [Section 4.9.1](#491-circumstances-for-revocation)).
	- a reason for Certificate revocation (e.g., a demonstration of Key Compromise).

[ChristopherRC]

In response to the "3. Scope of “all time-valid and unrevoked Certificates issued by the CA”" question on list.

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 organization MUST complete an evaluation of all time-valid and unrevoked Certificates it has issued 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).

[aarongable]

I quite like the overall shape this has arrived at. A couple minor / editorial nits.

[aarongable]

Including this info in a standalone CP isn't appropriate; that document places requirements on CAs, not communicates about how CAs fulfill requirements. A description of a CA's revocation process belongs in a CPS, not a CP.

Suggested change

	The CA's Certificate Policy or Certification Practice Statement MUST describe a process for Subscribers to request revocation of their own Certificates.
	The CA's Certification Practice Statement or combined CP/CPS MUST describe a process for Subscribers to request revocation of their own Certificates.

[aarongable]

Suggested change

3. If the CA determines the Certificate Problem Report requires an action of revocation for the Certificate(s) specified within, the CA SHOULD work with the applicable Subscriber to determine the date and time which the CA will revoke the Certificate. The period from the time the Certificate Problem Report was determined actionable to published revocation MUST NOT exceed the time frame set forth in [Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate).

3. If the CA determines the Certificate Problem Report requires an action of revocation for the Certificate(s) specified within, the CA SHOULD work with the applicable Subscriber to determine the date and time at which the CA will revoke the Certificate. The period from the time the Certificate Problem Report was determined actionable to published revocation MUST NOT exceed the time frame set forth in [Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate).

[aarongable]

It feels like this section needs a carve-out for when the report is considered Actionable because it includes "a reason for Certificate revocation (e.g., a Subscriber request aligned with Section 4.9.1)". It's impossible for such a request to affect other certificates in the CA's valid corpus, so there should be no obligation for them to conduct a search.