Skip to content
Open
Changes from 46 commits
Commits
Show all changes
49 commits
Select commit Hold shift + click to select a range
270572f
Clarify the meaning of revocation
ChristopherRC Jan 21, 2025
a37126e
fix typo
ChristopherRC Jan 21, 2025
c704cd0
improve the usefulness of CPRs
ChristopherRC Jan 21, 2025
4a6b8ce
fix smart quote and bump BR version number references
ChristopherRC Jan 21, 2025
bd57535
Merge branch 'cabforum:main' into improveCPRs-2
ChristopherRC Jun 13, 2025
ab72e67
Nit - fix bullet points
ChristopherRC Jun 13, 2025
7612e9d
Merge pull request #1 from ChristopherRC/improveCPRs-2
XolphinMartijn Oct 2, 2025
5c81321
Update effective dates and add more permissive language
XolphinMartijn Oct 2, 2025
df07211
fix: Utilize "MUST evaluate"
XolphinMartijn Oct 15, 2025
31a6479
Update docs/BR.md
XolphinMartijn Nov 11, 2025
be40b46
Update docs/BR.md
XolphinMartijn Nov 11, 2025
342ff48
use "applicable Subscriber"
XolphinMartijn Nov 11, 2025
65085bd
Linebreak
XolphinMartijn Nov 11, 2025
4bb06c1
Linebreak
XolphinMartijn Nov 11, 2025
594427d
Character replacement
XolphinMartijn Nov 11, 2025
91f8e5e
Update docs/BR.md
XolphinMartijn Nov 13, 2025
4e43a30
Update docs/BR.md
XolphinMartijn Nov 13, 2025
cf05e90
Use Key Compromise term
XolphinMartijn Nov 18, 2025
332ac9e
Update docs/BR.md
XolphinMartijn Nov 18, 2025
a2a51e2
fix: Revert language based on feedback, removing "Subordinate"
XolphinMartijn Nov 26, 2025
b4bb5c5
Utilize Issuing CAs
XolphinMartijn Nov 26, 2025
9093e46
Move 4.4.4 into 4.9.3
XolphinMartijn Nov 26, 2025
9642e7b
"Revoked" defined term
XolphinMartijn Nov 26, 2025
0b97d0d
Move Key Compromise language to 4.9.12
XolphinMartijn Nov 26, 2025
0f2553b
Don't call out attachments specifically
XolphinMartijn Nov 26, 2025
c32f356
Remove "revocation requests or"
XolphinMartijn Dec 2, 2025
ef4e201
Simplify the Revoked language
XolphinMartijn Dec 3, 2025
f0b7e46
Simplify the Revoked language
XolphinMartijn Dec 3, 2025
2ad1582
Update docs/BR.md
XolphinMartijn Dec 3, 2025
f010ab1
Update docs/BR.md
XolphinMartijn Dec 3, 2025
fb938d0
Update docs/BR.md
XolphinMartijn Dec 3, 2025
572ee86
Apply suggestions from code review
XolphinMartijn Dec 3, 2025
9db978c
Add contact-details carve-out
XolphinMartijn Dec 4, 2025
8193abc
Use SHA256 fingerprint
XolphinMartijn Dec 5, 2025
53df8aa
Use "information"
XolphinMartijn Jan 19, 2026
339b88d
Add Subscriber revocation requests authentication language
XolphinMartijn Jan 19, 2026
90856b8
Merge branch 'main' into CPR_Revamp
XolphinMartijn Jan 19, 2026
2840471
Update "Revoked" definition
XolphinMartijn Jan 19, 2026
d25aa9b
"and" no longer required
XolphinMartijn Jan 19, 2026
d7c86f8
Update docs/BR.md
XolphinMartijn Feb 24, 2026
267cdf4
Update effective date
XolphinMartijn Mar 16, 2026
9112942
Update Baseline Requirements version in BR.md
XolphinMartijn Mar 18, 2026
6cf96bd
Update docs/BR.md
XolphinMartijn Mar 18, 2026
d4df4e7
Update docs/BR.md
XolphinMartijn May 21, 2026
4751419
Update docs/BR.md
XolphinMartijn May 21, 2026
bcee0b8
Update docs/BR.md
XolphinMartijn Aug 25, 2026
a0722b0
Update docs/BR.md
XolphinMartijn Aug 31, 2026
ef1dda7
Update docs/BR.md
XolphinMartijn Sep 1, 2026
a45b4ac
Push out effective date
XolphinMartijn Sep 2, 2026
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 43 additions & 8 deletions docs/BR.md
Original file line number Diff line number Diff line change
Expand Up @@ -517,6 +517,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-09-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`.

**Reverse Zone Domain Name**: the FQDN in the `.arpa` namespace that corresponds to an IP address. This FQDN is constructed by converting the IP address to a sequence of labels followed by the applicable IP Reverse Zone Suffix, as specified in RFC 1035 (for IPv4 addresses) and RFC 3596 (for IPv6 addresses).

**Root CA**: The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.
Expand Down Expand Up @@ -1600,18 +1604,48 @@ The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscri

### 4.9.3 Procedure for revocation request
Comment thread
XolphinMartijn marked this conversation as resolved.

The CA SHALL provide a process for Subscribers to request revocation of their own Certificates. The process MUST be described in the CA's Certificate Policy or Certification Practice Statement. The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports.
Prior to 2026-09-15, for Section 4.9.3 of these Requirements, the CA SHALL adhere to these Requirements or Version 2.2.5 of the Baseline Requirements for TLS Server Certificates. Effective 2026-09-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 highly available systems to accept revocation requests and Certificate Problem Reports, and the personnel and procedures to meet the response deadlines specified in these Requirements.

The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for submitting Certificate Problem Reports. 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 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"
Comment thread
XolphinMartijn marked this conversation as resolved.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

2. information about either:
- 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.

Comment thread
XolphinMartijn marked this conversation as resolved.
Within twenty-four (24) hours after determining a Certificate Problem Report is actionable:
Comment thread
XolphinMartijn marked this conversation as resolved.
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.
Comment thread
XolphinMartijn marked this conversation as resolved.
2. The CA SHOULD provide a report on its findings to applicable Subscriber(s).
Comment thread
XolphinMartijn marked this conversation as resolved.
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).
Comment thread
XolphinMartijn marked this conversation as resolved.

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 through a readily accessible online means and in Section 1.5.2 of their CPS.
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).
Comment thread
XolphinMartijn marked this conversation as resolved.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(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:")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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.
Comment thread
XolphinMartijn marked this conversation as resolved.
Outdated
Comment thread
XolphinMartijn marked this conversation as resolved.
Outdated

**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.
Comment thread
XolphinMartijn marked this conversation as resolved.

### 4.9.4 Revocation request grace period

No stipulation.

### 4.9.5 Time within which CA must process the revocation request
Comment thread
XolphinMartijn marked this conversation as resolved.

Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report.
After reviewing the facts and circumstances, the CA SHALL work with the Subscriber and any entity reporting the Certificate Problem Report or other revocation-related notice to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate. The period from receipt of the Certificate Problem Report or revocation-related notice to 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:
Prior to 2026-09-15, for Section 4.9.5 of these Requirements, the CA SHALL adhere to these Requirements or Version 2.2.5 of the Baseline Requirements for TLS Server Certificates. Effective 2026-09-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). 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);
Expand Down Expand Up @@ -1643,10 +1677,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.

CAs MUST continue issuing CRLs until one of the following is true:
- all Subordinate CA Certificates containing the same Subject Public Key are expired or revoked; OR
- the corresponding Subordinate CA Private Key is destroyed.

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)

Expand Down Expand Up @@ -1698,6 +1731,8 @@ No Stipulation.

See [Section 4.9.1](#491-circumstances-for-revocation).

Effective 2026-09-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 a known compromised public key and (2) perform a cascading revocation of all unexpired and unrevoked certificates containing the same compromised public key when the revocation reason of a revocation is "Key Compromise",
Comment thread
XolphinMartijn marked this conversation as resolved.
Outdated

### 4.9.13 Circumstances for suspension

The Repository MUST NOT include entries that indicate that a Certificate is suspended.
Expand Down