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]

I appreciate how this proposal considers the time to determine whether a problem report is actionable.

There may also be some lead time involved in handling a request from a Subscriber, namely in authenticating them as the Subscriber. For example, an ACME CA might only support authentication using a key. If it takes 23 hours for them to respond, that could be a problem. Could this proposal explicitly state something along the lines of "The period between receipt of a revocation request from the Subscriber once they have verified their identity" or something along those lines?

[XolphinMartijn]

I'm hesitent on this.. as such a carve-out here would also then trickle down into any type of revocation request, including automated ones.

How often does an ACME CA get a manual revocation request?

From our own experience, it's pretty much never. Based on that, I don't believe the negative side-effect us such a change, warrents making it

[aarongable]

How often does an ACME CA get a manual revocation request?

Far too often. Manual reports to our problem reporting address -- often from folks who recently bought a domain and want to revoke a prior domain-parker's cert for it, or folks who are recovering from a compromise and want to revoke a malicious actor's cert -- consume an inordinate amount of our time. In terms of proportions it is of course completely drowned out by ACME protocol revocation requests, but a small org can't afford to handle even a few manual requests per week.

[XolphinMartijn]

Thanks @aarongable, though maybe I should have been more clear in my question.

Based on what you're describing, those aren't directly a revocation request by the Subscriber, but rather all of these sounds like they're a Certificate Problem Report filed by third parties (the new domain owner is in this case still a third-party).

My question was more based on Cade's request, hinting on the Subscriber filing a manual revocation request, and the need to identify them as the Subscriber. So let me rephrase: How often does an ACME CA get a manual revocation request from the Subscriber themselves?

[cairnsc]

Good point about the carve-out leaking into how any type of revocation request is handled.

In response to your question: we don't receive manual revocation requests from the subscriber very often. In our particular case, most often we receive CPRs from domain owners whose service providers legitimately obtain a certificate on their behalf. Like Aaron, we have a relatively small org and receiving these can be quite time consuming (we, too, are built more around emphasizing the use of automation).

Although such subscriber requests are infrequent, I hoped to avoid a situation where a CA might be held accountable due to perceived non-conformance in such a scenario due to factors outside of their control. I don't know the best answer, so here's a first shot at a modification:

The period between receipt of a revocation request from the Subscriber and published revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1. If the revocation request is not authenticated upon receipt, within 24 hours of receipt of the request, the CA SHALL work with the requester to authenticate them as the Subscriber, at which point the period between the request is authenticated and published revocation applies.

It's not sufficient, but I think the "not authenticated upon receipt" provides a sufficient carve-out to distinguish it from e.g. ACME or logging in via a web portal.

[cairnsc]

I asked Gemini to be a little more concise:

The period between receipt of a revocation request from the Subscriber and published revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1. If the request is not authenticated upon receipt, the CA SHALL within 24 hours of receipt work with the requester to authenticate the request, and the period listed above will be measured from the time of authentication.

[cairnsc]

A description implies free-form text to me. Could this be at tension with the use of forms that allow selection of a reason from a list?

GTS implements a form that requires the reporter to select the revocation reason from radio boxes based on the revocation reasons specified in 4.9.1.1. Part of the motivation for doing this to avoid ambiguity and honor the reason specified when the reporter is the subscriber, which Mozilla's CA/Revocation Reasons emphasizes. There's a free-form text box that allows further information to be specified if necessary.

[XolphinMartijn]

@cairnsc

I think this makes a difference on wether something is a CPR, or a revocation request by the subscriber. For the latter, I'd say yes, a dropdown with the revocation reason is sensible. For a CPR, mostly used by third-parties less so. In case of a CPR by a third party, they don't get to decide the revocation reason, but that should be up to the CA.

Now if the same form is used for both, which I can understand may be desirable, sure. But in that case it may be up to the CA to determine if something is a revocation request, or rather a CPR.

I don't see how an actual CPR could be handled, without a description of the issue

[cairnsc]

I agree that an actual CPR by a reporter who is not the subscriber requires additional information.

Can it say "information about either" instead of "a description of either", so CAs have a bit more discretion in how the flow is implemented? I want to avoid "description" being taken to mean a written representation, when there might be other ways to get the information a CA needs. For example, a questionnaire designed to make it easier for the reporter to provide a reason or have it direct to the correct people or automated process to handle it.