Cleanup 2025 #628

dzacharo · 2025-10-31T17:26:48Z

No description provided.

…to S/MIME language

…WG call (#639) Resolves #526.

clintwilson · 2025-12-11T23:47:11Z

Based on discussion in the Validation Subcommittee today (Dec 11, 2025), #642 (#642) could be included in this cleanup.

While there was consensus that this change is not necessary to enable the use of RDAP for the purposes of Section 3.2.2.14.1 in the EVGs (due to inherited definition of "WHOIS" from the TBRs), it was agreed that adding clarity would help avoid potential confusion in the future.

dzacharo · 2025-12-12T07:35:28Z

Based on discussion in the Validation Subcommittee today (Dec 11, 2025), #642 (#642) could be included in this cleanup.

While there was consensus that this change is not necessary to enable the use of RDAP for the purposes of Section 3.2.2.14.1 in the EVGs (due to inherited definition of "WHOIS" from the TBRs), it was agreed that adding clarity would help avoid potential confusion in the future.

Fixed with 6bfbe3a

…e references section should also be updated.

…stency

aarongable · 2025-12-18T16:20:13Z

docs/BR.md

+| 2024-03-15 | [4.9.7](#497-crl-issuance-frequency) | CAs MUST generate and publish CRLs. |
+| 2024-09-15 | [4.3.1.2](#4312-linting-of-to-be-signed-certificate-content) | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. |
+| 2025-01-15 | [4.9.9](#499-on-line-revocationstatus-checking-availability) | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. |
+| 2025-01-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information. |
+| 2025-03-15 | [4.3.1.2](#4312-linting-of-to-be-signed-certificate-content) | The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. |
+| 2025-03-15 | [8.7](#87-self-audits) | The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits. |
+| 2025-03-15 | [3.2.2.9](#3229-multi-perspective-issuance-corroboration) | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. |
+| 2025-07-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates. |
+| 2025-12-01 | [5.7.1.2](#5712-mass-revocation-plans) | CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements. |


If we're cleaning up old effective dates, why aren't we cleaning up these ones? What's special about the beginning of 2024 that we're keeping dates after then?

Especially the second item (SHOULD implement Linting) whose corresponding sentence has already been deleted from the body of section 4.3.1.2.

docs/BR.md

aarongable · 2025-12-18T16:36:34Z

docs/BR.md

+  - if using the Registry Data Access Protocol ([RFC 7482](https://datatracker.ietf.org/doc/html/rfc7482)), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain.
+  - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information.
+
+Effective 2025-07-15:


Why are we preserving the text of this method at all? It cannot be used, and its validation data cannot be reused, so it is now fully irrelevant. This ballot should replace this whole section with

This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.

and the corresponding Relevant Dates can be removed from the table in Section 1.2.2.

The convention has been to retain the method until all certs issued using the method have expired.

aarongable · 2025-12-18T16:38:02Z

docs/BR.md

@@ -881,16 +843,17 @@ Confirming the Applicant's control over the FQDN by validating the Applicant is

 **Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.

-Effective January 15, 2025:
+Effective 2025-01-15:


Why are we preserving this effective date? This line should be removed, and the bullet points below it should be promoted to standalone paragraphs.

aarongable · 2025-12-18T16:39:16Z

docs/BR.md

+  - if using the Registry Data Access Protocol ([RFC 7482](https://datatracker.ietf.org/doc/html/rfc7482)), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain.
+  - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information.
+
+Effective 2025-07-15:


Why are we preserving the text of this method at all? It cannot be used, and its validation data cannot be reused, so it is now fully irrelevant. This ballot should replace this whole section with

This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.

and the corresponding Relevant Dates can be removed from the table in Section 1.2.2.

aarongable · 2025-12-18T16:58:50Z

docs/BR.md

+Due to the complexity involved in implementing Certificate Profiles that conform to these Requirements, it is considered best practice for the CA to implement a Linting process to test the technical conformity of each to-be-signed artifact prior to signing it. When a Precertificate has undergone Linting, it is not necessary for the corresponding to-be-signed Certificate to also undergo Linting, provided that the CA has a technical control to verify that the to-be-signed Certificate corresponds to the to-be-signed Precertificate in the manner described by [RFC 6962, Section 3.2](https://datatracker.ietf.org/doc/html/rfc6962#section-3.2).
+
 Effective 2025-03-15, the CA SHALL implement such a Linting process.


Why did we delete one of these effective dates but not the other? It's time to just integrate the requirement into the paragraph.

Suggested change

Due to the complexity involved in implementing Certificate Profiles that conform to these Requirements, it is considered best practice for the CA to implement a Linting process to test the technical conformity of each to-be-signed artifact prior to signing it. When a Precertificate has undergone Linting, it is not necessary for the corresponding to-be-signed Certificate to also undergo Linting, provided that the CA has a technical control to verify that the to-be-signed Certificate corresponds to the to-be-signed Precertificate in the manner described by [RFC 6962, Section 3.2](https://datatracker.ietf.org/doc/html/rfc6962#section-3.2).

Effective 2025-03-15, the CA SHALL implement such a Linting process.

Due to the complexity involved in implementing Certificate Profiles that conform to these Requirements, the CA MUST implement a Linting process to test the technical conformity of each to-be-signed artifact prior to signing it. When a Precertificate has undergone Linting, it is not necessary for the corresponding to-be-signed Certificate to also undergo Linting, provided that the CA has a technical control to verify that the to-be-signed Certificate corresponds to the to-be-signed Precertificate in the manner described by [RFC 6962, Section 3.2](https://datatracker.ietf.org/doc/html/rfc6962#section-3.2).```

aarongable · 2025-12-18T16:59:10Z

docs/BR.md

@@ -1518,7 +1493,7 @@ No stipulation.
 No stipulation.

 ### 4.8.7 Notification of certificate issuance by the CA to other entities
-
+2


Typo

Suggested change

2

aarongable · 2025-12-18T17:00:31Z

docs/BR.md


-OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019. The CA MAY process the Nonce extension (`1.3.6.1.5.5.7.48.1.2`) in accordance with RFC 8954.
+OCSP responders operated by the CA SHALL support the HTTP GET method, as described in [RFC 6960](https://datatracker.ietf.org/doc/html/rfc6960) and/or [RFC 5019](https://datatracker.ietf.org/doc/html/rfc5019). The CA MAY process the Nonce extension (1.3.6.1.5.5.7.48.1.2) in accordance with [RFC 8954](https://datatracker.ietf.org/doc/html/rfc8954).

 For the status of a Subscriber Certificate or its corresponding Precertificate:

 - Effective 2025-01-15, an authoritative OCSP response MUST be available (i.e. the responder MUST NOT respond with the "unknown" status) starting no more than 15 minutes after the Certificate or Precertificate is first published or otherwise made available.


Suggested change

- Effective 2025-01-15, an authoritative OCSP response MUST be available (i.e. the responder MUST NOT respond with the "unknown" status) starting no more than 15 minutes after the Certificate or Precertificate is first published or otherwise made available.

- An authoritative OCSP response MUST be available (i.e. the responder MUST NOT respond with the "unknown" status) starting no more than 15 minutes after the Certificate or Precertificate is first published or otherwise made available.

aarongable · 2025-12-18T17:01:17Z

docs/BR.md

@@ -1955,21 +1939,21 @@ The business continuity plan MUST include:

 #### 5.7.1.2 Mass Revocation Plans

-CA organizations MUST have a mass revocation plan, and as of December 1, 2025, they SHALL assert in section 5.7.1 of their CPS or combined CP/CPS that they maintain a comprehensive and actionable plan for mass revocation events, that they perform annual testing of the mass revocation plan, and that they incorporate lessons learned into such plan in order to continually improve their preparedness for mass revocation events over time.
+CA organizations MUST have a mass revocation plan, and as of 2025-12-01, they SHALL assert in section 5.7.1 of their CPS or combined CP/CPS that they maintain a comprehensive and actionable plan for mass revocation events, that they perform annual testing of the mass revocation plan, and that they incorporate lessons learned into such plan in order to continually improve their preparedness for mass revocation events over time.


Suggested change

CA organizations MUST have a mass revocation plan, and as of 2025-12-01, they SHALL assert in section 5.7.1 of their CPS or combined CP/CPS that they maintain a comprehensive and actionable plan for mass revocation events, that they perform annual testing of the mass revocation plan, and that they incorporate lessons learned into such plan in order to continually improve their preparedness for mass revocation events over time.

CA organizations MUST have a mass revocation plan, and they MUST assert in section 5.7.1 of their CPS or combined CP/CPS that they maintain a comprehensive and actionable plan for mass revocation events, that they perform annual testing of the mass revocation plan, and that they incorporate lessons learned into such plan in order to continually improve their preparedness for mass revocation events over time.

aarongable · 2025-12-18T17:01:56Z

docs/BR.md

-    1. In the case of Debian weak keys vulnerability (https://wiki.debian.org/SSLkeys), the CA SHALL reject all keys found at https://github.com/cabforum/Debian-weak-keys/ for each key type (e.g. RSA, ECDSA) and size listed in the repository. For all other keys meeting the requirements of [Section 6.1.5](#615-key-sizes), with the exception of RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys.
-    2. In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at https://github.com/crocs-muni/roca or equivalent.
-    3. In the case of Close Primes vulnerability (https://fermatattack.secvuln.info/), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat’s factorization method.  
+5. The Public Key corresponds to an industry-demonstrated weak Private Key. For requests submitted on or after 2024-11-15, at least the following precautions SHALL be implemented:


Suggested change

5. The Public Key corresponds to an industry-demonstrated weak Private Key. For requests submitted on or after 2024-11-15, at least the following precautions SHALL be implemented:

5. The Public Key corresponds to an industry-demonstrated weak Private Key. At least the following precautions SHALL be implemented:

srdavidson · 2025-12-29T16:45:46Z

docs/BR.md


-Effective July 15, 2025:
 - The CA MUST NOT rely on this method.
 - Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.

 ##### 3.2.2.4.3 Phone Contact with Domain Contact

 This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.


"certificates" -> "Certificates"
This capitalization varies even from the para before.
There is inconsistency in capitalization of Defined Terms throughout the text.

@srdavidson the phrase "Subscriber Certificate*" appears 64 times with a capital "C" and only once with a lowercase "c"- in section 7.1.2.7.11.
The word "Certificate*" with a capital "C" appears 882 times in the document, while with a lowercase "c" it appears 209 times.
If we want to set broader rules for capitalization, it would be good to create a separate issue for that and include that in a future cleanup.

richardwsmith · 2026-01-12T18:23:06Z

docs/BR.md


-**WHOIS**: Information retrieved directly from the Domain Name Registrar or registry operator via the protocol defined in RFC 3912, the Registry Data Access Protocol defined in RFC 7482, or an HTTPS website.
+**WHOIS**: Information retrieved directly from the Domain Name Registrar or registry operator via the protocol defined in [RFC 3912](https://datatracker.ietf.org/doc/html/rfc3912), the Registry Data Access Protocol defined in [RFC 9082](https://datatracker.ietf.org/doc/html/rfc9082), or an HTTPS website.


This should not be in a cleanup as this changes normative requirements from what was in the old RFC to what is in the new RFC without review of the respective requirements and ensuing discussion.

Good point. Until people have time to read the new RFC, let's use the older RFC.

richardwsmith · 2026-01-12T18:41:59Z

docs/BR.md

@@ -924,20 +887,22 @@ The Random Value SHALL remain valid for use in a confirming response for no more

 **Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.

-Effective January 15, 2025:
+Effective 2025-01-15:


See Aaron's comment about continuing to include past effective dates. This should also simply be removed.

dzacharo added 2 commits October 31, 2025 19:11

Addresses #584

47744bd

Addresses #592

c6dcede

dzacharo requested a review from a team as a code owner October 31, 2025 17:26

karolina-ads and others added 27 commits November 4, 2025 14:38

Addresses #603 - typo IASE -> ISAE

eedf28a

Addresses #496 - phone number example

ced04a0

#303 removed code signing reference

0fa3911

#452 changed SIZE 1..128

6d01919

#547 added v2 to header

e65f153

#540 MUST NOT -> SHOULD NOT

62af9ba

#540 Note about effective dates removed

5eaf69b

#415 changed APPENDIX -> Appendix as in other BR

21af19c

#546 3.2.2.4.4 changed to Email to a Constructed Address

327e12d

#458 changed 4.9.1.1 example 9

a7b16dd

#458 removed 4.9.1.1 example 2 and 3

fbc9a63

#574 header is ok, removed spaces

8f131de

#489 changed RFC 7482 -> 9082 in WHOIS def

306c1c0

#542 added number 1.2.2 to Relevant Dates

d8613da

#428 NTR Registration Scheme identifier definition updated according …

6f7abd6

…to S/MIME language

#193 changed common date format to ISO 8601

04cd765

#193 changed common date format to ISO 8601

e3a751e

#322 removed duplicated by a from sentence

09cd828

#458 fixed numbering sequence

8363555

Addresses #435

42c6eba

#496 changed definition "spaces as visual separators"

cb47fd0

#303 removed "or distribute executable code," and "malware"

3d1c310

#432 table headers bold changed from __ to **

b4631a6

#432 bold changed from __ to **

4e5539a

#432 headers - double spaces

6f5a1e7

Addresses #274.

daf5502

Addresses #444

8286dd0

karolina-ads and others added 20 commits December 2, 2025 00:44

#432 1.3.6.1.5.5.7.48 merge columns Access Method and OID

ee0e509

#432 Access Method and OID table spacing

8a8470b

#432 Access Method and OID table spacing

16721b9

#193 date format YYYY-MM-DD

3668290

#193 date format YYYY-MM-DD

9cb2243

#193 date format YYYY-MM-DD

447c81f

#432 table spacing

d72511b

#193 date format YYYY-MM-DD

d452374

#432 fixed and added links to RFC

5d69433

#432 fixed link

c0402d4

#432 punctuation and formatting changes

7ea5ac4

#432 standarized hyphens

453fce3

#432 standarized hyphens, punctuation and formatting changes

7568716

#432 punctuation : for lists

dd62205

#432 punctuation : for lists

4154fb0

#432 fixed section links

0e26881

#432 testing dns zone example

6774dd6

#432 testing dns zone example

f171a47

#432 testing dns zone example

92b05ce

Align Certificate Profile definition with discussion on 2025-12-04 SC…

1b885f4

…WG call (#639) Resolves #526.

Addresses #642

6bfbe3a

dzacharo added 4 commits December 12, 2025 09:56

This is actually a reference to the ITU-T X.509 standard. Reverting

decf4e9

Since RFC 7482 was replaced with RFC 9082 in the WHOIS definition, th…

bbd8bbb

…e references section should also be updated.

Updated RFC references to have a space after the word "RFC" for consi…

ce6778d

…stency

Removed old effective dates

351f275

aarongable reviewed Dec 18, 2025

View reviewed changes

srdavidson reviewed Dec 29, 2025

View reviewed changes

richardwsmith reviewed Jan 12, 2026

View reviewed changes

		Due to the complexity involved in implementing Certificate Profiles that conform to these Requirements, it is considered best practice for the CA to implement a Linting process to test the technical conformity of each to-be-signed artifact prior to signing it. When a Precertificate has undergone Linting, it is not necessary for the corresponding to-be-signed Certificate to also undergo Linting, provided that the CA has a technical control to verify that the to-be-signed Certificate corresponds to the to-be-signed Precertificate in the manner described by [RFC 6962, Section 3.2](https://datatracker.ietf.org/doc/html/rfc6962#section-3.2).

		Effective 2025-03-15, the CA SHALL implement such a Linting process.

	- Effective 2025-01-15, an authoritative OCSP response MUST be available (i.e. the responder MUST NOT respond with the "unknown" status) starting no more than 15 minutes after the Certificate or Precertificate is first published or otherwise made available.
	- An authoritative OCSP response MUST be available (i.e. the responder MUST NOT respond with the "unknown" status) starting no more than 15 minutes after the Certificate or Precertificate is first published or otherwise made available.

	5. The Public Key corresponds to an industry-demonstrated weak Private Key. For requests submitted on or after 2024-11-15, at least the following precautions SHALL be implemented:
	5. The Public Key corresponds to an industry-demonstrated weak Private Key. At least the following precautions SHALL be implemented:


		WHOIS: Information retrieved directly from the Domain Name Registrar or registry operator via the protocol defined in RFC 3912, the Registry Data Access Protocol defined in RFC 7482, or an HTTPS website.
		WHOIS: Information retrieved directly from the Domain Name Registrar or registry operator via the protocol defined in [RFC 3912](https://datatracker.ietf.org/doc/html/rfc3912), the Registry Data Access Protocol defined in [RFC 9082](https://datatracker.ietf.org/doc/html/rfc9082), or an HTTPS website.

Cleanup 2025 #628

Are you sure you want to change the base?

Cleanup 2025 #628

Uh oh!

Conversation

dzacharo commented Oct 31, 2025

Uh oh!

clintwilson commented Dec 11, 2025

Uh oh!

dzacharo commented Dec 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants