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.

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.

[ryancdickson]

Mostly nits!

[cairnsc]

Thanks for considering my comments so far, Martijn. I don't seem to be able to reopen the thread at #622 (comment) so I'm raising it here again.

My suggestion: "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 MAY support the use of a SHA-256 fingerprint as an identifier; and"

[XolphinMartijn]

@cairnsc Would you be OK adding the fingerprint as a SHOULD?

The CA may support any identifier, SHOULD puts a bit more of a emphasis on it, I'd say

[cairnsc]

Yes, I think that making it a SHOULD is quite reasonable and agree with your reasoning.

[cairnsc]

In speaking about this draft with a colleague, he suggested it might also be helpful to be explicit about requiring the fingerprint of the precert to be supported as well. What do you think?

[ryancdickson]

I agree with @cairnsc's suggestion - hashes included in actionable problem reports shouldn't just be limited to those corresponding to final certificates.

A CA Owner being provided with a hash of either the precertificate or the final certificate should be sufficient to begin the investigation.

[XolphinMartijn]

Yea, on the one hand, I'd say precertificates are incorporated in the Certificate definition, but in this case it seems it may be a good clarification.

Proposing this:

Suggested change

	1. at least one serial number or SHA-256 fingerprint of a time-valid and unrevoked Certificate issued by the CA; 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"