Bring section titles in-line with RFC 3647

[aarongable]

As of Ballot SC-74, CAs will be required to have their CP/CPS sections exactly match those laid out in RFC 3647, Section 6. I have created a tool which can check that markdown-formatted CPS documents comply with this requirement.

Unfortunately, the BRs themselves do not strictly match RFC 3647, Section 6. Of course, there is no requirement that they do so, but I believe it would be helpful for BR section titles to exactly match the CPS section titles to which they correspond.

Here is the output of my linting tool, when run against the current Baseline Requirements:

$ cd /code/github.com/letsencrypt/cp-cps/tools/lint
$ go run . /code/github.com/cabforum/servercert/docs/BR.md
heading "## 1.3 PKI participants" not found
heading "### 1.3.1 Certification authorities" not found
heading "### 1.3.2 Registration authorities" not found
heading "### 1.3.4 Relying parties" not found
heading "### 1.3.5 Other participants" not found
heading "## 1.4 Certificate usage" not found
heading "### 1.4.1 Appropriate certificate uses" not found
heading "### 1.4.2 Prohibited certificate uses" not found
heading "### 1.5.1 Organization administering the document" not found
heading "### 1.5.2 Contact person" not found
heading "### 1.5.3 Person determining CPS suitability for the policy" not found
heading "## 1.6 Definitions and acronyms" not found
heading "## 2.2 Publication of certification information" not found
heading "### 3.2.2 Authentication of organization identity" not found
heading "### 3.2.6 Criteria for interoperation" not found
heading "### 4.9.7 CRL issuance frequency (if applicable)" not found
heading "# 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS" not found
heading "## 5.1 Physical controls" not found
heading "### 5.2.2 Number of persons required per task" not found
heading "### 5.3.3 Training requirements" not found
heading "### 5.3.7 Independent contractor requirements" not found
heading "### 5.4.2 Frequency of processing log" not found
heading "### 5.4.6 Audit collection system (internal vs. external)" not found
heading "### 5.7.2 Computing resources, software, and/or data are corrupted" not found
heading "### 5.7.3 Entity private key compromise procedures" not found
heading "### 6.2.8 Method of activating private key" not found
heading "### 6.2.9 Method of deactivating private key" not found
heading "### 6.2.10 Method of destroying private key" not found
heading "### 7.1.2 Certificate extensions" not found
heading "### 7.1.4 Name forms" not found
heading "### 7.1.5 Name constraints" not found
empty section found at line 643
empty section found at line 645
empty section found at line 647
empty section found at line 649
empty section found at line 651
empty section found at line 653
empty section found at line 657
empty section found at line 1028
empty section found at line 1044
empty section found at line 1046
empty section found at line 1048
empty section found at line 1456
empty section found at line 1458
empty section found at line 1460
empty section found at line 1462
empty section found at line 1464
empty section found at line 1466
empty section found at line 1468
empty section found at line 1470
empty section found at line 1474
empty section found at line 1480
empty section found at line 1482
empty section found at line 1490
empty section found at line 1506
empty section found at line 1508
empty section found at line 1514
empty section found at line 1556
empty section found at line 1570
empty section found at line 1572
empty section found at line 1574
empty section found at line 1576
empty section found at line 1608
empty section found at line 1610
empty section found at line 1612
empty section found at line 1614
empty section found at line 1616
empty section found at line 1618
empty section found at line 1646
empty section found at line 1648
empty section found at line 1650
empty section found at line 1652
empty section found at line 1686
empty section found at line 1706
empty section found at line 1708
empty section found at line 1742
empty section found at line 1744
empty section found at line 1746
empty section found at line 1764
empty section found at line 1766
empty section found at line 1768
empty section found at line 1770
empty section found at line 1774
empty section found at line 1784
empty section found at line 1786
empty section found at line 1788
empty section found at line 1796
empty section found at line 1800
empty section found at line 1802
empty section found at line 1804
empty section found at line 1806
empty section found at line 1808
empty section found at line 3178
empty section found at line 3180
empty section found at line 3182
empty section found at line 3288
empty section found at line 3326
empty section found at line 3346
empty section found at line 3384
empty section found at line 3386
empty section found at line 3388
empty section found at line 3390
empty section found at line 3392
empty section found at line 3396
empty section found at line 3398
empty section found at line 3400
empty section found at line 3404
empty section found at line 3406
empty section found at line 3408
empty section found at line 3412
empty section found at line 3414
empty section found at line 3416
empty section found at line 3418
empty section found at line 3420
empty section found at line 3422
empty section found at line 3424
empty section found at line 3426
empty section found at line 3492
empty section found at line 3494
empty section found at line 3496
empty section found at line 3510
empty section found at line 3512
empty section found at line 3514
empty section found at line 3516
empty section found at line 3520
empty section found at line 3522
empty section found at line 3524
empty section found at line 3526
empty section found at line 3528
empty section found at line 3536
empty section found at line 3538
empty section found at line 3548
empty section found at line 3550
empty section found at line 3552
exit status 1

