Draft Ballot SC-XX: Improve Certificate Problem Reports and Clarify the Meaning of Revocation #622
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -502,6 +502,10 @@ The script outputs: | |
|
|
||
| [https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml](https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml) | ||
|
|
||
| **Revoked**: Effective 2026-05-15, a Certificate is considered revoked if: | ||
| - a CRL Distribution Point URI is present and the referenced CRL contains the Certificate's serial number; or | ||
| - an Authority Information Access OCSP URI is present and an OCSP response for the Certificate's serial number indicates a `certStatus` value of `revoked`. | ||
|
|
||
| **Root CA**: The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates. | ||
|
|
||
| **Root Certificate**: The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs. | ||
|
|
@@ -1532,18 +1536,48 @@ The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscri | |
|
|
||
| ### 4.9.3 Procedure for revocation request | ||
|
|
||
| Prior to 2026-05-15, for Section 4.9.3 of these Requirements, the CA SHALL adhere to these Requirements or Version 2.1.9 of the Baseline Requirements for TLS Server Certificates. Effective 2026-05-15, the CA SHALL adhere to these Requirements. | ||
|
|
||
| The CA's Certificate Policy or Certification Practice Statement MUST describe a process for Subscribers to request revocation of their own Certificates. | ||
|
|
||
| The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests. | ||
|
|
||
| The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions in Section 1.5.2 of their CPS and SHOULD additionally disclose the instructions through readily accessible online means (e.g. a KB article, dedicated webpage, FAQ). | ||
|
|
||
| Within twenty-four (24) hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to the report and determine if it's "actionable." | ||
|
|
||
| A Certificate Problem Report is considered actionable if it includes: | ||
| 1. at least one serial number or SHA-256 fingerprint of a time-valid and unrevoked Certificate issued by the CA; and | ||
| 2. a description of either: | ||
|
There was a problem hiding this comment. 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.
Member
Author
There was a problem hiding this comment. 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 There was a problem hiding this comment. 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. |
||
| - how the Certificate(s) in question violates these Requirements 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](#491-circumstances-for-revocation)). | ||
|
|
||
| A CA MAY take measures to prevent submission of non-actionable Certificate Problem Reports (e.g., input control validation on a form used to collect Certificate Problem Reports), but MUST be able to receive actionable Certificate Problem Reports. | ||
|
|
||
| Within twenty-four (24) hours after determining a Certificate Problem Report is actionable: | ||
| 1. The CA SHALL provide a report on its findings to the entity who filed the Certificate Problem Report, if contact details have been provided. | ||
XolphinMartijn marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| 2. The CA SHOULD provide a report on its findings to applicable Subscriber(s). | ||
| 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). | ||
|
|
||
| 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 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. | ||
|
|
||
| **Note**: If a non-actionable Certificate Problem Report is later amended by the reporter to satisfy the requirements of an actionable report described above, the time of receipt of the requested missing information is the basis for subsequent revocation timelines, if determined necessary. | ||
|
|
||
| ### 4.9.4 Revocation request grace period | ||
|
|
||
| No stipulation. | ||
|
|
||
| ### 4.9.5 Time within which CA must process the revocation request | ||
XolphinMartijn marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| Prior to 2026-05-15, for Section 4.9.5 of these Requirements, the CA SHALL adhere to these Requirements or Version 2.1.9 of the Baseline Requirements for TLS Server Certificates. Effective 2026-05-15, the CA SHALL adhere to these Requirements. | ||
|
|
||
| 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](#4911-reasons-for-revoking-a-subscriber-certificate). | ||
|
There was a problem hiding this comment. 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?
Member
Author
There was a problem hiding this comment. 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
Contributor
There was a problem hiding this comment.
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.
Member
Author
There was a problem hiding this comment. 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? There was a problem hiding this comment. 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. There was a problem hiding this comment. 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. |
||
|
|
||
| The period between the determination that a Certificate Problem Report is actionable and published revocation MUST NOT exceed the time frame set forth in [Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate). | ||
|
|
||
| The date selected by the CA SHOULD consider the following criteria: | ||
|
|
||
| 1. The nature of the alleged problem (scope, context, severity, magnitude, risk of harm); | ||
| 2. The consequences of revocation (direct and collateral impacts to Subscribers and Relying Parties); | ||
|
|
@@ -1575,10 +1609,9 @@ CAs issuing CA Certificates: | |
| 1. MUST update and publish a new CRL at least every twelve (12) months; | ||
| 2. MUST update and publish a new CRL within twenty-four (24) hours after recording a Certificate as revoked. | ||
|
|
||
| Issuing CAs MUST continue issuing CRLs until one of the following is true: | ||
| - all CA Certificates containing the same Subject Public Key are expired or revoked; OR | ||
| - the Private Key for the Issuing CA has been destroyed. | ||
|
|
||
| ### 4.9.8 Maximum latency for CRLs (if applicable) | ||
|
|
||
|
|
@@ -1630,6 +1663,8 @@ No Stipulation. | |
|
|
||
| See [Section 4.9.1](#491-circumstances-for-revocation). | ||
|
|
||
| Effective 2026-05-15, the CA's Certificate Policy or Certification Practice Statement MUST describe the circumstances that necessitate the CA to (1) reject subsequent certificate requests containing the same public key and (2) perform a cascading revocation of all time-valid certificates containing the same public key when the revocation reason of a revocation is "Key Compromise", | ||
|
|
||
| ### 4.9.13 Circumstances for suspension | ||
|
|
||
| The Repository MUST NOT include entries that indicate that a Certificate is suspended. | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.