Here is a diff which can be applied to BR.md to fix all lint findings.

diff --git a/docs/BR.md b/docs/BR.md
index e4dcc98..c341ee2 100644
--- a/docs/BR.md
+++ b/docs/BR.md
@@ -191,15 +191,15 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse
 | 2023-09-15 | Section 7 (and others) | CAs MUST use the updated Certificate Profiles passed in Version 2.0.0 |
 | 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. |
 
-## 1.3 PKI Participants
+## 1.3 PKI participants
 
 The CA/Browser Forum is a voluntary organization of Certification Authorities and suppliers of Internet browser and other relying-party software applications.
 
-### 1.3.1 Certification Authorities
+### 1.3.1 Certification authorities
 
 Certification Authority (CA) is defined in [Section 1.6](#16-definitions-and-acronyms). Current CA Members of the CA/Browser Forum are listed here: <https://cabforum.org/members>.
 
-### 1.3.2 Registration Authorities
+### 1.3.2 Registration authorities
 
 With the exception of [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address), the CA MAY delegate the performance of all, or any part, of [Section 3.2](#32-initial-identity-validation) requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of [Section 3.2](#32-initial-identity-validation).
 
@@ -227,22 +227,22 @@ As defined in [Section 1.6.1](#161-definitions).
 
 In some situations, a CA acts as an Applicant or Subscriber, for instance, when it generates and protects a Private Key, requests a Certificate, demonstrates control of a Domain, or obtains a Certificate for its own use.
 
-### 1.3.4 Relying Parties
+### 1.3.4 Relying parties
 
 "Relying Party" and "Application Software Supplier" are defined in [Section 1.6.1](#161-definitions). Current Members of the CA/Browser Forum who are Application Software Suppliers are listed here:  
 <https://cabforum.org/members>.
 
-### 1.3.5 Other Participants
+### 1.3.5 Other participants
 
 Other groups that have participated in the development of these Requirements include the AICPA/CICA WebTrust for Certification Authorities task force and ETSI ESI. Participation by such groups does not imply their endorsement, recommendation, or approval of the final product.
 
-## 1.4 Certificate Usage
+## 1.4 Certificate usage
 
-### 1.4.1 Appropriate Certificate Uses
+### 1.4.1 Appropriate certificate uses
 
 The primary goal of these Requirements is to enable efficient and secure electronic communication, while addressing user concerns about the trustworthiness of Certificates. These Requirements also serve to inform users and help them to make informed decisions when relying on Certificates.
 
-### 1.4.2 Prohibited Certificate Uses
+### 1.4.2 Prohibited certificate uses
 
 No stipulation.
 
@@ -250,15 +250,15 @@ No stipulation.
 
 The Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates present criteria established by the CA/Browser Forum for use by Certification Authorities when issuing, maintaining, and revoking publicly-trusted TLS Server Certificates. This document may be revised from time to time, as appropriate, in accordance with procedures adopted by the CA/Browser Forum. Because one of the primary beneficiaries of this document is the end user, the Forum openly invites anyone to make recommendations and suggestions by email to the CA/Browser Forum at <[email protected]>. The Forum members value all input, regardless of source, and will seriously consider all such input.
 
-### 1.5.1 Organization Administering the Document
+### 1.5.1 Organization administering the document
 
 No stipulation.
 
-### 1.5.2 Contact Person
+### 1.5.2 Contact person
 
 Contact information for the CA/Browser Forum is available here: <https://cabforum.org/leadership/>. In this section of a CA's CPS, the CA shall provide a link to a web page or an email address for contacting the person or persons responsible for operation of the CA.
 
-### 1.5.3 Person Determining CPS suitability for the policy
+### 1.5.3 Person determining CPS suitability for the policy
 
 No stipulation.
 
@@ -266,7 +266,7 @@ No stipulation.
 
 No stipulation.
 
-## 1.6 Definitions and Acronyms
+## 1.6 Definitions and acronyms
 
 The Definitions found in the CA/Browser Forum's Network and Certificate System Security Requirements are incorporated by reference as if fully set forth herein.
 
@@ -611,7 +611,7 @@ The CA SHALL develop, implement, enforce, and annually update a Certificate Poli
 
 The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with this Policy.
 
-## 2.2 Publication of information
+## 2.2 Publication of certification information
 
 The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see [Section 8.4](#84-topics-covered-by-assessment)).
 
@@ -643,21 +643,35 @@ The CA shall make its Repository publicly available in a read-only manner.
 
 ### 3.1.1 Types of names
 
+No stipulation.
+
 ### 3.1.2 Need for names to be meaningful
 
+No stipulation.
+
 ### 3.1.3 Anonymity or pseudonymity of subscribers
 
+No stipulation.
+
 ### 3.1.4 Rules for interpreting various name forms
 
+No stipulation.
+
 ### 3.1.5 Uniqueness of names
 
+No stipulation.
+
 ### 3.1.6 Recognition, authentication, and role of trademarks
 
+No stipulation.
+
 ## 3.2 Initial identity validation
 
 ### 3.2.1 Method to prove possession of private key
 
-### 3.2.2 Authentication of Organization and Domain Identity
+No stipulation.
+
+### 3.2.2 Authentication of organization identity
 
 If the Applicant requests a Certificate that will contain Subject Identity Information comprised only of the `countryName` field, then the CA SHALL verify the country associated with the Subject using a verification process meeting the requirements of [Section 3.2.2.3](#3223-verification-of-country) and that is described in the CA's Certificate Policy and/or Certification Practice Statement. If the Applicant requests a Certificate that will contain the countryName field and other Subject Identity Information, then the CA SHALL verify the identity of the Applicant, and the authenticity of the Applicant Representative's certificate request using a verification process meeting the requirements of this [Section 3.2.2.1](#3221-identity) and that is described in the CA's Certificate Policy and/or Certification Practice Statement. The CA SHALL inspect any document relied upon under this Section for alteration or falsification.
 
@@ -1028,6 +1042,8 @@ The CA SHALL verify the certificate request with the Applicant using a Reliable
 
 ### 3.2.4 Non-verified subscriber information
 
+No stipulation.
+
 ### 3.2.5 Validation of authority
 
 If the Applicant for a Certificate containing Subject Identity Information is an organization, the CA SHALL use a Reliable Method of Communication to verify the authenticity of the Applicant Representative's certificate request.
@@ -1036,7 +1052,7 @@ The CA MAY use the sources listed in [Section 3.2.2.1](#3221-identity) to verify
 
 In addition, the CA SHALL establish a process that allows an Applicant to specify the individuals who may request Certificates. If an Applicant specifies, in writing, the individuals who may request a Certificate, then the CA SHALL NOT accept any certificate requests that are outside this specification. The CA SHALL provide an Applicant with a list of its authorized certificate requesters upon the Applicant's verified written request.
 
-### 3.2.6 Criteria for Interoperation or Certification
+### 3.2.6 Criteria for interoperation
 
 The CA SHALL disclose all Cross-Certified Subordinate CA Certificates that identify the CA as the Subject, provided that the CA arranged for or accepted the establishment of the trust relationship (i.e. the Cross-Certified Subordinate CA Certificate at issue).
 
@@ -1044,10 +1060,16 @@ The CA SHALL disclose all Cross-Certified Subordinate CA Certificates that ident
 
 ### 3.3.1 Identification and authentication for routine re-key
 
+No stipulation.
+
 ### 3.3.2 Identification and authentication for re-key after revocation
 
+No stipulation.
+
 ## 3.4 Identification and authentication for revocation request
 
+No stipulation.
+
 # 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
 
 ## 4.1 Certificate Application
@@ -1294,7 +1316,7 @@ No stipulation.
 
 **Note**: Following certificate issuance, a certificate may be revoked for reasons stated in [Section 4.9](#49-certificate-revocation-and-suspension). Therefore, relying parties should check the revocation status of all certificates that contain a CDP or OCSP pointer.
 
-### 4.9.7 CRL issuance frequency
+### 4.9.7 CRL issuance frequency (if applicable)
 
 CRLs must be available via a publicly-accessible HTTP URL (i.e., "published").
 
@@ -1424,7 +1446,7 @@ No stipulation.
 
 Not applicable.
 
-# 5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS
+# 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS
 
 The CA/Browser Forum's Network and Certificate System Security Requirements are incorporated by reference as if fully set forth herein.
 
@@ -1452,36 +1474,58 @@ The CA's security program MUST include an annual Risk Assessment that:
 
 Based on the Risk Assessment, the CA SHALL develop, implement, and maintain a security plan consisting of security procedures, measures, and products designed to achieve the objectives set forth above and to manage and control the risks identified during the Risk Assessment, commensurate with the sensitivity of the Certificate Data and Certificate Management Processes. The security plan MUST include administrative, organizational, technical, and physical safeguards appropriate to the sensitivity of the Certificate Data and Certificate Management Processes. The security plan MUST also take into account then-available technology and the cost of implementing the specific measures, and SHALL implement a reasonable level of security appropriate to the harm that might result from a breach of security and the nature of the data to be protected.
 
-## 5.1 Physical Security Controls
+## 5.1 Physical controls
 
 ### 5.1.1 Site location and construction
 
+No stipulation.
+
 ### 5.1.2 Physical access
 
+No stipulation.
+
 ### 5.1.3 Power and air conditioning
 
+No stipulation.
+
 ### 5.1.4 Water exposures
 
+No stipulation.
+
 ### 5.1.5 Fire prevention and protection
 
+No stipulation.
+
 ### 5.1.6 Media storage
 
+No stipulation.
+
 ### 5.1.7 Waste disposal
 
+No stipulation.
+
 ### 5.1.8 Off-site backup
 
+No stipulation.
+
 ## 5.2 Procedural controls
 
 ### 5.2.1 Trusted roles
 
-### 5.2.2 Number of Individuals Required per Task
+No stipulation.
+
+### 5.2.2 Number of persons required per task
 
 The CA Private Key SHALL be backed up, stored, and recovered only by personnel in trusted roles using, at least, dual control in a physically secured environment.
 
 ### 5.2.3 Identification and authentication for each role
 
+No stipulation.
+
 ### 5.2.4 Roles requiring separation of duties
 
+No stipulation.
+
 ## 5.3 Personnel controls
 
 ### 5.3.1 Qualifications, experience, and clearance requirements
@@ -1490,7 +1534,9 @@ Prior to the engagement of any person in the Certificate Management Process, whe
 
 ### 5.3.2 Background check procedures
 
-### 5.3.3 Training Requirements and Procedures
+No stipulation.
+
+### 5.3.3 Training requirements
 
 The CA SHALL provide all personnel performing information verification duties with skills-training that covers basic Public Key Infrastructure knowledge, authentication and vetting policies and procedures (including the CA's Certificate Policy and/or Certification Practice Statement), common threats to the information verification process (including phishing and other social engineering tactics), and these Requirements.
 
@@ -1506,14 +1552,20 @@ All personnel in Trusted roles SHALL maintain skill levels consistent with the C
 
 ### 5.3.5 Job rotation frequency and sequence
 
+No stipulation.
+
 ### 5.3.6 Sanctions for unauthorized actions
 
-### 5.3.7 Independent Contractor Controls
+No stipulation.
+
+### 5.3.7 Independent contractor requirements
 
 The CA SHALL verify that the Delegated Third Party's personnel involved in the issuance of a Certificate meet the training and skills requirements of [Section 5.3.3](#533-training-requirements-and-procedures) and the document retention and event logging requirements of [Section 5.4.1](#541-types-of-events-recorded).
 
 ### 5.3.8 Documentation supplied to personnel
 
+No stipulation.
+
 ## 5.4 Audit logging procedures
 
 ### 5.4.1 Types of events recorded
@@ -1563,7 +1615,9 @@ Logging of router and firewall activities necessary to meet the requirements of
   3. Logging of all changes made to firewall rules, including additions, modifications, and deletions; and
   4. Logging of all system events and errors, including hardware failures, software crashes, and system restarts.
 
-### 5.4.2 Frequency of processing audit log
+### 5.4.2 Frequency of processing log
+
+No stipulation.
 
 ### 5.4.3 Retention period for audit log
 
@@ -1579,12 +1633,20 @@ Note: While these Requirements set the minimum retention period, the CA MAY choo
 
 ### 5.4.4 Protection of audit log
 
+No stipulation.
+
 ### 5.4.5 Audit log backup procedures
 
-### 5.4.6 Audit collection System (internal vs. external)
+No stipulation.
+
+### 5.4.6 Audit collection system (internal vs. external)
+
+No stipulation.
 
 ### 5.4.7 Notification to event-causing subject
 
+No stipulation.
+
 ### 5.4.8 Vulnerability assessments
 
 Additionally, the CA's security program MUST include an annual Risk Assessment that:
@@ -1617,16 +1679,28 @@ Note: While these Requirements set the minimum retention period, the CA MAY choo
 
 ### 5.5.3 Protection of archive
 
+No stipulation.
+
 ### 5.5.4 Archive backup procedures
 
+No stipulation.
+
 ### 5.5.5 Requirements for time-stamping of records
 
+No stipulation.
+
 ### 5.5.6 Archive collection system (internal or external)
 
+No stipulation.
+
 ### 5.5.7 Procedures to obtain and verify archive information
 
+No stipulation.
+
 ## 5.6 Key changeover
 
+No stipulation.
+
 ## 5.7 Compromise and disaster recovery
 
 ### 5.7.1 Incident and compromise handling procedures
@@ -1653,14 +1727,22 @@ The business continuity plan MUST include:
 14. The distance of recovery facilities to the CA's main site; and
 15. Procedures for securing its facility to the extent possible during the period of time following a disaster and prior to restoring a secure environment either at the original or a remote site.
 
-### 5.7.2 Recovery Procedures if Computing resources, software, and/or data are corrupted
+### 5.7.2 Computing resources, software, and/or data are corrupted
+
+No stipulation.
+
+### 5.7.3 Entity private key compromise procedures
 
-### 5.7.3 Recovery Procedures after Key Compromise
+No stipulation.
 
 ### 5.7.4 Business continuity capabilities after a disaster
 
+No stipulation.
+
 ## 5.8 CA or RA termination
 
+No stipulation.
+
 # 6. TECHNICAL SECURITY CONTROLS
 
 ## 6.1 Key pair generation and installation
@@ -1695,6 +1777,8 @@ In all cases, the CA SHALL:
 
 #### 6.1.1.2 RA Key Pair Generation
 
+No stipulation.
+
 #### 6.1.1.3 Subscriber Key Pair Generation
 
 The CA SHALL reject a certificate request if one or more of the following conditions are met:
@@ -1715,8 +1799,12 @@ If the CA or any of its designated RAs become aware that a Subscriber's Private
 
 ### 6.1.3 Public key delivery to certificate issuer
 
+No stipulation.
+
 ### 6.1.4 CA public key delivery to relying parties
 
+No stipulation.
+
 ### 6.1.5 Key sizes
 
 For RSA key pairs the CA SHALL:
@@ -1751,10 +1839,16 @@ The CA SHALL implement physical and logical safeguards to prevent unauthorized c
 
 ### 6.2.1 Cryptographic module standards and controls
 
+No stipulation.
+
 ### 6.2.2 Private key (n out of m) multi-person control
 
+No stipulation.
+
 ### 6.2.3 Private key escrow
 
+No stipulation.
+
 ### 6.2.4 Private key backup
 
 See [Section 5.2.2](#522-number-of-individuals-required-per-task).
@@ -1771,18 +1865,28 @@ If the Issuing CA generated the Private Key on behalf of the Subordinate CA, the
 
 The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats.
 
-### 6.2.8 Activating Private Keys
+### 6.2.8 Method of activating private key
 
-### 6.2.9 Deactivating Private Keys
+No stipulation.
+
+### 6.2.9 Method of deactivating private key
+
+No stipulation.
 
-### 6.2.10 Destroying Private Keys
+### 6.2.10 Method of destroying private key
+
+No stipulation.
 
 ### 6.2.11 Cryptographic Module Rating
 
+No stipulation.
+
 ## 6.3 Other aspects of key pair management
 
 ### 6.3.1 Public key archival
 
+No stipulation.
+
 ### 6.3.2 Certificate operational periods and key pair usage periods
 
 Subscriber Certificates issued on or after 1 September 2020 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. 
@@ -1793,10 +1897,16 @@ For the purpose of calculations, a day is measured as 86,400 seconds. Any amount
 
 ### 6.4.1 Activation data generation and installation
 
+No stipulation.
+
 ### 6.4.2 Activation data protection
 
+No stipulation.
+
 ### 6.4.3 Other aspects of activation data
 
+No stipulation.
+
 ## 6.5 Computer security controls
 
 ### 6.5.1 Specific computer security technical requirements
@@ -1805,18 +1915,30 @@ The CA SHALL enforce multi-factor authentication for all accounts capable of dir
 
 ### 6.5.2 Computer security rating
 
+No stipulation.
+
 ## 6.6 Life cycle technical controls
 
 ### 6.6.1 System development controls
 
+No stipulation.
+
 ### 6.6.2 Security management controls
 
+No stipulation.
+
 ### 6.6.3 Life cycle security controls
 
+No stipulation.
+
 ## 6.7 Network security controls
 
+No stipulation.
+
 ## 6.8 Time-stamping
 
+No stipulation.
+
 # 7. CERTIFICATE, CRL, AND OCSP PROFILES
 
 ## 7.1 Certificate profile
@@ -1829,7 +1951,7 @@ Prior to 2023-09-15, the CA SHALL issue Certificates in accordance with the prof
 
 Certificates MUST be of type X.509 v3.
 
-### 7.1.2 Certificate Content and Extensions
+### 7.1.2 Certificate extensions
 
 If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following certificate profiles, which incorporate, and are derived from [RFC 5280](https://tools.ietf.org/html/rfc5280). Except as explicitly noted, all normative requirements imposed by RFC 5280 shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine [RFC 5280, Appendix B](https://tools.ietf.org/html/rfc5280#appendix-B) for further issues to be aware of.
 
@@ -3096,7 +3218,7 @@ If the signing key is P-384, the signature MUST use ECDSA with SHA-384. When enc
 
 If the signing key is P-521, the signature MUST use ECDSA with SHA-512. When encoded, the `AlgorithmIdentifier` MUST be byte-for-byte identical with the following hex-encoded bytes: `300a06082a8648ce3d040304`.
 
-### 7.1.4 Name Forms
+### 7.1.4 Name forms
 
 This section details encoding rules that apply to all Certificates issued by a CA. Further restrictions may be specified within [Section 7.1.2](#712-certificate-content-and-extensions), but these restrictions do not supersede these requirements.
 
@@ -3177,6 +3299,8 @@ Before including such an attribute, the CA SHALL:
 
 ### 7.1.5 Name constraints
 
+No stipulation
+
 ### 7.1.6 Certificate policy object identifier
 
 #### 7.1.6.1 Reserved Certificate Policy Identifiers
@@ -3193,10 +3317,16 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o
 
 ### 7.1.7 Usage of Policy Constraints extension
 
+No stipulation.
+
 ### 7.1.8 Policy qualifiers syntax and semantics
 
+No stipulation.
+
 ### 7.1.9 Processing semantics for the critical Certificate Policies extension
 
+No stipulation.
+
 ## 7.2 CRL profile
 
 Prior to 2024‐03‐15, the CA SHALL issue CRLs in accordance with the profile specified in these Requirements or the profile specified in Version 1.8.7 of the Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates. Effective 2024‐03‐15, the CA SHALL issue CRLs in accordance with the profile specified in these Requirements.
@@ -3303,6 +3433,8 @@ The `CRLReason` indicated MUST contain a value permitted for CRLs, as specified
 
 ### 7.3.1 Version number(s)
 
+No stipulation.
+
 ### 7.3.2 OCSP extensions
 
 The `singleExtensions` of an OCSP response MUST NOT contain the `reasonCode` (OID 2.5.29.21) CRL entry extension.
@@ -3341,6 +3473,8 @@ The CA's audit SHALL be performed by a Qualified Auditor. A Qualified Auditor me
 
 ## 8.3 Assessor's relationship to assessed entity
 
+No stipulation.
+
 ## 8.4 Topics covered by assessment
 
 The CA SHALL undergo an audit in accordance with one of the following schemes:
@@ -3361,6 +3495,8 @@ The audit period for the Delegated Third Party SHALL NOT exceed one year (ideall
 
 ## 8.5 Actions taken as a result of deficiency
 
+No stipulation.
+
 ## 8.6 Communication of results
 
 The Audit Report SHALL state explicitly that it covers the relevant systems and processes used in the issuance of all Certificates that assert one or more of the policy identifiers listed in [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers). The CA SHALL make the Audit Report publicly available.
@@ -3399,48 +3535,86 @@ During the period in which a Technically Constrained Subordinate CA issues Certi
 
 ### 9.1.1 Certificate issuance or renewal fees
 
+No stipulation.
+
 ### 9.1.2 Certificate access fees
 
+No stipulation.
+
 ### 9.1.3 Revocation or status information access fees
 
+No stipulation.
+
 ### 9.1.4 Fees for other services
 
+No stipulation.
+
 ### 9.1.5 Refund policy
 
+No stipulation.
+
 ## 9.2 Financial responsibility
 
 ### 9.2.1 Insurance coverage
 
+No stipulation.
+
 ### 9.2.2 Other assets
 
+No stipulation.
+
 ### 9.2.3 Insurance or warranty coverage for end-entities
 
+No stipulation.
+
 ## 9.3 Confidentiality of business information
 
 ### 9.3.1 Scope of confidential information
 
+No stipulation.
+
 ### 9.3.2 Information not within the scope of confidential information
 
+No stipulation.
+
 ### 9.3.3 Responsibility to protect confidential information
 
+No stipulation.
+
 ## 9.4 Privacy of personal information
 
 ### 9.4.1 Privacy plan
 
+No stipulation.
+
 ### 9.4.2 Information treated as private
 
+No stipulation.
+
 ### 9.4.3 Information not deemed private
 
+No stipulation.
+
 ### 9.4.4 Responsibility to protect private information
 
+No stipulation.
+
 ### 9.4.5 Notice and consent to use private information
 
+No stipulation.
+
 ### 9.4.6 Disclosure pursuant to judicial or administrative process
 
+No stipulation.
+
 ### 9.4.7 Other information disclosure circumstances
 
+No stipulation.
+
 ## 9.5 Intellectual property rights
 
+No stipulation.
+
 ## 9.6 Representations and warranties
 
 ### 9.6.1 CA representations and warranties
@@ -3507,10 +3681,16 @@ The Subscriber Agreement or Terms of Use MUST contain provisions imposing on the
 
 ### 9.6.4 Relying party representations and warranties
 
+No stipulation.
+
 ### 9.6.5 Representations and warranties of other participants
 
+No stipulation.
+
 ## 9.7 Disclaimers of warranties
 
+No stipulation.
+
 ## 9.8 Limitations of liability
 
 For delegated tasks, the CA and any Delegated Third Party MAY allocate liability between themselves contractually as they determine, but the CA SHALL remain fully responsible for the performance of all parties in accordance with these Requirements, as if the tasks had not been delegated.
@@ -3525,24 +3705,42 @@ Notwithstanding any limitations on its liability to Subscribers and Relying Part
 
 ### 9.10.1 Term
 
+No stipulation.
+
 ### 9.10.2 Termination
 
+No stipulation.
+
 ### 9.10.3 Effect of termination and survival
 
+No stipulation.
+
 ## 9.11 Individual notices and communications with participants
 
+No stipulation.
+
 ## 9.12 Amendments
 
 ### 9.12.1 Procedure for amendment
 
+No stipulation.
+
 ### 9.12.2 Notification mechanism and period
 
+No stipulation.
+
 ### 9.12.3 Circumstances under which OID must be changed
 
+No stipulation.
+
 ## 9.13 Dispute resolution provisions
 
+No stipulation.
+
 ## 9.14 Governing law
 
+No stipulation.
+
 ## 9.15 Compliance with applicable law
 
 The CA SHALL issue Certificates and operate its PKI in accordance with all law applicable to its business and the Certificates it issues in every jurisdiction in which it operates.
@@ -3551,8 +3749,12 @@ The CA SHALL issue Certificates and operate its PKI in accordance with all law a
 
 ### 9.16.1 Entire agreement
 
+No stipulation.
+
 ### 9.16.2 Assignment
 
+No stipulation.
+
 ### 9.16.3 Severability
 
 In the event of a conflict between these Requirements and a law, regulation or government order (hereinafter 'Law') of any jurisdiction in which a CA operates or issues certificates, a CA MAY modify any conflicting requirement to the minimum extent necessary to make the requirement valid and legal in the jurisdiction. This applies only to operations or certificate issuances that are subject to that Law. In such event, the CA SHALL immediately (and prior to issuing a certificate under the modified requirement) include in Section 9.16.3 of the CA's CPS a detailed reference to the Law requiring a modification of these Requirements under this section, and the specific modification to these Requirements implemented by the CA.
@@ -3563,10 +3765,16 @@ Any modification to CA practice enabled under this section MUST be discontinued
 
 ### 9.16.4 Enforcement (attorneys' fees and waiver of rights)
 
+No stipulation.
+
 ### 9.16.5 Force Majeure
 
+No stipulation.
+
 ## 9.17 Other provisions
 
+No stipulation.
+
 # APPENDIX A – CAA Contact Tag
 
 These methods allow domain owners to publish contact information in DNS for the purpose of validating domain control.

I note that I don't think all of the changes in this diff are improvements. Specifically, the removal of "...domain and..." from 3.2.2, and the removal of "Recovery procedures if..." from 5.7.2 make the purpose of those sections notably less clear. However, CAs will be required to use the worse titles going forward, and I believe that consistency is worthwhile here.

[dzacharo]

Notes from the 2024-12-05 SCWG Teleconference:

• Ben has a draft proposal for aligning the section numbers with RFC 3647 or allow certain exceptions
• Inigo would like to align the titles not just for the BRs but also in the EV Guidelines for consistency.