Update 6.2.7 to match 6.1.1 and 5.1.8 (#296)

Let's have our cross-references use the same language.

.github/workflows/lint.yml

@@ -0,0 +1,19 @@
+name: Lint CP/CPS
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - '**'
+jobs:
+  lint:
+
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-go@v5
+      - name: Run linter
+        working-directory: ./tools/lint
+        run: go run . ../../CP-CPS.md

.github/workflows/pr_tools.yml

@@ -3,22 +3,22 @@ name: Test Tools
 on:
   push:
     branches:
-      - master
+      - main
   pull_request:
     branches:
-      - master
+      - '**'
 jobs:
   build:
 
     runs-on: ubuntu-latest
     strategy:
       matrix:
-        python-version: [3.6, 3.7, 3.8, 3.9]
+        python-version: [3.8, 3.12.3]
 
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@v4
       - name: Set up Python ${{ matrix.python-version }}
-        uses: actions/setup-python@v2
+        uses: actions/setup-python@v5
         with:
           python-version: ${{ matrix.python-version }}
       - name: Install dependencies

GUIDELINES.md

@@ -1,25 +0,0 @@
-# This document contains some guidelines for editing ISRG CP and CPS documents.
-
-## CP
-
-Our CP is a copy of the Baseline Requirements (BRs) with the following changes:
-
-1. Change anything that is obviously necessary, including much of the content in Sections 1.1 and 1.2.
-
-2. Stucture should follow the structure suggested in RFC 3647 Section 6. Casing of section labels should match RFC 3647 casing. Where there is a difference between the BR structure and RFC 3647 suggested structures, use RFC 3647.
-
-Note that any RFC 3647 section is allowed to contain sub-sections that are not defined in RFC 3647, so additional sub-sections in the BRs should be copied.
-
-An example of a conflict between RFC 3647 and the BR structure is the title of Section 3.2.2. The BRs call it "Authentication of Organization and Domain Identity" but RFC 3647 calls it "Authentication of organization identity". We must use the RFC 3647 section name.
-
-3. Section names for any validation methods we don't use under Sections 3.2.2.4 and 3.2.2.5 should be [Reserved] with "No stipulation." as the content. We do not include information for validation methods we don't use so as to not introduce confusion.
-
-4. No sections can be left blank. If there is a blank section in the BRs say "No stipulation." to indicate that our CP will not impose additional requirements.
-
-5. Section 9, legal, is designed and reviewed by ISRG attorneys.
-
-## CPS
-
-The CPS should have the same structure at the CP, but contain more detailed information.
-
-Section 9, legal, is designed and reviewed by ISRG attorneys.

README.md

@@ -1,7 +1,7 @@
-# ISRG CP and CPS Documents (DRAFT)
+# ISRG CP and CPS Document (DRAFT)
 
-This repository contains Certificate Policy (CP) and Certification Practice Statement (CPS) documents for ISRG / Let's Encrypt.
+This repository contains the combined Certificate Policy (CP) and Certification Practice Statement (CPS) document for ISRG / Let's Encrypt.
 
-This is where we work on our CP and CPS documents, but no revision becomes official until it's posted here:
+This is where we work on our CP/CPS document, but no revision becomes official until it's posted here:
 
 <https://letsencrypt.org/repository/>

archive/CP.md

@@ -21,7 +21,7 @@ The following Certification Authorities are covered under this CP:
 | CA Type | Distinguished Name | Key Pair Type and Parameters | Cert SHA-256 Fingerprint | Validity Period |
 |---------|--------------------|------------------------------|--------------------------|-----------------|
 | Root CA | C=US,<br>O=Internet Security Research Group,<br>CN=ISRG Root X1 | RSA, n has 4096 bits, e=65537 | 96:BC:EC:06:26:49:76:F3:<br>74:60:77:9A:CF:28:C5:A7:<br>CF:E8:A3:C0:AA:E1:1A:8F:<br>FC:EE:05:C0:BD:DF:08:C6 | Not Before: Jun  4 11:04:38 2015 GMT,<br>Not After: Jun  4 11:04:38 2035 GMT |
-| Root CA | C=US,<br>O=Internet Security Research Group,<br>CN=ISRG Root X2 | ECDSA, NIST curve P-384 | 69:72:9b:8e:15:a8:6e:fc:<br>17:7a:57:af:b7:17:1d:fc:<br>64:ad:d2:8c:2f:ca:8c:f1:<br>50:7e:34:45:3c:cb:14:70 | Not Before: Sept  4 00:00:00 2020 GMT,<br>Not After: Sept 17 16:00:00 2040 GMT |
+| Root CA | C=US,<br>O=Internet Security Research Group,<br>CN=ISRG Root X2 | ECDSA, NIST curve P-384 | 69:72:9B:8E:15:A8:6E:FC:<br>17:7A:57:AF:B7:17:1D:FC:<br>64:AD:D2:8C:2F:CA:8C:F1:<br>50:7E:34:45:3C:CB:14:70 | Not Before: Sept  4 00:00:00 2020 GMT,<br>Not After: Sept 17 16:00:00 2040 GMT |
 
 This work is licensed under the Creative Commons Attribution 4.0 International License ("CC BY 4.0"). This work is derivative of "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" by the CA/Browser Forum, used under CC BY 4.0. To view a copy of this license, visit <https://creativecommons.org/licenses/by/4.0/> or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
 
@@ -47,6 +47,9 @@ This is the ISRG Certificate Policy. This document was approved for publication
 | June 8, 2021 | Update Sections 4.2.1, 4.2.2, 4.9.1.1, 6.3.2, and 7.1.4.2.1 to match BRs v1.7.6. Define Internal Name in Section 1.6.1. | 2.7 |
 | July 19, 2021 | Sync against Baseline Requirements v1.7.8. | 3.0 |
 | August 20, 2021 | Update mailing address. Minor formatting changes. | 3.1 |
+| December 22, 2021 | Sync against Baseline Requirements v1.8.0. Minor updates. | 3.2 |
+| May 06, 2022 | Sync against Baseline Requirements v1.8.4. | 3.3 |
+| March 10, 2023 | Sync against Baseline Requirements v1.8.6. | 3.4 |
 
 ### 1.2.2 Relevant Dates
 
@@ -60,7 +63,7 @@ This is the ISRG Certificate Policy. This document was approved for publication
 | 2013-12-31 | 6.1.5 | CAs SHALL confirm that the RSA Public Key is at least 2048 bits or that one of the following ECC curves is used: P-256, P-384, or P-521. A Root CA Certificate issued prior to 31 Dec. 2010 with an RSA key size less than 2048 bits MAY still serve as a trust anchor. |
 | 2015-01-16 | 7.1.3 | CAs SHOULD NOT issue Subscriber Certificates utilizing the SHA-1 algorithm with an Expiry Date greater than 1 January 2017. |
 | 2015-04-01 | 6.3.2 | CAs SHALL NOT issue certificates with validity periods longer than 39 months, except under certain circumstances. |
-| 2015-04-15 | 2.2 | A CA's CPS must state whether it reviews CAA Records, and if so, its policy or practice on processing CAA records for Fully Qualified Domain Names. |
+| 2015-04-15 | 2.2 | A CA's CPS must state whether it reviews CAA Records, and if so, its policy or practice on processing CAA records for Fully-Qualified Domain Names. |
 | 2015-11-01 | 7.1.4.2.1 | Issuance of Certificates with Reserved IP Address or Internal Name prohibited. |
 | 2016-01-01 | 7.1.3 | CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm. |
 | 2016-06-30 | 6.1.7 | CAs MUST NOT issue Subscriber Certificates directly from Root CAs. |
@@ -84,11 +87,15 @@ This is the ISRG Certificate Policy. This document was approved for publication
 | 2020-09-01 | 6.3.2 | Certificates issued SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. |
 | 2020-09-30 | 4.9.10 | OCSP responses MUST conform to the validity period requirements specified. |
 | 2020-09-30 | 7.1.4.1 | Subject and Issuer Names for all possible certification paths MUST be byte-for-byte identical. |
-| 2020-09-30 | 7.1.6.4 | Subscriber Certificates MUST include a CA/Browser Form Reserved Policy Identifier in the Certificate Policies extension. |
+| 2020-09-30 | 7.1.6.4 | Subscriber Certificates MUST include a CA/Browser Forum Reserved Policy Identifier in the Certificate Policies extension. |
 | 2020-09-30 | 7.2 and 7.3 | All OCSP and CRL responses for Subordinate CA Certificates MUST include a meaningful reason code. |
 | 2021-07-01 | 3.2.2.8 | CAA checking is no longer optional if the CA is the DNS Operator or an Affiliate. |
 | 2021-07-01 | 3.2.2.4.18 and 3.2.2.4.19 | Redirects MUST be the result of one of the HTTP status code responses defined.  |
+| 2021-10-01 | 7.1.4.2.1 | Fully-Qualified Domain Names MUST consist solely of P-Labels and Non-Reserved LDH Labels. |
 | 2021-12-01 | 3.2.2.4 | CAs MUST NOT use methods 3.2.2.4.6, 3.2.2.4.18, or 3.2.2.4.19 to issue wildcard certificates or with Authorization Domain Names other than the FQDN. |
+| 2022-06-01 | 7.1.3.2.1 | CAs MUST NOT sign OCSP responses using the SHA-1 hash algorithm. |
+| 2022-09-01 | 7.1.4.2.2 | CAs MUST NOT include the organizationalUnitName field in the Subject |
+| 2023-01-15 | 7.2.2 | Sharded or partitioned CRLs MUST have a distributionPoint |
 
 ## 1.3 PKI Participants
 
@@ -146,7 +153,7 @@ No stipulation.
 
 ### 1.5.1 Organization Administering the Document
 
-This CP document is maintained by the ISRG Policy Management Authority.
+This CP document is maintained by the ISRG Policy Management Authority (PMA).
 
 ### 1.5.2 Contact Person
 
@@ -168,15 +175,17 @@ The ISRG Policy Management Authority is responsible for determining the suitabil
 
 ### 1.5.4 CPS approval procedures
 
-The ISRG Policy Management Authority approves any revisions to this CP document after formal review.
+The ISRG Policy Management Authority approves any revisions to the ISRG CPS after formal review.
 
 ## 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.
+
 ### 1.6.1 Definitions
 
 **Affiliate**: A corporation, partnership, joint venture or other entity controlling, controlled by, or under common control with another entity, or an agency, department, political subdivision, or any entity operating under the direct control of a Government Entity.
 
-**Applicant**: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual certificate request.
+**Applicant**: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate is issued, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual certificate request.
 
 **Applicant Representative**: A natural person or human sponsor who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant:
 
@@ -192,11 +201,11 @@ The ISRG Policy Management Authority approves any revisions to this CP document
 
 **Audit Report**: A report from a Qualified Auditor stating the Qualified Auditor's opinion on whether an entity's processes and controls comply with the mandatory provisions of these Requirements.
 
-**Authorization Domain Name**: The Domain Name used to obtain authorization for certificate issuance for a given FQDN. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If the FQDN contains a wildcard character, then the CA MUST remove all wildcard labels from the left most portion of requested FQDN. The CA may prune zero or more labels from left to right until encountering a Base Domain Name and may use any one of the intermediate values for the purpose of domain validation.
+**Authorization Domain Name**: The FQDN used to obtain authorization for a given FQDN to be included in a Certificate. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If a Wildcard Domain Name is to be included in a Certificate, then the CA MUST remove "`*.`" from the left-most portion of the Wildcard Domain Name to yield the corresponding FQDN. The CA may prune zero or more Domain Labels of the FQDN from left to right until encountering a Base Domain Name and may use any one of the values that were yielded by pruning (including the Base Domain Name itself) for the purpose of domain validation.
 
 **Authorized Ports**: One of the following ports: 80 (http), 443 (https), 25 (smtp), 22 (ssh).
 
-**Base Domain Name**: The portion of an applied-for FQDN that is the first domain name node left of a registry-controlled or public suffix plus the registry-controlled or public suffix (e.g. "example.co.uk" or "example.com"). For FQDNs where the right-most domain name node is a gTLD having ICANN Specification 13 in its registry agreement, the gTLD itself may be used as the Base Domain Name.
+**Base Domain Name**: The portion of an applied-for FQDN that is the first Domain Name node left of a registry-controlled or public suffix plus the registry-controlled or public suffix (e.g. "example.co.uk" or "example.com"). For FQDNs where the right-most Domain Name node is a gTLD having ICANN Specification 13 in its registry agreement, the gTLD itself may be used as the Base Domain Name.
 
 **CAA**: From RFC 8659 (<http://tools.ietf.org/html/rfc8659>): "The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue."
 
@@ -212,21 +221,21 @@ The ISRG Policy Management Authority approves any revisions to this CP document
 
 **Certificate Problem Report**: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.
 
+**Certificate Profile**: A set of documents or files that defines requirements for Certificate content and Certificate extensions in accordance with [Section 7](#7-certificate-crl-and-ocsp-profiles), e.g. a Section in a CA’s CPS or a certificate template file used by CA software.
+
 **Certificate Revocation List**: A regularly updated time-stamped list of revoked Certificates that is created and digitally signed by the CA that issued the Certificates.
 
-**Certification Authority**: An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Roots CAs and Subordinate CAs.
+**Certification Authority**: An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Root CAs and Subordinate CAs.
 
 **Certification Practice Statement**: One of several documents forming the governance framework in which Certificates are created, issued, managed, and used.
 
-**Certificate Profile**: A set of documents or files that defines requirements for Certificate content and Certificate extensions in accordance with [Section 7](#7-certificate-crl-and-ocsp-profiles). e.g. a Section in a CA’s CPS or a certificate template file used by CA software.
-
 **Control**: "Control" (and its correlative meanings, "controlled by" and "under common control with") means possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors ; or (3) vote that portion of voting shares required for "control" under the law of the entity's Jurisdiction of Incorporation or Registration but in no case less than 10%.
 
 **Country**: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations.
 
 **Cross Certificate**: A certificate that is used to establish a trust relationship between two Root CAs.
 
-**CSPRNG**: A random number generator intended for use in cryptographic system.
+**CSPRNG**: A random number generator intended for use in a cryptographic system.
 
 **Delegated Third Party**: A natural person or Legal Entity that is not the CA but is authorized by the CA, and whose activities are not within the scope of the appropriate CA audits, to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein.
 
@@ -238,11 +247,11 @@ The ISRG Policy Management Authority approves any revisions to this CP document
 
 **DNS TXT Record Phone Contact**: The phone number defined in [Appendix A.2.2](#a22-dns-txt-record-phone-contact).
 
-**Domain Authorization Document**: Documentation provided by, or a CA's documentation of a communication with, a Domain Name Registrar, the Domain Name Registrant, or the person or entity listed in WHOIS as the Domain Name Registrant (including any private, anonymous, or proxy registration service) attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace.
-
 **Domain Contact**: The Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar.
 
-**Domain Name**: The label assigned to a node in the Domain Name System.
+**Domain Label**: From RFC 8499 (<http://tools.ietf.org/html/rfc8499>): "An ordered list of zero or more octets that makes up a portion of a domain name. Using graph theory, a label identifies one node in a portion of the graph of all possible domain names."
+
+**Domain Name**: An ordered list of one or more Domain Labels assigned to a node in the Domain Name System.
 
 **Domain Namespace**: The set of all possible Domain Names that are subordinate to a single node in the Domain Name System.
 
@@ -258,7 +267,7 @@ The ISRG Policy Management Authority approves any revisions to this CP document
 
 **Expiry Date**: The "Not After" date in a Certificate that defines the end of a Certificate's validity period.
 
-**Fully-Qualified Domain Name**: A Domain Name that includes the labels of all superior nodes in the Internet Domain Name System.
+**Fully-Qualified Domain Name**: A Domain Name that includes the Domain Labels of all superior nodes in the Internet Domain Name System.
 
 **Government Entity**: A government-operated legal entity, agency, department, ministry, branch, or similar element of the government of a country, or political subdivision within such country (such as a state, province, city, county, etc.).
 
@@ -266,7 +275,7 @@ The ISRG Policy Management Authority approves any revisions to this CP document
 
 **Internal Name**: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA's Root Zone Database.
 
-**IP Address**: A 32-bit or 128-bit label assigned to a device that uses the Internet Protocol for communication.
+**IP Address**: A 32-bit or 128-bit number assigned to a device that uses the Internet Protocol for communication.
 
 **IP Address Contact**: The person(s) or entity(ies) registered with an IP Address Registration Authority as having the right to control how one or more IP Addresses are used.
 
@@ -280,16 +289,24 @@ The ISRG Policy Management Authority approves any revisions to this CP document
 
 **Key Pair**: The Private Key and its associated Public Key.
 
+**LDH Label**: From RFC 5890 (<http://tools.ietf.org/html/rfc5890>): "A string consisting of ASCII letters, digits, and the hyphen with the further restriction that the hyphen cannot appear at the beginning or end of the string. Like all DNS labels, its total length must not exceed 63 octets."
+
 **Legal Entity**: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country's legal system.
 
+**Non-Reserved LDH Label**: From RFC 5890 (<http://tools.ietf.org/html/rfc5890>): "The set of valid LDH labels that do not have '`--`' in the third and fourth positions."
+
 **Object Identifier**: A unique alphanumeric or numeric identifier registered under the International Organization for Standardization's applicable standard for a specific object or object class.
 
 **OCSP Responder**: An online server operated under the authority of the CA and connected to its Repository for processing Certificate status requests. See also, Online Certificate Status Protocol.
 
+**Onion Domain Name**: A Fully Qualified Domain Name ending with the RFC 7686 ".onion" Special-Use Domain Name. For example, `2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion` is an Onion Domain Name, whereas `torproject.org` is not an Onion Domain Name.
+
 **Online Certificate Status Protocol**: An online Certificate-checking protocol that enables relying-party application software to determine the status of an identified Certificate. See also OCSP Responder.
 
 **Parent Company**: A company that Controls a Subsidiary Company.
 
+**P-Label**: A XN-Label that contains valid output of the Punycode algorithm (as defined in RFC 3492, Section 6.3) from the fifth and subsequent positions.
+
 **Private Key**: The key of a Key Pair that is kept secret by the holder of the Key Pair, and that is used to create Digital Signatures and/or to decrypt electronic records or files that were encrypted with the corresponding Public Key.
 
 **Public Key**: The key of a Key Pair that may be publicly disclosed by the holder of the corresponding Private Key and that is used by a Relying Party to verify Digital Signatures created with the holder's corresponding Private Key and/or to encrypt messages so that they can be decrypted only with the holder's corresponding Private Key.
@@ -347,11 +364,11 @@ The script outputs:
 
 **Requirements**: Policy requirements outlined in this document.
 
-**Reserved IP Address**: An IPv4 or IPv6 address that the IANA has marked as reserved:
+**Reserved IP Address**: An IPv4 or IPv6 address that is contained in the address block of any entry in either of the following IANA registries:
 
-[http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml](http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml)
+[https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml](https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml)
 
-[http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml](http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml)
+[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)
 
 **Root CA**: The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.
 
@@ -361,7 +378,7 @@ The script outputs:
 
 **Subject**: The natural person, device, system, unit, or Legal Entity identified in a Certificate as the Subject. The Subject is either the Subscriber or a device under the control and operation of the Subscriber.
 
-**Subject Identity Information**: Information that identifies the Certificate Subject. Subject Identity Information does not include a domain name listed in the `subjectAltName` extension or the Subject `commonName` field.
+**Subject Identity Information**: Information that identifies the Certificate Subject. Subject Identity Information does not include a Domain Name listed in the `subjectAltName` extension or the Subject `commonName` field.
 
 **Subordinate CA**: A Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA.
 
@@ -381,15 +398,17 @@ The script outputs:
 
 **Valid Certificate**: A Certificate that passes the validation procedure specified in RFC 5280.
 
-**Validation Specialists**: Someone who performs the information verification duties specified by these Requirements.
+**Validation Specialist**: Someone who performs the information verification duties specified by these Requirements.
 
-**Validity Period**: Prior to 2020-09-01, the period of time measured from the date when the Certificate is issued until the Expiry Date. For Certificates issued on or after 2020-09-01, the validity period is as defined within RFC 5280, Section 4.1.2.5: the period of time from notBefore through notAfter, inclusive.
+**Validity Period**: From RFC 5280 (<http://tools.ietf.org/html/rfc5280>): "The period of time from notBefore through notAfter, inclusive."
 
 **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.
 
-**Wildcard Certificate**: A Certificate containing an asterisk (\*) in the left-most position of any of the Subject Fully-Qualified Domain Names contained in the Certificate.
+**Wildcard Certificate**: A Certificate containing at least one Wildcard Domain Name in the Subject Alternative Names in the Certificate.
 
-**Wildcard Domain Name**: A Domain Name consisting of a single asterisk character followed by a single full stop character ("\*.") followed by a Fully-Qualified Domain Name.
+**Wildcard Domain Name**: A string starting with "\*." (U+002A ASTERISK, U+002E FULL STOP) immediately followed by a Fully-Qualified Domain Name.
+
+**XN-Label**: From RFC 5890 (<http://tools.ietf.org/html/rfc5890>): "The class of labels that begin with the prefix `"xn--"` (case independent), but otherwise conform to the rules for LDH labels."
 
 ### 1.6.2 Acronyms
 
@@ -432,43 +451,51 @@ ETSI TS 102 042, Electronic Signatures and Infrastructures (ESI); Policy require
 
 FIPS 140-2, Federal Information Processing Standards Publication - Security Requirements For Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001.
 
+FIPS 140-3, Federal Information Processing Standards Publication - Security Requirements For Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, March 22, 2019.
+
 FIPS 186-4, Federal Information Processing Standards Publication - Digital Signature Standard (DSS), Information Technology Laboratory, National Institute of Standards and Technology, July 2013.
 
 ISO 21188:2006, Public key infrastructure for financial services -- Practices and policy framework.
 
-Network and Certificate System Security Requirements, v.1.0, 1/1/2013.
+Network and Certificate System Security Requirements, Version 1.7, available at <https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Network-Security-Guidelines-v1.7.pdf>.
 
 NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications, <http://csrc.nist.gov/publications/nistpubs/800-89/SP-800-89_November2006.pdf>.
 
-RFC2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels, Bradner, March 1997.
+RFC2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997.
 
-RFC2527, Request for Comments: 2527, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, Chokhani, et al, March 1999.
+RFC3492, Request for Comments: 3492, Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello. March 2003.
 
-RFC3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, Chokhani, et al, November 2003.
+RFC3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework. S. Chokhani, et al. November 2003.
 
-RFC3912, Request for Comments: 3912, WHOIS Protocol Specification, Daigle, September 2004.
+RFC3912, Request for Comments: 3912, WHOIS Protocol Specification. L. Daigle. September 2004.
 
-RFC4366, Request for Comments: 4366, Transport Layer Security (TLS) Extensions, Blake-Wilson, et al, April 2006.
+RFC3986, Request for Comments: 3986, Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, et al. January 2005.
 
-RFC5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments, A. Deacon, et al, September 2007.
+RFC5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. A. Deacon, et al. September 2007.
 
-RFC5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile, Cooper et al, May 2008.
+RFC5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, et al. May 2008.
 
-RFC8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record, Hallam-Baker, Stradling, Hoffman-Andrews, November 2019.
+RFC5890, Request for Comments: 5890, Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. August 2010.
 
-RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. Santesson, Myers, Ankney, Malpani, Galperin, Adams, June 2013.
+RFC5952, Request for Comments: 5952, A Recommendation for IPv6 Address Text Representation. S. Kawamura, et al. August 2010.
 
-RFC6962, Request for Comments: 6962, Certificate Transparency. B. Laurie, A. Langley, E. Kasper. June 2013.
+RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, et al. June 2013.
 
-RFC7231, Request For Comments: 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, R. Fielding, J. Reschke. June 2014.
+RFC6962, Request for Comments: 6962, Certificate Transparency. B. Laurie, et al. June 2013.
 
-RFC7538, Request For Comments: 7538, The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect), J. Reschke. April 2015.
+RFC7231, Request For Comments: 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, et al. June 2014.
 
-RFC7482, Request for Comments: 7482, Registration Data Access Protocol (RDAP) Query Format, Newton, et al, March 2015.
+RFC7482, Request for Comments: 7482, Registration Data Access Protocol (RDAP) Query Format. A. Newton, et al. March 2015.
 
-WebTrust for Certification Authorities, SSL Baseline with Network Security, Version 2.3, available at <https://www.cpacanada.ca/-/media/site/business-and-accounting-resources/docs/webtrust/wt-pcca-ss-lbns2-3.pdf>.
+RFC7538, Request For Comments: 7538, The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. April 2015.
 
-X.509, Recommendation ITU-T X.509 (10/2012) \| ISO/IEC 9594-8:2014 (E), Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks.
+RFC8499, Request for Comments: 8499, DNS Terminology. P. Hoffman, et al. January 2019.
+
+RFC8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, et al. November 2019.
+
+WebTrust for Certification Authorities, SSL Baseline with Network Security, Version 2.5, available at <https://www.cpacanada.ca/-/media/site/operational/ms-member-services/docs/webtrust/wt100bwtbr-25-110120-finalaoda.pdf>.
+
+X.509, Recommendation ITU-T X.509 (08/2005) \| ISO/IEC 9594-8:2005, Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks.
 
 ### 1.6.4 Conventions
 
@@ -490,7 +517,7 @@ The CA SHALL publicly disclose its Certificate Policy and/or Certification Pract
 
 The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647.
 
-Section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement SHALL state the CA's policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements. It shall clearly specify the set of Issuer Domain Names that the CA recognizes in CAA "issue" or "issuewild" records as permitting it to issue. The CA SHALL log all actions taken, if any, consistent with its processing practice.
+Section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement SHALL state the CA's policy or practice on processing CAA Records for Fully-Qualified Domain Names; that policy shall be consistent with these Requirements. It shall clearly specify the set of Issuer Domain Names that the CA recognizes in CAA "issue" or "issuewild" records as permitting it to issue. The CA SHALL log all actions taken, if any, consistent with its processing practice.
 
 The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version. The CA MAY fulfill this requirement by incorporating these Requirements directly into its Certificate Policy and/or Certification Practice Statements or by incorporating them by reference using a clause such as the following (which MUST include a link to the official version of these Requirements):
 
@@ -567,7 +594,7 @@ If the Subject Identity Information is to include a DBA or tradename, the CA SHA
 
 1. Documentation provided by, or communication with, a government agency in the jurisdiction of the Applicant's legal creation, existence, or recognition;
 2. A Reliable Data Source;
-3. Communication with a government agency responsible for the management of such DBAs or tradenames;
+3. Communication with a government agency responsible for the management of such DBAs or trade names;
 4. An Attestation Letter accompanied by documentary support; or
 5. A utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.
 
@@ -590,8 +617,8 @@ This section defines the permitted processes and procedures for validating the A
 
 The CA SHALL confirm that prior to issuance, the CA has validated each Fully-Qualified Domain Name (FQDN) listed in the Certificate as follows:
 
-1. When the FQDN does not contain "onion" as the rightmost label, the CA SHALL validate the FQDN using at least one of the methods listed below; and
-2. When the FQDN contains "onion" as the rightmost label, the CA SHALL validate the FQDN in accordance with Appendix B.
+1. When the FQDN is not an Onion Domain Name, the CA SHALL validate the FQDN using at least one of the methods listed below; and
+2. When the FQDN is an Onion Domain Name, the CA SHALL validate the FQDN in accordance with Appendix B.
 
 Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document) prior to Certificate issuance. For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate.
 
@@ -617,17 +644,11 @@ The CA MAY resend the email, fax, SMS, or postal mail in its entirety, including
 
 The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
 
-**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
+**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.
 
 ##### 3.2.2.4.3 Phone Contact with Domain Contact
 
-Confirming the Applicant's control over the FQDN by calling the Domain Name Registrant's phone number and obtaining a response confirming the Applicant's request for validation of the FQDN. The CA MUST place the call to a phone number identified by the Domain Name Registrar as the Domain Contact.
-
-Each phone call SHALL be made to a single number and MAY confirm control of multiple FQDNs, provided that the phone number is identified by the Domain Registrar as a valid contact method for every Base Domain Name being verified using the phone call.
-
-CAs SHALL NOT perform validations using this method after May 31, 2019. Completed validations using this method SHALL continue to be valid for subsequent issuance per the applicable certificate data reuse periods.
-
-**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
+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.
 
 ##### 3.2.2.4.4 Constructed Email to Domain Contact
 
@@ -645,7 +666,7 @@ The email MAY be re-sent in its entirety, including the re-use of the Random Val
 
 The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
 
-**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
+**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.
 
 ##### 3.2.2.4.5 Domain Authorization Document
 
@@ -653,30 +674,18 @@ This method has been retired and MUST NOT be used. Prior validations using this
 
 ##### 3.2.2.4.6 Agreed-Upon Change to Website
 
-Confirming the Applicant's control over the FQDN by confirming one of the following under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of Domain Validation, on the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an Authorized Port:
-
-1. The presence of Required Website Content contained in the content of a file. The entire Required Website Content MUST NOT appear in the request used to retrieve the file or web page, or
-2. The presence of the Request Token or Random Value contained in the content of a file where the Request Token or Random Value MUST NOT appear in the request.
-
-If a Random Value is used, the CA SHALL provide a Random Value unique to the Certificate request and SHALL not use the Random Value after the longer of
-
-  i. 30 days or
-  ii. if the Applicant submitted the Certificate request, the timeframe permitted for reuse of validated information relevant to the certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of these Guidelines or Section 11.14.3 of the EV Guidelines).
-
-CAs SHALL NOT perform validations using this method after June 3, 2020. CAs MAY continue to re-use information and validations for domains validated under this method per the applicable certificate data reuse periods.
-
-**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
+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.
 
 ##### 3.2.2.4.7 DNS Change
 
-Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record for either 1) an Authorization Domain Name; or 2) an Authorization Domain Name that is prefixed with a label that begins with an underscore character.
+Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record for either 1) an Authorization Domain Name; or 2) an Authorization Domain Name that is prefixed with a Domain Label that begins with an underscore character.
 
 If a Random Value is used, the CA SHALL provide a Random Value unique to the Certificate request and SHALL not use the Random Value after
 
   i. 30 days or
-  ii. if the Applicant submitted the Certificate request, the timeframe permitted for reuse of validated information relevant to the Certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of these Guidelines or Section 11.14.3 of the EV Guidelines).
+  ii. if the Applicant submitted the Certificate request, the time frame permitted for reuse of validated information relevant to the Certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of these Guidelines or Section 11.14.3 of the EV Guidelines).
 
-**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
+**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.
 
 ##### 3.2.2.4.8 IP Address
 
@@ -700,7 +709,7 @@ This method has been retired and MUST NOT be used.
 
 Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact. This method may only be used if the CA is also the Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.
 
-**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
+**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.
 
 ##### 3.2.2.4.13 Email to DNS CAA Contact
 
@@ -710,7 +719,7 @@ Each email MAY confirm control of multiple FQDNs, provided that each email addre
 
 The Random Value SHALL be unique in each email. The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient(s) SHALL remain unchanged. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
 
-**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
+**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.
 
 ##### 3.2.2.4.14 Email to DNS TXT Contact
 
@@ -720,7 +729,7 @@ Each email MAY confirm control of multiple FQDNs, provided that each email addre
 
 The Random Value SHALL be unique in each email. The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient(s) SHALL remain unchanged. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
 
-**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
+**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.
 
 ##### 3.2.2.4.15 Phone Contact with Domain Contact
 
@@ -732,19 +741,19 @@ In the event of reaching voicemail, the CA may leave the Random Value and the AD
 
 The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
 
-**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
+**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.
 
 ##### 3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact
 
 Confirm the Applicant's control over the FQDN by calling the DNS TXT Record Phone Contact’s phone number and obtain a confirming response to validate the ADN. Each phone call MAY confirm control of multiple ADNs provided that the same DNS TXT Record Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN.
 
-The CA MAY NOT knowingly be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation.
+The CA MUST NOT knowingly be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation.
 
 In the event of reaching voicemail, the CA may leave the Random Value and the ADN(s) being validated. The Random Value MUST be returned to the CA to approve the request.
 
 The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
 
-**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
+**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.
 
 ##### 3.2.2.4.17 Phone Contact with DNS CAA Phone Contact
 
@@ -756,7 +765,7 @@ In the event of reaching voicemail, the CA may leave the Random Value and the AD
 
 The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
 
-**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
+**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.
 
 ##### 3.2.2.4.18 Agreed-Upon Change to Website v2
 
@@ -786,8 +795,7 @@ If a Random Value is used, then:
 2. The Random Value MUST remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
 
 **Note**:
-  * For Certificates issued prior to 2021-12-01, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
-  * For Certificates issued on or after 2021-12-01, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.
+  * The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.
 
 ##### 3.2.2.4.19 Agreed-Upon Change to Website - ACME
 
@@ -806,8 +814,7 @@ If the CA follows redirects, the following apply:
 3. Redirects MUST be to resource URLs accessed via Authorized Ports.
 
 **Note**:
-  * For Certificates issued prior to 2021-12-01, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
-  * For Certificates issued on or after 2021-12-01, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.
+  * The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.
 
 ##### 3.2.2.4.20 TLS Using ALPN
 
@@ -836,7 +843,7 @@ Confirming the Applicant's control over the requested IP Address by confirming t
 If a Random Value is used, the CA SHALL provide a Random Value unique to the certificate request and SHALL not use the Random Value after the longer of
 
   i. 30 days or
-  ii. if the Applicant submitted the certificate request, the timeframe permitted for reuse of validated information relevant to the certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document).
+  ii. if the Applicant submitted the certificate request, the time frame permitted for reuse of validated information relevant to the certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document).
 
 ##### 3.2.2.5.2 Email, Fax, SMS, or Postal Mail to IP Address Contact
 
@@ -882,9 +889,10 @@ Confirming the Applicant's control over the IP Address by performing the procedu
 
 #### 3.2.2.6 Wildcard Domain Validation
 
-Before issuing a certificate with a wildcard character (\*) in a CN or `subjectAltName` of type DNS-ID, the CA MUST establish and follow a documented procedure that determines if the wildcard character occurs in the first label position to the left of a "registry-controlled" label or "public suffix" (e.g. "\*.com", "\*.co.uk", see RFC 6454 Section 8.2 for further explanation).
+Before issuing a Wildcard Certificate, the CA MUST establish and follow a documented procedure that determines if the FQDN portion of any
+Wildcard Domain Name in the Certificate is “registry-controlled” or is a “public suffix” (e.g. “\*.com”, “\*.co.uk”, see RFC 6454 Section 8.2 for further explanation).
 
-If a wildcard would fall within the label immediately to the left of a registry-controlled or public suffix, CAs MUST refuse issuance unless the applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue "\*.co.uk" or "\*.local", but MAY issue "\*.example.com" to Example Co.).
+If the FQDN portion of any Wildcard Domain Name is "registry-controlled" or is a "public suffix", CAs MUST refuse issuance unless the Applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue "\*.co.uk" or "\*.local", but MAY issue "\*.example.com" to Example Co.).
 
 Determination of what is "registry-controlled" versus the registerable portion of a Country Code Top-Level Domain Namespace is not standardized at the time of writing and is not a property of the DNS itself. Current best practice is to consult a "public suffix list" such as the [Public Suffix List (PSL)](<http://publicsuffix.org/>), and to retrieve a fresh copy regularly.
 
@@ -904,7 +912,7 @@ Databases maintained by the CA, its owner, or its affiliated companies do not qu
 
 #### 3.2.2.8 CAA Records
 
-As part of the issuance process, the CA MUST check for CAA records and follow the processing instructions found, for each `dNSName` in the `subjectAltName` extension of the certificate to be issued, as specified in RFC 8659. If the CA issues, they MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater.
+As part of the Certificate issuance process, the CA MUST retrieve and process CAA records in accordance with RFC 8659 for each `dNSName` in the `subjectAltName` extension that does not contain an Onion Domain Name. If the CA issues, they MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater.
 
 This stipulation does not prevent the CA from checking CAA records at any other time.
 
@@ -970,7 +978,7 @@ No stipulation.
 
 ### 4.1.1 Who can submit a certificate application
 
-In accordance with [Section 5.5.2](#552-retention-period-for-archive), the CA SHALL maintain an internal database of all previously revoked Certificates and previously rejected certificate requests due to suspected phishing or other fraudulent usage or concerns. The CA SHALL use this information to identify subsequent suspicious certificate requests.
+No stipulation.
 
 ### 4.1.2 Enrollment process and responsibilities
 
@@ -993,7 +1001,7 @@ The certificate request MAY include all factual information about the Applicant
 
 Applicant information MUST include, but not be limited to, at least one Fully-Qualified Domain Name or IP address to be included in the Certificate's `subjectAltName` extension.
 
-[Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in [Section 3.2](#32-initial-identity-validation) to verify certificate information, or may reuse previous validations themselves, provided that the CA obtained the data or document from a source specified under [Section 3.2](#32-initial-identity-validation) or completed the validation itself no more than 825 days prior to issuing the Certificate. Effective 2021-10-01, for validation of Domain Names and IP Addresses according to Section 3.2.2.4 and 3.2.2.5, any reused data, document, or completed validation MUST be obtained no more than 398 days prior to issuing the Certificate.
+[Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in [Section 3.2](#32-initial-identity-validation) to verify certificate information, or may reuse previous validations themselves, provided that the CA obtained the data or document from a source specified under [Section 3.2](#32-initial-identity-validation) or completed the validation itself no more than 825 days prior to issuing the Certificate. For validation of Domain Names and IP Addresses according to Section 3.2.2.4 and 3.2.2.5, any reused data, document, or completed validation MUST be obtained no more than 398 days prior to issuing the Certificate.
 
 In no case may a prior validation be reused if any data or document used in the prior validation was obtained more than the maximum time permitted for reuse of the data or document prior to issuing the Certificate.
 
@@ -1005,7 +1013,7 @@ If a Delegated Third Party fulfills any of the CA's obligations under this secti
 
 ### 4.2.2 Approval or rejection of certificate applications
 
-CAs SHALL NOT issue certificates containing Internal Names (see [Section 7.1.4.2.1](#71421-subject-alternative-name-extension)).
+CAs SHALL NOT issue Certificates containing Internal Names or Reserved IP Addresses (see [Section 7.1.4.2.1](#71421-subject-alternative-name-extension)).
 
 ### 4.2.3 Time to process certificate applications
 
@@ -1151,17 +1159,17 @@ The CA SHALL revoke a Certificate within 24 hours if one or more of the followin
 
 The CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days if one or more of the following occurs:
 
-1. The Certificate no longer complies with the requirements of [Section 6.1.5](#615-key-sizes) and [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking);
-2. The CA obtains evidence that the Certificate was misused;
-3. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use;
-4. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant's right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name);
-5. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;
-6. The CA is made aware of a material change in the information contained in the Certificate;
-7. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's Certificate Policy or Certification Practice Statement;
-8. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate;
-9. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;
-10. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement; or
-11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed.
+6. The Certificate no longer complies with the requirements of [Section 6.1.5](#615-key-sizes) and [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking);
+7. The CA obtains evidence that the Certificate was misused;
+8. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use;
+9. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant's right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name);
+10. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;
+11. The CA is made aware of a material change in the information contained in the Certificate;
+12. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's Certificate Policy or Certification Practice Statement;
+13. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate;
+14. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;
+15. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement; or
+16. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed.
 
 #### 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate
 
@@ -1246,11 +1254,6 @@ The validity interval of an OCSP response is the difference in time between the
 
 For the status of Subscriber Certificates:
 
-Prior to 2020-09-30:
-The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.
-
-Effective 2020-09-30:
-
 1. OCSP responses MUST have a validity interval greater than or equal to eight hours;
 2. OCSP responses MUST have a validity interval less than or equal to ten days;
 3. For OCSP responses with validity intervals less than sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol prior to one-half of the validity period before the nextUpdate.
@@ -1457,7 +1460,7 @@ No stipulation.
 
 ### 5.4.1 Types of events recorded
 
-The CA and each Delegated Third Party SHALL record details of the actions taken to process a certificate request and to issue a Certificate, including all information generated and documentation received in connection with the certificate request; the time and date; and the personnel involved. The CA SHALL make these records available to its Qualified Auditor as proof of the CA’s compliance with these Requirements.
+The CA and each Delegated Third Party SHALL record events related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems. The CA and each Delegated Third Party SHALL record events related to their actions taken to process a certificate request and to issue a Certificate, including all information generated and documentation received in connection with the certificate request; the time and date; and the personnel involved. The CA SHALL make these records available to its Qualified Auditor as proof of the CA’s compliance with these Requirements.
 
 The CA SHALL record at least the following events:
 
@@ -1466,15 +1469,17 @@ The CA SHALL record at least the following events:
    2. Certificate requests, renewal, and re-key requests, and revocation;
    3. Approval and rejection of certificate requests;
    4. Cryptographic device lifecycle management events;
-   5. Generation of Certificate Revocation Lists and OCSP entries;
-   6. Introduction of new Certificate Profiles and retirement of existing Certificate Profiles.
+   5. Generation of Certificate Revocation Lists;
+   6. Signing of OCSP Responses (as described in [Section 4.9](#49-certificate-revocation-and-suspension) and [Section 4.10](#410-certificate-status-services)); and
+   7. Introduction of new Certificate Profiles and retirement of existing Certificate Profiles.
 
 2. Subscriber Certificate lifecycle management events, including:
    1. Certificate requests, renewal, and re-key requests, and revocation;
    2. All verification activities stipulated in these Requirements and the CA's Certification Practice Statement;
    3. Approval and rejection of certificate requests;
-   4. Issuance of Certificates; and
-   5. Generation of Certificate Revocation Lists and OCSP entries.
+   4. Issuance of Certificates; 
+   5. Generation of Certificate Revocation Lists; and 
+   6. Signing of OCSP Responses (as described in [Section 4.9](#49-certificate-revocation-and-suspension) and [Section 4.10](#410-certificate-status-services)).
 
 3. Security events, including:
    1. Successful and unsuccessful PKI system access attempts;
@@ -1487,33 +1492,35 @@ The CA SHALL record at least the following events:
 
 Log records MUST include the following elements:
 
-1. Date and time of record;
+1. Date and time of event;
 2. Identity of the person making the journal record; and
-3. Description of the record.
+3. Description of the event.
 
-### 5.4.2 Frequency for Processing and Archiving Audit Logs
+### 5.4.2 Frequency of processing audit log
 
 No stipulation.
 
-### 5.4.3 Retention Period for Audit Logs
+### 5.4.3 Retention period for audit log
 
-The CA SHALL retain, for at least two years:
+The CA and each Delegated Third Party SHALL retain, for at least two (2) years:
 
   1. CA certificate and key lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (1)) after the later occurrence of:
      1. the destruction of the CA Private Key; or
      2. the revocation or expiration of the final CA Certificate in that set of Certificates that have an X.509v3 `basicConstraints` extension with the `cA` field set to true and which share a common Public Key corresponding to the CA Private Key;
-  2. Subscriber Certificate lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (2)) after the revocation or expiration of the Subscriber Certificate;
+  2. Subscriber Certificate lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (2)) after the expiration of the Subscriber Certificate;
   3. Any security event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (3)) after the event occurred.
 
-### 5.4.4 Protection of Audit Log
+Note: While these Requirements set the minimum retention period, the CA MAY choose a greater value as more appropriate in order to be able to investigate possible security or other types of incidents that will require retrospection and examination of past audit log events.
+
+### 5.4.4 Protection of audit log
 
 No stipulation.
 
-### 5.4.5 Audit Log Backup Procedures
+### 5.4.5 Audit log backup procedures
 
 No stipulation.
 
-### 5.4.6 Audit Log Accumulation System (internal vs. external)
+### 5.4.6 Audit collection System (internal vs. external)
 
 No stipulation.
 
@@ -1533,11 +1540,23 @@ Additionally, the CA's security program MUST include an annual Risk Assessment t
 
 ### 5.5.1 Types of records archived
 
-No stipulation.
+The CA and each Delegated Third Party SHALL archive all audit logs (as set forth in [Section 5.4.1](#541-types-of-events-recorded)).
+
+Additionally, the CA and each Delegated Third Party SHALL archive:
+1. Documentation related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems; and
+2. Documentation related to their verification, issuance, and revocation of certificate requests and Certificates.
 
 ### 5.5.2 Retention period for archive
 
-The CA SHALL retain all documentation relating to certificate requests and the verification thereof, and all Certificates and revocation thereof, for at least seven years after any Certificate based on that documentation ceases to be valid.
+Archived audit logs (as set forth in [Section 5.5.1](#551-types-of-records-archived) SHALL be retained for a period of at least two (2) years from their record creation timestamp, or as long as they are required to be retained per [Section 5.4.3](#543-retention-period-for-audit-log), whichever is longer.
+
+Additionally, the CA and each Delegated Third Party SHALL retain, for at least two (2) years:
+1. All archived documentation related to the security of Certificate Systems, Certificate Management Systems, Root CA Systems and Delegated Third Party Systems (as set forth in [Section 5.5.1](#551-types-of-records-archived)); and
+2. All archived documentation relating to the verification, issuance, and revocation of certificate requests and Certificates (as set forth in [Section 5.5.1](#551-types-of-records-archived)) after the later occurrence of:
+   1. such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or
+   2. the expiration of the Subscriber Certificates relying upon such records and documentation.
+
+Note: While these Requirements set the minimum retention period, the CA MAY choose a greater value as more appropriate in order to be able to investigate possible security or other types of incidents that will require retrospection and examination of past records archived.
 
 ### 5.5.3 Protection of archive
 
@@ -1725,7 +1744,7 @@ If the Issuing CA generated the Private Key on behalf of the Subordinate CA, the
 
 ### 6.2.7 Private key storage on cryptographic module
 
-The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140 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.
+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
 
@@ -1739,7 +1758,7 @@ No stipulation.
 
 No stipulation.
 
-### 6.2.11 Cryptographic Module Capabilities
+### 6.2.11 Cryptographic Module Rating
 
 No stipulation.
 
@@ -2056,9 +2075,10 @@ In addition, the CA MAY use the following signature algorithm and encoding if al
   * The only differences between the new Certificate and existing Certificate are one of the following:
     * A new `subjectPublicKey` within the `subjectPublicKeyInfo`, using the same algorithm and key size; and/or,
     * A new `serialNumber`, of the same encoded length as the existing Certificate; and/or
-    * The new Certificate's `extKeyUsage` extension is present, has at least one key purpose specified, and none of the key purposes specified are the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) or the anyExtendedKeyUsage (OID: 2.5.2937.0) key purposes; and/or
+    * The new Certificate's `extKeyUsage` extension is present, has at least one key purpose specified, and none of the key purposes specified are the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) or the anyExtendedKeyUsage (OID: 2.5.29.37.0) key purposes; and/or
     * The new Certificate's `basicConstraints` extension has a pathLenConstraint that is zero.
 * If used within an OCSP response, such as the `signatureAlgorithm` of a BasicOCSPResponse:
+  * The `producedAt` field value of the ResponseData MUST be earlier than 2022-06-01 00:00:00 UTC; and,
   * All unexpired, un-revoked Certificates that contain the Public Key of the CA Key Pair and that have the same Subject Name MUST also contain an `extKeyUsage` extension with the only key usage present being the id-kp-ocspSigning (OID: 1.3.6.1.5.5.7.3.9) key usage.
 * If used within a CRL, such as the `signatureAlgorithm` field of a CertificateList or the `signature` field of a TBSCertList:
   * The CRL is referenced by one or more Root CA or Subordinate CA Certificates; and,
@@ -2085,9 +2105,7 @@ If the signing key is P-521, the signature MUST use ECDSA with SHA-512. When enc
 
 #### 7.1.4.1 Name Encoding
 
-Prior to 2020-09-30, the content of the Certificate Issuer Distinguished Name field MUST match the Subject DN of the Issuing CA to support Name chaining as specified in RFC 5280, Section 4.1.2.4.
-
-Effective 2020-09-30, the following requirements SHOULD be met by all newly-issued Subordinate CA Certificates that are not used to issue TLS certificates, as defined in [Section 7.1.2.2](#7122-subordinate-ca-certificate), and MUST be met for all other Certificates, regardless of whether the Certificate is a CA Certificate or a Subscriber Certificate.
+The following requirements SHOULD be met by all newly-issued Subordinate CA Certificates that are not used to issue TLS certificates, as defined in [Section 7.1.2.2](#7122-subordinate-ca-certificate), and MUST be met for all other Certificates, regardless of whether the Certificate is a CA Certificate or a Subscriber Certificate.
 
 For every valid Certification Path (as defined by RFC 5280, Section 6):
 
@@ -2104,19 +2122,25 @@ Subject attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e
 
 __Certificate Field:__ `extensions:subjectAltName`  
 __Required/Optional:__ Required  
-__Contents:__ This extension MUST contain at least one entry. Each entry MUST be either a `dNSName` containing the Fully-Qualified Domain Name or an `iPAddress` containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate.
+__Contents:__ This extension MUST contain at least one entry. Each entry MUST be one of the following types:
 
-Wildcard FQDNs are permitted.
+* `dNSName`: The entry MUST contain either a Fully-Qualified Domain Name or Wildcard Domain Name that the CA has validated in accordance with [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). Wildcard Domain Names MUST be validated for consistency with [Section 3.2.2.6](#3226-wildcard-domain-validation). The entry MUST NOT contain an Internal Name.
 
-CAs SHALL NOT issue certificates with a `subjectAltName` extension or `subject:commonName` field containing a Reserved IP Address or Internal Name.
+   The Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name contained in the entry MUST be composed entirely of LDH Labels joined together by a U+002E FULL STOP (".") character. The zero-length Domain Label representing the root zone of the Internet Domain Name System MUST NOT be included (e.g. "example.com" MUST be encoded as "example.com" and MUST NOT be encoded as "example.com.").
 
-Entries in the `dNSName` MUST be in the "preferred name syntax", as specified in RFC 5280, and thus MUST NOT contain underscore characters ("_").
+   The Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name MUST consist solely of Domain Labels that are P-Labels or Non-Reserved LDH Labels.
+
+* `iPAddress`: The entry MUST contain an IPv4 or IPv6 address that the CA has validated in accordance with [Section 3.2.2.5](#3225-authentication-for-an-ip-address). The entry MUST NOT contain a Reserved IP Address.
 
 ##### 7.1.4.2.2 Subject Distinguished Name Fields
 
 a. __Certificate Field:__ `subject:commonName` (OID 2.5.4.3)  
    __Required/Optional:__ __Deprecated__ (Discouraged, but not prohibited)  
-   __Contents:__ If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension (see [Section 7.1.4.2.1](#71421-subject-alternative-name-extension)).
+   __Contents:__ If present, this field MUST contain exactly one entry that is one of the values contained in the Certificate's `subjectAltName` extension (see [Section 7.1.4.2.1](#71421-subject-alternative-name-extension)). The value of the field MUST be encoded as follows:
+
+   * If the value is an IPv4 address, then the value MUST be encoded as an IPv4Address as specified in RFC 3986, Section 3.2.2.
+   * If the value is an IPv6 address, then the value MUST be encoded in the text representation specified in RFC 5952, Section 4.
+   * If the value is a Fully-Qualified Domain Name or Wildcard Domain Name, then the value MUST be encoded as a character-for-character copy of the `dNSName` entry value from the `subjectAltName` extension. Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation.
 
 b. __Certificate Field:__ `subject:organizationName` (OID 2.5.4.10)  
    __Required/Optional:__ __Optional__.  
@@ -2137,14 +2161,14 @@ e. __Certificate Field:__ `subject:localityName` (OID: 2.5.4.7)
    __Required__ if the `subject:organizationName` field, `subject:givenName` field, or `subject:surname` field are present and the `subject:stateOrProvinceName` field is absent.  
    __Optional__ if the `subject:stateOrProvinceName` field and the `subject:organizationName` field, `subject:givenName` field, or `subject:surname` field are present.  
    __Prohibited__ if the `subject:organizationName` field, `subject:givenName`, and `subject:surname` field are absent.  
-   __Contents:__ If present, the `subject:localityName` field MUST contain the Subject's locality information as verified under [Section 3.2.2.1](#3221-identity). If the `subject:countryName` field specifies the ISO 3166-1 user-assigned code of XX in accordance with [Section 7.1.4.2.2](#71422-subject-distinguished-name-fields) (g), the `localityName` field MAY contain the Subject's locality and/or state or province information as verified under [Section 3.2.2.1](#3221-identity).
+   __Contents:__ If present, the `subject:localityName` field MUST contain the Subject's locality information as verified under [Section 3.2.2.1](#3221-identity). If the `subject:countryName` field specifies the ISO 3166-1 user-assigned code of XX in accordance with [Section 7.1.4.2.2](#71422-subject-distinguished-name-fields) (h), the `localityName` field MAY contain the Subject's locality and/or state or province information as verified under [Section 3.2.2.1](#3221-identity).
 
 f. __Certificate Field:__ `subject:stateOrProvinceName` (OID: 2.5.4.8)  
    __Required/Optional:__  
    __Required__ if the `subject:organizationName` field, `subject:givenName` field, or `subject:surname` field are present and `subject:localityName` field is absent.  
    __Optional__ if the `subject:localityName` field and the `subject:organizationName` field, the `subject:givenName` field, or the `subject:surname` field are present.  
    __Prohibited__ if the `subject:organizationName` field, the `subject:givenName` field, or `subject:surname` field are absent.  
-   __Contents:__ If present, the `subject:stateOrProvinceName` field MUST contain the Subject's state or province information as verified under [Section 3.2.2.1](#3221-identity). If the `subject:countryName` field specifies the ISO 3166-1 user-assigned code of XX in accordance with [Section 7.1.4.2.2](#71422-subject-distinguished-name-fields) (g), the `subject:stateOrProvinceName` field MAY contain the full name of the Subject's country information as verified under [Section 3.2.2.1](#3221-identity).
+   __Contents:__ If present, the `subject:stateOrProvinceName` field MUST contain the Subject's state or province information as verified under [Section 3.2.2.1](#3221-identity). If the `subject:countryName` field specifies the ISO 3166-1 user-assigned code of XX in accordance with [Section 7.1.4.2.2](#71422-subject-distinguished-name-fields) (h), the `subject:stateOrProvinceName` field MAY contain the full name of the Subject's country information as verified under [Section 3.2.2.1](#3221-identity).
 
 g. __Certificate Field:__ `subject:postalCode` (OID: 2.5.4.17)  
    __Required/Optional:__  
@@ -2159,8 +2183,7 @@ h. __Certificate Field:__ `subject:countryName` (OID: 2.5.4.6)
    __Contents:__ If the `subject:organizationName` field is present, the `subject:countryName` MUST contain the two-letter ISO 3166-1 country code associated with the location of the Subject verified under [Section 3.2.2.1](#3221-identity). If the `subject:organizationName` field is absent, the `subject:countryName` field MAY contain the two-letter ISO 3166-1 country code associated with the Subject as verified in accordance with [Section 3.2.2.3](#3223-verification-of-country). If a Country is not represented by an official ISO 3166-1 country code, the CA MAY specify the ISO 3166-1 user-assigned code of XX indicating that an official ISO 3166-1 alpha-2 code has not been assigned.
 
 i. __Certificate Field:__ `subject:organizationalUnitName` (OID: 2.5.4.11)  
-   __Required/Optional:__ __Optional__.  
-   __Contents__: The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with [Section 3.2](#32-initial-identity-validation) and the Certificate also contains `subject:organizationName`, `subject:givenName`, `subject:surname`, `subject:localityName`, and `subject:countryName` attributes, also verified in accordance with [Section 3.2.2.1](#3221-identity).
+   __Required/Optional:__ __Prohibited__. 
 
 j. Other Subject Attributes  
    Other attributes MAY be present within the subject field. If present, other attributes MUST contain information that has been verified by the CA.
@@ -2247,12 +2270,10 @@ The Subordinate CA and the Issuing CA SHALL represent, in their Certificate Poli
 
 #### 7.1.6.4 Subscriber Certificates
 
-Effective 2020-09-30, a Certificate issued to a Subscriber MUST contain, within the Certificate's `certificatePolicies` extension, one or more policy identifier(s) that are specified beneath the CA/Browser Forum's reserved policy OID arc of `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1)} (2.23.140.1)`.
+A Certificate issued to a Subscriber MUST contain, within the Certificate's `certificatePolicies` extension, one or more policy identifier(s) that are specified beneath the CA/Browser Forum's reserved policy OID arc of `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1)} (2.23.140.1)`.
 
 The certificate MAY also contain additional policy identifier(s) defined by the Issuing CA. The issuing CA SHALL document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these requirements.
 
-For certificates issued prior to 2020-09-30, a Certificate issued to a Subscriber MUST contain a `certificatePolicies` extension. The extension MUST contain one or more policy identifiers that indicate adherence to and compliance with these Requirements. CAs MUST either use a CA/Browser Forum identifier reserved for this purpose or MUST use a policy identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement to indicate the Certificate's compliance with these Requirements.
-
 Prior to including a Reserved Certificate Policy Identifier, the CA MUST ensure the following requirements are met:
 
 * __Certificate Policy Identifier:__ `2.23.140.1.2.1`
@@ -2301,8 +2322,6 @@ No stipulation.
 
 1. `reasonCode` (OID 2.5.29.21)
 
-   Effective 2020-09-30, all of the following requirements MUST be met:
-
    If present, this extension MUST NOT be marked critical.
 
    If a CRL entry is for a Root CA or Subordinate CA Certificate, including Cross Certificates, this CRL entry extension MUST be present.
@@ -2313,12 +2332,16 @@ No stipulation.
    If a CRL entry is for a Certificate subject to these Requirements, the `CRLReason` MUST NOT be certificateHold (6).
 
    If a `reasonCode` CRL entry extension is present, the `CRLReason` MUST indicate the most appropriate reason for revocation of the certificate, as defined by the CA within its CP/CPS.
+   
+2. `issuingDistributionPoint` (OID 2.5.29.28)
+
+   Effective 2023-01-15, if a CRL does not contain entries for all revoked unexpired certificates issued by the CRL issuer, then it MUST contain a critical Issuing Distribution Point extension and MUST populate the `distributionPoint` field of that extension.
 
 ## 7.3 OCSP profile
 
-Effective 2020-09-30, if an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross Certificates, and that certificate has been revoked, then the `revocationReason` field within the `RevokedInfo` of the `CertStatus` MUST be present.
+If an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross Certificates, and that certificate has been revoked, then the `revocationReason` field within the `RevokedInfo` of the `CertStatus` MUST be present.
 
-Effective 2020-09-30, the `CRLReason` indicated MUST contain a value permitted for CRLs, as specified in [Section 7.2.2](#722-crl-and-crl-entry-extensions).
+The `CRLReason` indicated MUST contain a value permitted for CRLs, as specified in [Section 7.2.2](#722-crl-and-crl-entry-extensions).
 
 ### 7.3.1 Version number(s)
 
@@ -2332,10 +2355,9 @@ The `singleExtensions` of an OCSP response MUST NOT contain the `reasonCode` (OI
 
 The CA SHALL at all times:
 
-1. 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;
-2. Comply with these Requirements;
-3. Comply with the audit requirements set forth in this section; and
-4. Be licensed as a CA in each jurisdiction where it operates, if licensing is required by the law of such jurisdiction for the issuance of Certificates.
+1. Comply with these Requirements;
+2. Comply with the audit requirements set forth in this section; and
+3. Be licensed as a CA in each jurisdiction where it operates, if licensing is required by the law of such jurisdiction for the issuance of Certificates.
 
 **Implementers' Note**: Version 1.1.6 of the SSL Baseline Requirements was published on July 29, 2013. Version 2.0 of WebTrust's Principles and Criteria for Certification Authorities - SSL Baseline with Network Security and ETSI's Electronic Signatures and Infrastructures (ESI) 102 042 incorporate version 1.1.6 of these Requirements and version 1.0 of the Network and Certificate System Security Requirements. The CA/Browser Forum continues to improve the Baseline Requirements while WebTrust and ETSI also continue to update their audit criteria. We encourage all CAs to conform to each revision herein on the date specified without awaiting a corresponding update to an applicable audit criterion. In the event of a conflict between an existing audit criterion and a guideline revision, we will communicate with the audit community and attempt to resolve any uncertainty, and we will respond to implementation questions directed to <questions@cabforum.org>. Our coordination with compliance auditors will continue as we develop guideline revision cycles that harmonize with the revision cycles for audit criteria, the compliance auditing periods and cycles of CAs, and the CA/Browser Forum's guideline implementation dates.
 
@@ -2393,8 +2415,6 @@ The Audit Report SHALL state explicitly that it covers the relevant systems and
 
 The CA MUST make its Audit Report publicly available no later than three months after the end of the audit period. In the event of a delay greater than three months, the CA SHALL provide an explanatory letter signed by the Qualified Auditor.
 
-For Audit Reports in which the Audit Period includes a date later than 2020-08-01, then the requirements set forth in the remainder of this [Section 8.6](#86-communication-of-results) SHALL be met. Audit Reports for Audit Periods that conclude prior to 2020-08-01 SHOULD meet these requirements.
-
 The Audit Report MUST contain at least the following clearly-labelled information:
 
 1. name of the organization being audited;
@@ -2529,20 +2549,16 @@ The Certificate Warranties specifically include, but are not limited to, the fol
    ii. followed the procedure when issuing the Certificate; and
    iii. accurately described the procedure in the CA's Certificate Policy and/or Certification Practice Statement;
 3. **Accuracy of Information**: That, at the time of issuance, the CA
-   i. implemented a procedure for verifying the accuracy of all of the information contained in the Certificate (with the exception of the subject:organizationalUnitName attribute);
+   i. implemented a procedure for verifying the accuracy of all of the information contained in the Certificate;
    ii. followed the procedure when issuing the Certificate; and
    iii. accurately described the procedure in the CA's Certificate Policy and/or Certification Practice Statement;
-4. **No Misleading Information**: That, at the time of issuance, the CA
-   i. implemented a procedure for reducing the likelihood that the information contained in the Certificate's subject:organizationalUnitName attribute would be misleading;
-   ii. followed the procedure when issuing the Certificate; and
-   iii. accurately described the procedure in the CA's Certificate Policy and/or Certification Practice Statement;
-5. **Identity of Applicant**: That, if the Certificate contains Subject Identity Information, the CA
+4. **Identity of Applicant**: That, if the Certificate contains Subject Identity Information, the CA
    i. implemented a procedure to verify the identity of the Applicant in accordance with [Section 3.2](#32-initial-identity-validation) and [Section 7.1.4.2.2](#71422-subject-distinguished-name-fields);
    ii. followed the procedure when issuing the Certificate; and
    iii. accurately described the procedure in the CA's Certificate Policy and/or Certification Practice Statement;
-6. **Subscriber Agreement**: That, if the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements, or, if the CA and Subscriber are the same entity or are Affiliated, the Applicant Representative acknowledged the Terms of Use;
-7. **Status**: That the CA maintains a 24 x 7 publicly-accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates; and
-8. **Revocation**: That the CA will revoke the Certificate for any of the reasons specified in these Requirements.
+5. **Subscriber Agreement**: That, if the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements, or, if the CA and Subscriber are the same entity or are Affiliated, the Applicant Representative acknowledged the Terms of Use;
+6. **Status**: That the CA maintains a 24 x 7 publicly-accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates; and
+7. **Revocation**: That the CA will revoke the Certificate for any of the reasons specified in these Requirements.
 
 The Root CA SHALL be responsible for the performance and warranties of the Subordinate CA, for the Subordinate CA's compliance with these Requirements, and for all liabilities and indemnification obligations of the Subordinate CA under these Requirements, as if the Root CA were the Subordinate CA issuing the Certificates
 
@@ -2639,7 +2655,7 @@ No stipulation.
 
 ## 9.15 Compliance with applicable law
 
-No stipulation.
+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.
 
 ## 9.16 Miscellaneous provisions
 
@@ -2717,32 +2733,34 @@ The DNS TXT record MUST be placed on the "`_validation-contactemail`" subdomain
 
 The DNS TXT record MUST be placed on the "`_validation-contactphone`" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid Global Number as defined in RFC 3966, Section 5.1.4, or it cannot be used.
 
-# APPENDIX B – Issuance of Certificates for .onion Domain Names
+# APPENDIX B – Issuance of Certificates for Onion Domain Names
 
-This appendix defines permissible verification procedures for including one or more RFC 7686 ".onion" special-use Domain Names in a Certificate.
+This appendix defines permissible verification procedures for including one or more Onion Domain Names in a Certificate.
 
-1. The Domain Name MUST contain at least two labels, where the right-most label is "onion", and the label immediately preceding the right-most "onion" label is a valid Version 3 Onion Address, as defined in Section 6 of the Tor Rendezvous Specification - Version 3 located at <https://spec.torproject.org/rend-spec-v3>.
+1. The Domain Name MUST contain at least two Domain Labels, where the rightmost Domain Label is "onion", and the Domain Label immediately preceding the rightmost "onion" Domain Label is a valid Version 3 Onion Address, as defined in Section 6 of the Tor Rendezvous Specification - Version 3 located at <https://spec.torproject.org/rend-spec-v3>.
 
-2. The CA MUST verify the Applicant’s control over the .onion Domain Name using at least one of the methods listed below:
+2. The CA MUST verify the Applicant’s control over the Onion Domain Name using at least one of the methods listed below:
 
    a. The CA MAY verify the Applicant's control over the .onion service by using one of the following methods from [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control):
 
-      i. [Section 3.2.2.4.6 - Agreed-Upon Change to Website](#32246-agreed-upon-change-to-website)
-      ii. [Section 3.2.2.4.18 - Agreed-Upon Change to Website v2](#322418-agreed-upon-change-to-website-v2)
-      iii. [Section 3.2.2.4.19 - Agreed-Upon Change to Website - ACME](#322419-agreed-upon-change-to-website-acme)
+      i. [Section 3.2.2.4.18 - Agreed-Upon Change to Website v2](#322418-agreed-upon-change-to-website-v2)
+      ii. [Section 3.2.2.4.19 - Agreed-Upon Change to Website - ACME](#322419-agreed-upon-change-to-website---acme)
+      iii. [Section 3.2.2.4.20 - TLS Using ALPN](#322420-tls-using-alpn)
 
       When these methods are used to verify the Applicant's control over the .onion service, the CA MUST use Tor protocol to establish a connection to the .onion hidden service. The CA MUST NOT delegate or rely on a third-party to establish the connection, such as by using Tor2Web.
 
       **Note**: This section does not override or supersede any provisions specified within the respective methods. The CA MUST only use a method if it is still permitted within that section and MUST NOT issue Wildcard Certificates or use it as an Authorization Domain Name, except as specified by that method.
 
-   b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains:
+   b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion service's private key if the Attributes section of the certificationRequestInfo contains:
 
       i. A caSigningNonce attribute that contains a Random Value that is generated by the CA; and
-      ii. An applicantSigningNonce attribute that contains a single value with at least 64-bits of entropy that is generated by the Applicant.
+      ii. An applicantSigningNonce attribute that contains a single value. The CA MUST recommend to Applicants that the applicantSigningNonce value should contain at least 64 bits of entropy.
 
       The signing nonce attributes have the following format:
 
       ```ASN.1
+      cabf OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) }
+
       caSigningNonce ATTRIBUTE ::= {
          WITH SYNTAX              OCTET STRING
          EQUALITY MATCHING RULE   octetStringMatch
@@ -2766,4 +2784,4 @@ This appendix defines permissible verification procedures for including one or m
 
       Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
 
-3. When a Certificate includes an FQDN where "onion" is in the right-most label of the Domain Name, the Domain Name shall not be considered an Internal Name provided that the Certificate was issued in compliance with this [Appendix B](#appendix-b--issuance-of-certificates-for-onion-domain-names).
+3. When a Certificate includes an Onion Domain Name, the Domain Name shall not be considered an Internal Name provided that the Certificate was issued in compliance with this [Appendix B](#appendix-b--issuance-of-certificates-for-onion-domain-names).

archive/CPS.md

@@ -6,11 +6,11 @@ This Certification Practice Statement ("CPS") document outlines the certificatio
 
 ISRG PKI services include, but are not limited to, issuing, managing, validating, revoking, and renewing publicly-trusted Certificates in accordance with the requirements of the ISRG Certificate Policy (CP) and in a manner consistent with this CPS. It is recommended that readers familiarize themselves with the ISRG CP prior to reading this document.
 
-These services are provided to the general public with exceptions as deemed appropriate by ISRG management or in accordance with relevant law.
+These services are provided to the general public with exceptions as ISRG management deems appropriate or in accordance with relevant law.
 
 ISRG PKI services are most commonly, but not necessarily exclusively, provided under the brand/trademark "Let's Encrypt".
 
-The ISRG PKI conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at <http://www.cabforum.org>. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.
+The ISRG PKI conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at <https://www.cabforum.org>. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.
 
 Other documents related to the behavior and control of the ISRG PKI, such as a Subscriber Agreement and Privacy Policy, can be found at <https://letsencrypt.org/repository/>.
 
@@ -21,15 +21,15 @@ The following Certification Authorities are covered under this CPS:
 | CA Type | Distinguished Name | Key Pair Type and Parameters | Cert SHA-256 Fingerprint | Validity Period |
 |---------|--------------------|------------------------------|--------------------------|-----------------|
 | Root CA | C=US,<br>O=Internet Security Research Group,<br>CN=ISRG Root X1 | RSA, n has 4096 bits, e=65537 | 96:BC:EC:06:26:49:76:F3:<br>74:60:77:9A:CF:28:C5:A7:<br>CF:E8:A3:C0:AA:E1:1A:8F:<br>FC:EE:05:C0:BD:DF:08:C6 | Not Before: Jun  4 11:04:38 2015 GMT,<br>Not After: Jun  4 11:04:38 2035 GMT |
-| Root CA | C=US,<br>O=Internet Security Research Group,<br>CN=ISRG Root X2 | ECDSA, NIST curve P-384 | 69:72:9b:8e:15:a8:6e:fc:<br>17:7a:57:af:b7:17:1d:fc:<br>64:ad:d2:8c:2f:ca:8c:f1:<br>50:7e:34:45:3c:cb:14:70 | Not Before: Sept  4 00:00:00 2020 GMT,<br>Not After: Sept 17 16:00:00 2040 GMT |
+| Root CA | C=US,<br>O=Internet Security Research Group,<br>CN=ISRG Root X2 | ECDSA, NIST curve P-384 | 69:72:9B:8E:15:A8:6E:FC:<br>17:7A:57:AF:B7:17:1D:FC:<br>64:AD:D2:8C:2F:CA:8C:F1:<br>50:7E:34:45:3C:CB:14:70 | Not Before: Sept  4 00:00:00 2020 GMT,<br>Not After: Sept 17 16:00:00 2040 GMT |
 
 This work is licensed under the Creative Commons Attribution 4.0 International License. To
-view a copy of this license, visit <http://creativecommons.org/licenses/by/4.0/> or send a letter to Creative
+view a copy of this license, visit <https://creativecommons.org/licenses/by/4.0/> or send a letter to Creative
 Commons, PO Box 1866, Mountain View, CA 94042, USA.
 
 ## 1.2 Document name and identification
 
-This is the ISRG Certification Practices Statement. This document was approved for publication by the ISRG Policy Management Authority, and is made available at <https://letsencrypt.org/repository/>.
+This is the ISRG Certification Practice Statement. This document was approved for publication by the ISRG Policy Management Authority, and is made available at <https://letsencrypt.org/repository/>.
 
 The following revisions have been made:
 
@@ -57,6 +57,10 @@ The following revisions have been made:
 | June  8, 2021 | Section 7.1 end entity certificate lifetime specification updated to match Section 6.3.2. Update BR references in Section 3.2.2. Add Section 4.2.4 regarding CAA checking. State in Section 6.7 that the CA complies with the CA/Browser Forum's Network and Certificate System Security Requirements. | 3.3 |
 | July 19, 2021 | Extensive changes. | 4.0 |
 | August 20, 2021 | Update mailing address. De-duplicate terms defined in ISRG CP. Make section titles consistent with BRs and ISRG CP. Replace use of "domain" with FQDN. Other minor formatting changes. | 4.1 |
+| December 22, 2021 | Update list of trusted roles in Section 5.2.1. Minor changes to Section 9. Minor typo and consistency improvements. | 4.2 |
+| May 6, 2022 | Update audit log and records archival retention periods. | 4.3 |
+| September 28, 2022 | Update Sections 4.9.7 & 4.10.1 to cover CRLs for Subscriber Certificates. Clarify language about background checks in Section 5.3.2. | 4.4 |
+| March 10, 2023 | Make CN optional in subscriber cert profile. Add subscriber CRL profile. Update indemnity language in Section 9.9.3. Minor grammatical, punctuation, and formatting changes. | 4.5 |
 
 ## 1.3 PKI Participants
 
@@ -92,8 +96,8 @@ No stipulation.
 
 Certificates may not be used:
 
-* For any application requiring fail-safe performance such as a) the operation of nuclear power facilities b) air traffic control systems c) aircraft navigation systems d) weapons control systems e) any other system in which failure could lead to injury, death, or environmental damage.
-* For software or hardware architectures that provide facilities for interference with encrypted communications, including but not limited to a) active eavesdropping (e.g., monster-in-the-middle attacks) b) traffic management of domain names or internet protocol addresses that the organization does not own or control. Note that these restrictions shall apply regardless of whether a relying party communicating through the software or hardware architecture has knowledge of its providing facilities for interference with encrypted communications.
+* For any application requiring fail-safe performance, such as: a) the operation of nuclear power facilities; b) air traffic control systems; c) aircraft navigation systems; d) weapons control systems; or e) any other system in which failure could lead to injury, death, or environmental damage.
+* For software or hardware architectures that provide facilities for interference with encrypted communications, including but not limited to: a) active eavesdropping (e.g., monster-in-the-middle attacks); or b) traffic management of domain names or internet protocol addresses that the organization does not own or control. Note that these restrictions shall apply regardless of whether a relying party communicating through the software or hardware architecture has knowledge of its providing facilities for interference with encrypted communications.
 
 Note that Certificates do not guarantee anything regarding reputation, honesty, or the current state of endpoint security. A Certificate only represents that the information contained in it was verified as reasonably correct when the Certificate was issued.
 
@@ -101,7 +105,7 @@ Note that Certificates do not guarantee anything regarding reputation, honesty,
 
 ### 1.5.1 Organization Administering the Document
 
-This CPS document is maintained by the ISRG PMA.
+The ISRG PMA maintains this CPS document.
 
 ### 1.5.2 Contact Person
 
@@ -131,45 +135,38 @@ The ISRG PMA approves any revisions to this CPS document after formal review.
 
 ### 1.6.1 Definitions
 
-* ACME Protocol
-  * A protocol used for validation, issuance, and management of certificates. The protocol is an open standard managed by the IETF.
-* Baseline Requirements
-  * A document published by the CAB Forum which outlines minimum requirements for publicly trusted Certificate Authorities.
-* CAB Forum
-  * Certificate Authority / Browser Forum, a group a CAs and browsers which come together to discuss technical and policy issues related to PKI systems. (<https://cabforum.org/>)
-* Certificate Repository
-  * A repository of information about ISRG certificates. It is located at: <https://letsencrypt.org/certificates/>
-* Policy and Legal Repository
-  * A repository of policy and legal documents related to the ISRG PKI. It is located at: <https://letsencrypt.org/repository/>
-* Precertificate
-  * A certificate containing a critical poison extension as defined by RFC 6962 Section 3.1.
-* Secure PKI Facilities
-  * Facilities designed to protect sensitive PKI infrastructure, including CA private keys.
-* Trusted Contributor
-  * A contributor who performs in a Trusted Role. Trusted Contributors may be employees, contractors, or community members. Trusted Contributors must be properly trained and qualified, and have the proper legal obligations in place before performing in a Trusted Role.
-* Trusted Role
-  * A role which qualifies a person to access or modify ISRG PKI systems, infrastructure, and confidential information.
+**ACME Protocol**: A protocol used for validation, issuance, and management of certificates. The protocol is an open standard managed by the IETF.
+
+**Baseline Requirements**: A document published by the CAB Forum which outlines minimum requirements for publicly trusted Certificate Authorities.
+
+**CAB Forum**: Certificate Authority / Browser Forum, a group of CAs and browsers which come together to discuss technical and policy issues related to PKI systems. (<https://cabforum.org/>)
+
+**Certificate Repository**: A repository of information about ISRG certificates. It is located at: <https://letsencrypt.org/certificates/>
+
+**Policy and Legal Repository**: A repository of policy and legal documents related to the ISRG PKI. It is located at: <https://letsencrypt.org/repository/>
+
+**Precertificate**: A certificate containing a critical poison extension as defined by RFC 6962 Section 3.1.
+
+**Secure PKI Facilities**: Facilities designed to protect sensitive PKI infrastructure, including CA private keys.
+
+**Trusted Contributor**: A contributor who performs in a Trusted Role. Trusted Contributors may be employees, contractors, or community members. Trusted Contributors must be properly trained and qualified, and have the proper legal obligations in place before performing in a Trusted Role.
+
+**Trusted Role**: A role which qualifies a person to access or modify ISRG PKI systems, infrastructure, and confidential information.
 
 See ISRG CP 1.6.1 for additional definitions.
 
 ### 1.6.2 Acronyms
 
-* ACME
-  * Automated Certificate Management Environment
-* DV
-  * Domain Validation
-* HSM
-  * Hardware Security Module
-* IP
-  * Internet Protocol
-* ISRG
-  * Internet Security Research Group
-* PMA
-  * Policy Management Authority
-* SAN
-  * Subject Alternative Name
-* TLD
-  * Top Level Domain
+| **Acronym** | **Meaning** |
+| --- | --- |
+| ACME | Automated Certificate Management Environment |
+| DV | Domain Validation |
+| HSM | Hardware Security Module |
+| IP | Internet Protocol |
+| ISRG | Internet Security Research Group |
+| PMA | Policy Management Authority |
+| SAN | Subject Alternative Name |
+| TLD | Top Level Domain |
 
 See ISRG CP 1.6.2 for additional acronyms.
 
@@ -179,9 +176,9 @@ No references defined at this time.
 
 ### 1.6.4 Conventions
 
-Terms not otherwise defined in this CPS shall be as defined in applicable agreements, user manuals, Certificate Policies and Certification Practice Statements, of the CA.
+Terms not otherwise defined in this CPS shall be as defined in applicable agreements, user manuals, Certificate Policies, and Certification Practice Statements of the CA.
 
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in these Requirements shall be interpreted in accordance with RFC 2119.
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this CPS shall be interpreted in accordance with RFC 2119.
 
 # 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
 
@@ -269,7 +266,7 @@ All validations are performed in compliance with the current CAB Forum Baseline
 
 ### 3.2.3 Authentication of individual identity
 
-ISRG does not issue certificates to individuals, and thus does not authenticate individual identities.
+ISRG does not issue Subscriber Certificates containing Subject Identity Information, and thus does not validate any natural person's identity.
 
 ### 3.2.4 Non-verified subscriber information
 
@@ -297,7 +294,7 @@ See Section 4.7.
 
 Identification and authentication for revocation requests is performed by ISRG in compliance with Section 4.9 of this document.
 
-Identification and authentication are not required when revocation is being requested by ISRG.
+Identification and authentication are not required when ISRG is requesting revocation.
 
 # 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
 
@@ -325,13 +322,13 @@ Certificate information is verified using data and documents obtained no more th
 
 As part of the issuance process, ISRG checks for CAA records and follows the processing instructions found, for each dNSName in the subjectAltName extension of the certificate to be issued, as specified in RFC 8659 and Section 3.2.2.8 of the ISRG CP. The CA acts in accordance with CAA records if present. If the CA issues, the CA will do so within the TTL of the CAA record, or 8 hours, whichever is greater. The CA's CAA identifying domain is `letsencrypt.org`.
 
-ISRG maintains a list of high-risk domains and blocks issuance of certificates for those domains. Requests for removal from the high-risk domains list will be considered, but will likely require further documentation confirming control of the domain from the Applicant, or other proof as deemed necessary by ISRG management.
+ISRG maintains a list of high-risk domains and blocks issuance of certificates for those domains. Requests for removal from the high-risk domains list will be considered, but will likely require further documentation confirming control of the domain from the Applicant, or other proof as ISRG management deems necessary.
 
 ### 4.2.2 Approval or rejection of certificate applications
 
 Approval requires successful completion of validation per Section 3.2.2 as well as compliance with all CA policies.
 
-Certificates containing a new gTLD under consideration by ICANN will not be issued. The CA Server will periodically be updated with the latest version of the Public Suffix List and will consult the ICANN domains section for every requested DNS identifier. CA server will not validate or issue for DNS identifiers that do not have a Public Suffix in the ICANN domains section. The Public Suffix List is updated when new gTLDs are added, and never includes new gTLDs before they are resolvable.
+Certificates containing a new gTLD under consideration by ICANN will not be issued. The CA Server will periodically be updated with the latest version of the Public Suffix List and will consult the ICANN domains section for every requested DNS identifier. The CA server will not validate or issue for DNS identifiers that do not have a Public Suffix in the ICANN domains section.
 
 ### 4.2.3 Time to process certificate applications
 
@@ -489,11 +486,11 @@ Anyone can revoke any certificate via the ACME API if they can demonstrate contr
 
 Subscribers can revoke certificates belonging to their accounts via the ACME API if they can sign the revocation request with the associated account private key. No other information is required in such cases.
 
-Certificates may be administratively revoked by ISRG if it is determined that the Subscriber has failed to meet obligations under the ISRG CP, this CPS, the relevant Subscriber Agreement, or any other applicable agreement, regulation, or law. Certificates may also be administratively revoked at the discretion of ISRG management.
+ISRG may administratively revoke certificates if it determines that the Subscriber has failed to meet obligations under the ISRG CP, this CPS, the relevant Subscriber Agreement, or any other applicable agreement, regulation, or law. Certificates may also be administratively revoked at ISRG management's discretion.
 
 ### 4.9.3 Procedure for revocation request
 
-Revocation requests may be made by anyone, at any time, via the Certificate Revocation interface of the ACME Protocol defined in RFC 8555 section 7.6. Successful revocation requests with a reason code of `keyCompromise` will result in the affected key being blocked for future issuance and all currently valid certificates with that key will be revoked, regardless of whether compromise was demonstrated per the requirements in Section 4.9.12 of this document.
+Anyone may make revocation requests, at any time, via the Certificate Revocation interface of the ACME Protocol defined in RFC 8555 section 7.6. Successful revocation requests with a reason code of `keyCompromise` will result in the affected key being blocked for future issuance and all currently valid certificates with that key will be revoked, regardless of whether compromise was demonstrated per the requirements in Section 4.9.12 of this document.
 
 Requests for revocation may also be made by emailing [cert-prob-reports@letsencrypt.org](mailto:cert-prob-reports@letsencrypt.org). ISRG maintains a continuous (24x7) ability to accept and respond to revocation requests and Certificate Problem Reports. ISRG will respond to such requests within 24 hours, though an investigation into the legitimacy of the request may take longer.
 
@@ -520,13 +517,11 @@ See Section 4.5.2.
 
 ### 4.9.7 CRL issuance frequency (if applicable)
 
-ISRG will issue updated CRLs for Subordinate CA certificates with a frequency greater than or equal to that required by the ISRG CP.
-
-ISRG does not issue CRLs for Subscriber Certificates.
+ISRG will issue updated CRLs with the frequency required by the ISRG CP.
 
 ### 4.9.8 Maximum latency for CRLs (if applicable)
 
-When a CRL is requested by a Relying Party the time to receive a response will be less than ten seconds under normal operating conditions.
+When a Relying Party requests a CRL, the time to receive a response will be less than ten seconds under normal operating conditions.
 
 ### 4.9.9 On-line revocation/status checking availability
 
@@ -564,9 +559,7 @@ Not applicable.
 
 ### 4.10.1 Operational characteristics
 
-CRL entries for Subordinate CA certificates will remain in place until the certificates expire. ISRG does not provide CRLs for Subscriber Certificates.
-
-OCSP responses will be made available for all unexpired Subscriber certificates.
+ISRG will retain revocation entries on a CRL or OCSP Response as required by the ISRG CP.
 
 ### 4.10.2 Service availability
 
@@ -634,7 +627,7 @@ ISRG prohibits any media that contains or has contained sensitive data from leav
 
 ### 5.1.8 Off-site backup
 
-ISRG maintains multiple backups of ISRG CA Private Keys at multiple Secure PKI Facilities. All backups are stored on devices meeting FIPS 140 Level 3 criteria.
+ISRG maintains multiple backups of ISRG CA Private Keys at multiple Secure PKI Facilities. All backups are stored on devices meeting FIPS 140-2 Level 3 criteria.
 
 ## 5.2 Procedural controls
 
@@ -644,14 +637,22 @@ All persons, employees or otherwise, with the ability to materially impact the o
 
 Trusted Roles include, but are not limited to:
 
-* Management
-  * May view confidential information but may not directly impact CA operations. Strong decision-making authority.
-* Security Officers
-  * May view confidential information but may not directly impact CA operations. Strong decision-making authority.
-* Systems Administrators
-  * May view confidential information and directly impact CA operations. Decision-making authority is limited.
-* Engineering Liaisons
-  * May view confidential information but may not directly impact CA operations. No decision-making authority.
+* PKI Administrators
+  * Confidential Information: Direct access on a need-to-know basis
+  * Environment Access: Test yes, production yes
+  * CA Decision-making Authority: Yes
+* PKI Staff
+  * Confidential Information: View on a need-to-know basis
+  * Environment Access: Test yes, production no
+  * CA Decision-making Authority: Yes
+* PKI Partners
+  * Confidential Information: View on a need-to-know basis
+  * Environment Access: Test yes, production no
+  * CA Decision-making Authority: No
+* Non-PKI Staff
+  * Confidential Information: View on a need-to-know basis
+  * Environment Access: Test no, production no
+  * CA Decision-making Authority: No
 
 Each Trusted Role requires an appropriate level of training and legal obligation.
 
@@ -679,7 +680,7 @@ ISRG management ensures this with appropriate interviewing practices, training,
 
 Trusted Contributors must undergo a background check prior to performing in a trusted role. ISRG management will review the results of background checks for problematic issues prior to approving performance of a trusted role.
 
-Background checks include, but are not limited to, criminal background and employment history.
+Background checks include, without limitation, criminal background and employment history.
 
 ### 5.3.3 Training Requirements and Procedures
 
@@ -689,7 +690,7 @@ Training programs are developed for each role by ISRG management and Security Of
 
 ### 5.3.4 Retraining frequency and requirements
 
-Training is repeated for each Trusted Contributor on an annual basis and covers topics necessary to maintain skill level requirements.
+Training is repeated annually for each Trusted Contributor, and covers topics necessary to maintain skill level requirements.
 
 Training is also offered whenever changes in the industry or operations require it in order for contributors to competently perform in their trusted roles.
 
@@ -731,7 +732,7 @@ No stipulation.
 
 ### 5.4.3 Retention Period for Audit Logs
 
-Audit logs are retained for at least seven years and will be made available to compliance auditors upon request.
+Audit logs are retained for at least the period required by Section 5.4.3 of the ISRG CP.
 
 ### 5.4.4 Protection of Audit Log
 
@@ -769,11 +770,11 @@ ISRG Security Officers perform a risk assessment at least annually. This risk as
 
 ### 5.5.1 Types of records archived
 
-ISRG archives all audit logs, the contents of which are described in Section 5.4.1. ISRG may also archive any other information deemed critical to understanding the historical performance of the CA's duties.
+ISRG archives all audit logs, the contents of which are described in Section 5.4.1. ISRG also archives other documents and information critical to understanding the historical security and performance of the CA's duties.
 
 ### 5.5.2 Retention period for archive
 
-ISRG retains all documentation relating to certificate requests and the verification thereof, and all Certificates and revocation thereof, for at least seven years after any Certificate based on that documentation ceases to be valid.
+Archived records are retained for at least the period required by Section 5.5.2 of the ISRG CP.
 
 ### 5.5.3 Protection of archive
 
@@ -821,7 +822,7 @@ In the event that computing resources, software, and/or data are corrupted or ot
 
 ### 5.7.3 Recovery Procedures after Key Compromise
 
-In the event that an ISRG CA Private Key is compromised, or suspected to be compromised, ISRG will immediately launch a thorough investigation. Forensic evidence will be collected and secured as quickly as possible. If it cannot be determined with a high degree of certainty that the private key in question was not compromised, then the following steps may be taken in whatever order is deemed most appropriate by ISRG Security Officers:
+In the event that an ISRG CA Private Key is compromised, or suspected to be compromised, ISRG will immediately launch a thorough investigation. Forensic evidence will be collected and secured as quickly as possible. If it cannot be determined with a high degree of certainty that the private key in question was not compromised, then the following steps may be taken in whatever order ISRG Security Officers deem most appropriate:
 
 * Certificates relying on the private key in question will be revoked.
 * ISRG will notify root programs relying on the integrity of the key in question.
@@ -836,7 +837,7 @@ ISRG maintains multiple geographically diverse facilities, each of which is capa
 In the event that ISRG CA services are to be terminated:
 
 * All affected parties, including root programs and Subscribers, will be provided with notice as far in advance as reasonably possible.
-* A termination plan will be created and review by the ISRG PMA.
+* The ISRG PMA will create and review a termination plan.
 
 If a suitable successor entity exists, the following steps will be taken:
 
@@ -887,7 +888,7 @@ ISRG Subordinate CA ECDSA Private Keys are at least 384 bits in length.
 
 ISRG uses HSMs conforming to FIPS 186-4, capable of providing random number generation and on-board creation of at least 2048-bit RSA keys and at least 384-bit ECDSA keys.
 
-Per [NIST SP 800‐89](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-89.pdf), section 5.3.3, the CA ensures that:
+Per NIST SP 800‐89 (<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-89.pdf>), section 5.3.3, the CA ensures that:
 
   - the public exponent of any RSA key used in a DV-SSL Certificate is in the range between 2<sup>16</sup>+1 and 2<sup>256</sup>-1, and
   - the modulus of such a certificate is an odd number, not the power of a prime, and has no factors smaller than 752.
@@ -960,11 +961,11 @@ ISRG Root and Subordinate CA key pairs have lifetimes corresponding to their cer
 
 ### 6.4.1 Activation data generation and installation
 
-Activation data used to activate ISRG CA Private Keys is generated during a key ceremony. Activation data is then transferred to the person who will use it or place it will be stored.
+Activation data used to activate ISRG CA Private Keys is generated during a key ceremony. Activation data is then transferred to the person who will use it or the place it will be stored.
 
 ### 6.4.2 Activation data protection
 
-Activation data is protected from unauthorized disclosure via a combination of physical and logical means.
+Activation data is protected from unauthorized disclosure via both physical and logical means.
 
 ### 6.4.3 Other aspects of activation data
 
@@ -988,13 +989,13 @@ ISRG has developed policies and procedures to effectively manage the acquisition
 
 ISRG CA hardware and software is dedicated solely to performing CA functions.
 
-Vendor selection includes an evaluation of reputation in the market, ability to deliver a quality product, vulnerability history, and the likelihood of remaining viable in the future. Physical product deliveries are received by Trusted Contributors and inspected for evidence of tampering. HSMs are shipped in tamper-evident packaging and tamper bag serial numbers are confirmed with the vendor upon reception.
+Vendor selection includes an evaluation of reputation in the market, ability to deliver a quality product, vulnerability history, and the likelihood of remaining viable in the future. Physical product deliveries are received by Trusted Contributors and inspected for evidence of tampering. HSMs are shipped in tamper-evident packaging and tamper bag serial numbers are confirmed with the vendor upon receipt.
 
 ISRG maintains a CA testing environment separate from the production environment. The testing environment reasonably emulates the production environment but does not have access to ISRG CA Private Keys used in trusted certificates. The purpose of this testing environment is to allow extensive but safe testing of software and systems that are or will be deployed to the CA production environment.
 
 ISRG has developed and maintains appropriate change control policies and procedures to be followed any time CA systems are modified. Changes to ISRG CA systems require review by qualified Trusted Personnel who are different from the person requesting the change. Change requests are documented, as are any subsequent required reviews or approvals.
 
-When ISRG develops software to be used in CA operations, software development policies are put into place and methodologies are followed in order to ensure software quality and integrity. This always includes a requirement for peer review of code changes. Code commit privileges are granted only to qualified and trusted contributors. Nobody with the ability to deploy software to ISRG PKI systems (e.g. Systems Administrators) may have the ability to unilaterally commit code to core CA software. The reverse is also true.
+When ISRG develops software to be used in CA operations, software development policies are put into place and methodologies are followed in order to ensure software quality and integrity. This always includes a requirement for peer review of code changes. Code commit privileges are granted only to qualified and trusted contributors. Nobody with the ability to deploy software to ISRG PKI systems (e.g. PKI Administrators) may have the ability to unilaterally commit code to core CA software. The reverse is also true.
 
 ### 6.6.2 Security management controls
 
@@ -1057,7 +1058,7 @@ Extensions are not marked critical unless specifically described here as critica
 | ------------------------------ | ---------------------------------------------------------------------------------- |
 | Serial Number                  | Must be unique, with 64 bits of output from a CSPRNG                               |
 | Issuer Distinguished Name      | Derived from Issuer certificate                                                    |
-| Subject Distinguished Name     | CN=one of the values from the Subject Alternative Name extension                   |
+| Subject Distinguished Name     | CN=none, or one of the values from the Subject Alternative Name extension                   |
 | Validity Period                | Up to 100 days                                                                     |
 | Basic Constraints              | Critical.<br> cA=False                                                            |
 | Key Usage                      | Critical.<br> digitalSignature, keyEncipherment                                   |
@@ -1141,7 +1142,19 @@ For the status of Subordinate CA Certificates:
 | ThisUpdate                | The date and time when the Certificate revocation list validity begins         |
 | NextUpdate                | Up to ThisUpdate + 1 year                                                      |
 | RevokedCertificates       | Contains: userCertificate, revocationDate, reasonCode                          |
-| CRLnumber                 | The serial number of this CRL in an incrementally increasing sequence of CRLs. |
+| CRLnumber                 | The serial number of this CRL in an incrementally increasing sequence of CRLs  |
+
+For the status of Subscriber Certificates:
+
+| Field or Extension        | Value                                                                          |
+| ------------------------- | ------------------------------------------------------------------------------ |
+| Version                   | V2                                                                             |
+| Signature Algorithm       | sha256WithRSAEncryption or ecdsa-with-SHA384                                   |
+| ThisUpdate                | The date and time when the Certificate revocation list validity begins         |
+| NextUpdate                | Up to ThisUpdate + 10 days                                                     |
+| RevokedCertificates       | Contains: userCertificate, revocationDate, reasonCode                          |
+| CRLnumber                 | The serial number of this CRL in an incrementally increasing sequence of CRLs  |
+| IssuingDistributionPoint  | Contains a distributionPoint pointing to the CRL's unique URL                  |
 
 ### 7.2.1 Version number(s)
 
@@ -1289,7 +1302,7 @@ ISRG follows the privacy policy posted on its website (<https://letsencrypt.org/
 
 ### 9.4.6 Disclosure pursuant to judicial or administrative process
 
-ISRG may disclose personal information if compelled to do so by court order or other compulsory legal process, provided that ISRG will oppose such disclosure with all legal and technical tools reasonably available to ISRG.
+ISRG may disclose personal information if compelled to do so by court order or other compulsory legal process, provided that if ISRG determines that such court order or legal process is invalid or unconstitutional, ISRG will make reasonable legal efforts to oppose disclosure.
 
 ### 9.4.7 Other information disclosure circumstances
 
@@ -1373,7 +1386,7 @@ Each Subscriber will indemnify and hold harmless ISRG and its directors, officer
 
 ### 9.9.3 Indemnification by Relying Parties
 
-To the extent permitted by law, each Relying Party shall indemnify ISRG, its partners, and any cross-signed entities, and their respective directors, officers, employees, agents, and contractors against any loss, damage, or expense, including reasonable attorney's fees, related to the Relying Party's (i) breach of any service terms applicable to the services provided by ISRG or its affiliates and used by the Relying Party, this CPS, or applicable law; (ii) unreasonable reliance on a certificate; or (iii) failure to check the certificate's status prior to use.
+To the extent permitted by law, each Relying Party shall indemnify ISRG, its partners, entities that have cross-signed or issued sub-CAs for ISRG, and their respective directors, officers, employees, agents, and contractors against any loss, damage, or expense, including reasonable attorney's fees, related to the Relying Party's (i) breach of any service terms applicable to the services provided by ISRG or its affiliates and used by the Relying Party, this CPS, or applicable law; (ii) unreasonable reliance on a certificate; or (iii) failure to check the certificate's status prior to use.
 
 ## 9.10 Term and termination
 
@@ -1387,7 +1400,7 @@ This CPS and any amendments remain in effect until replaced with a newer version
 
 ### 9.10.3 Effect of termination and survival
 
-ISRG will communicate the conditions and effect of this CPS's termination via the ISRG Repository. The communication will specify which provisions survive termination. At a minimum, all responsibilities related to protecting confidential information will survive termination. All Subscriber Agreements remain effective until the certificate is revoked or expired, even if this CPS terminates.
+ISRG will communicate the conditions and effect of this CPS's termination via the ISRG Repository. The communication will specify which provisions survive termination. At a minimum, all responsibilities related to protecting confidential information will survive termination. All Subscriber Agreements remain effective at least until the certificate is revoked or expired, even if this CPS terminates.
 
 ## 9.11 Individual notices and communications with participants
 

patches/README.md

@@ -1,11 +0,0 @@
-To generate a new ISRG CP from a patch, follow these instructions:
-
-1. Apply a patch in this directory against a markdown copy of the BRs. Current BR markdown can be found here, for example:
-
-<https://github.com/cabforum/servercert/blob/main/docs/BR.md>
-
-2. Run the no-stipulation tool against the patched BRs to add required text to empty leaf sections:
-
-<https://github.com/letsencrypt/cp-cps/blob/master/tools/no-stipulations/no_stipulation.py>
-
-3. Review the updated CP to make sure the changes are correct and appropriate. Make sure to look for added language that is self-referential to the BRs, such as "these Baseline Requirements." That would need to be changed, whereas something like "these Requirements" is fine because "Requirements" has been re-defined to refer to our CP.

patches/isrg-cp-from-brs.patch

@@ -1,279 +0,0 @@
-diff --git a/docs/BR.md b/docs/BR.md
-index 5823995..280f22d 100644
---- a/docs/BR.md
-+++ b/docs/BR.md
-@@ -1,128 +1,51 @@
-----
--title: Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates
--subtitle: Version 1.7.8
--author:
--  - CA/Browser Forum
--date: 13 July, 2021  
--copyright: |
--  Copyright 2021 CA/Browser Forum
--
--  This work is licensed under the Creative Commons Attribution 4.0 International license.
-----
--
- # 1. INTRODUCTION
- 
- ## 1.1 Overview
- 
--This document describes an integrated set of technologies, protocols, identity-proofing, lifecycle management, and auditing requirements that are necessary (but not sufficient) for the issuance and management of Publicly-Trusted Certificates; Certificates that are trusted by virtue of the fact that their corresponding Root Certificate is distributed in widely-available application software. The requirements are not mandatory for Certification Authorities unless and until they become adopted and enforced by relying-party Application Software Suppliers.
--
--**Notice to Readers**
-+This Certificate Policy ("CP") document outlines the certificate policies for Internet Security Research Group ("ISRG") Public Key Infrastructure ("ISRG PKI").
- 
--The CP for the Issuance and Management of Publicly-Trusted Certificates describe a subset of the requirements that a Certification Authority must meet in order to issue Publicly Trusted Certificates. This document serves two purposes: to specify Baseline Requirements and to provide guidance and requirements for what a CA should include in its CPS. Except where explicitly stated otherwise, these Requirements apply only to relevant events that occur on or after 1 July 2012 (the original effective date of these requirements).
-+ISRG PKI services include, but are not limited to, issuing, managing, validating, revoking, and renewing Certificates. ISRG PKI is operated in accordance with the requirements of this CP, and in a manner consistent with the ISRG Certification Practice Statement ("CPS").
- 
--These Requirements do not address all of the issues relevant to the issuance and management of Publicly-Trusted Certificates. In accordance with RFC 3647 and to facilitate a comparison of other certificate policies and CPSs (e.g. for policy mapping), this document includes all sections of the RFC 3647 framework. However, rather than beginning with a "no stipulation" comment in all empty sections, the CA/Browser Forum is leaving such sections initially blank until a decision of "no stipulation" is made. The CA/Browser Forum may update these Requirements from time to time, in order to address both existing and emerging threats to online security. In particular, it is expected that a future version will contain more formal and comprehensive audit requirements for delegated functions.
-+ISRG PKI services are provided to the general public with exceptions as deemed appropriate by ISRG management or in accordance with relevant law.
- 
--These Requirements only address Certificates intended to be used for authenticating servers accessible through the Internet. Similar requirements for code signing, S/MIME, time-stamping, VoIP, IM, Web services, etc. may be covered in future versions.
-+ISRG PKI services are most commonly, but not necessarily exclusively, provided under the brand/trademark "Let's Encrypt".
- 
--These Requirements do not address the issuance, or management of Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, and for which the Root Certificate is not distributed by any Application Software Supplier.
-+The ISRG PKI conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at <http://www.cabforum.org>. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.
- 
--These Requirements are applicable to all Certification Authorities within a chain of trust. They are to be flowed down from the Root Certification Authority through successive Subordinate Certification Authorities.
-+Other documents related to the behavior and control of the ISRG PKI, such as a Subscriber Agreement and Privacy Policy, can be found at <https://letsencrypt.org/repository/>.
- 
--## 1.2 Document name and identification
-+Per IETF PKIX RFC 3647, this CP is divided into nine components that cover security controls, practices, and procedures for certification services provided by the ISRG PKI.
- 
--This certificate policy (CP) contains the requirements for the issuance and management of publicly-trusted SSL certificates, as adopted by the CA/Browser Forum.
-+The following Certification Authorities are covered under this CP:
- 
--The following Certificate Policy identifiers are reserved for use by CAs as an optional means of asserting compliance with this document (OID arc 2.23.140.1.2) as follows:
-+| CA Type | Distinguished Name | Key Pair Type and Parameters | Cert SHA-256 Fingerprint | Validity Period |
-+|---------|--------------------|------------------------------|--------------------------|-----------------|
-+| Root CA | C=US,<br>O=Internet Security Research Group,<br>CN=ISRG Root X1 | RSA, n has 4096 bits, e=65537 | 96:BC:EC:06:26:49:76:F3:<br>74:60:77:9A:CF:28:C5:A7:<br>CF:E8:A3:C0:AA:E1:1A:8F:<br>FC:EE:05:C0:BD:DF:08:C6 | Not Before: Jun  4 11:04:38 2015 GMT,<br>Not After: Jun  4 11:04:38 2035 GMT |
-+| Root CA | C=US,<br>O=Internet Security Research Group,<br>CN=ISRG Root X2 | ECDSA, NIST curve P-384 | 69:72:9b:8e:15:a8:6e:fc:<br>17:7a:57:af:b7:17:1d:fc:<br>64:ad:d2:8c:2f:ca:8c:f1:<br>50:7e:34:45:3c:cb:14:70 | Not Before: Sept  4 00:00:00 2020 GMT,<br>Not After: Sept 17 16:00:00 2040 GMT |
- 
--`{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) domain-validated(1)} (2.23.140.1.2.1);` and
-+This work is licensed under the Creative Commons Attribution 4.0 International License ("CC BY 4.0"). This work is derivative of "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" by the CA/Browser Forum, used under CC BY 4.0. To view a copy of this license, visit <https://creativecommons.org/licenses/by/4.0/> or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
- 
--`{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) organization-validated(2)} (2.23.140.1.2.2);` and
-+## 1.2 Document name and identification
- 
--`{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) individual-validated(3)} (2.23.140.1.2.3)`.
-+This is the ISRG Certificate Policy. This document was approved for publication by the ISRG Policy Management Authority, and is made available at <https://letsencrypt.org/repository/>.
- 
- ### 1.2.1 Revisions
- 
--| **Ver.** | **Ballot** | **Description** | **Adopted** | **Effective\*** |
--|-|-|-----|--|--|
--| 1.0.0 | 62 | Version 1.0 of the Baseline Requirements Adopted | 22-Nov-11 | 01-Jul-12 |
--| 1.0.1 | 71 | Revised Auditor Qualifications | 08-May-12 | 01-Jan-13 |
--| 1.0.2 | 75 | Non-critical Name Constraints allowed as exception to RFC 5280 | 08-Jun-12 | 08-Jun-12 |
--| 1.0.3 | 78 | Revised Domain/IP Address Validation, High Risk Requests, and Data Sources | 22-Jun-12 | 22-Jun-12 |
--| 1.0.4 | 80 | OCSP responses for non-issued certificates | 02-Aug-12 | 01-Feb-13 01-Aug-13 |
--| -- | 83 | Network and Certificate System Security Requirements adopted | 03-Aug-13 | 01-Jan-13 |
--| 1.0.5 | 88 | User-assigned country code of XX allowed | 12-Sep-12 | 12-Sep-12 |
--| 1.1.0 | -- | Published as Version 1.1 with no changes from 1.0.5 | 14-Sep-12 | 14-Sep-12 |
--| 1.1.1 | 93 | Reasons for Revocation and Public Key Parameter checking | 07-Nov-12 | 07-Nov-12 01-Jan-13 |
--| 1.1.2 | 96 | Wildcard certificates and new gTLDs | 20-Feb-13 | 20-Feb-13 01-Sep-13 |
--| 1.1.3 | 97 | Prevention of Unknown Certificate Contents | 21-Feb-13 | 21-Feb-13 |
--| 1.1.4 | 99 | Add DSA Keys (BR v.1.1.4) | 3-May-2013 | 3-May-2013 |
--| 1.1.5 | 102 | Revision to subject domainComponent language in Section 9.2.3 | 31-May-2013 | 31-May-2013 |
--| 1.1.6 | 105 | Technical Constraints for Subordinate Certificate Authorities | 29-July-2013 | 29-July-2013 |
--| 1.1.7 | 112 | Replace Definition of "Internal Server Name" with "Internal Name" | 3-April-2014 | 3-April-2014 |
--| 1.1.8 | 120 | Affiliate Authority to Verify Domain | 5-June-2014 | 5-June-2014 |
--| 1.1.9 | 129 | Clarification of PSL mentioned in Section 11.1.3 | 4-Aug-2014 | 4-Aug-2014 |
--| 1.2.0 | 125 | CAA Records | 14-Oct-2014 | 15-Apr-2015 |
--| 1.2.1 | 118 | SHA-1 Sunset | 16-Oct-2014 | 16-Jan-2015 1-Jan-2016 1-Jan-2017 |
--| 1.2.2 | 134 | Application of RFC 5280 to Pre-certificates | 16-Oct-2014 | 16-Oct-2014 |
--| 1.2.3 | 135 | ETSI Auditor Qualifications | 16-Oct-2014 | 16-Oct-2014 |
--| 1.2.4 | 144 | Validation Rules for .onion Names | 18-Feb-2015 | 18-Feb-2015 |
--| 1.2.5 | 148 | Issuer Field Correction | 2-April-2015 | 2-April-2015 |
--| 1.3.0 | 146 | Convert Baseline Requirements to RFC 3647 Framework | 16-Apr-2015 | 16-Apr-2015 |
--| 1.3.1 | 151 | Addition of Optional OIDs for Indicating Level of Validation | 28-Sep-2015 | 28-Sep-2015 |
--| 1.3.2 | 156 | Amend Sections 1 and 2 of Baseline Requirements | 3-Dec-2015 | 3-Dec-2016 |
--| 1.3.3 | 160 | Amend Section 4 of Baseline Requirements | 4-Feb-2016 | 4-Feb-2016 |
--| 1.3.4 | 162 | Sunset of Exceptions | 15-Mar-2016 | 15-Mar-2016 |
--| 1.3.5 | 168 | Baseline Requirements Corrections (Revised) | 10-May-2016 | 10-May-2016 |
--| 1.3.6 | 171 | Updating ETSI Standards in CABF documents | 1-July-2016 | 1-July-2016 |
--| 1.3.7 | 164 | Certificate Serial Number Entropy | 8-July-2016 | 30-Sep-2016 |
--| 1.3.8 | 169 | Revised Validation Requirements | 5-Aug-2016 | 1-Mar-2017 |
--| 1.3.9 | 174 | Reform of Requirements Relating to Conflicts with Local Law | 29-Aug-2016 | 27-Nov-2016 |
--| 1.4.0 | 173 | Removal of requirement to cease use of public key due to incorrect info | 28-July-2016 | 11-Sept-2016 |
--| 1.4.1 | 175 | Addition of givenName and surname | 7-Sept-2016 | 7-Sept-2016 |
--| 1.4.2 | 181 | Removal of some validation methods listed in Section 3.2.2.4 | 7-Jan-2017 | 7-Jan-2017 |
--| 1.4.3 | 187 | Make CAA Checking Mandatory | 8-Mar-2017 | 8-Sep-2017 |
--| 1.4.4 | 193 | 825-day Certificate Lifetimes | 17-Mar-2017 | 1-Mar-2018 |
--| 1.4.5 | 189 | Amend Section 6.1.7 of Baseline Requirements | 14-Apr-2017 | 14-May-2017 |
--| 1.4.6 | 195 | CAA Fixup | 17-Apr-2017 | 18-May-2017 |
--| 1.4.7 | 196 | Define “Audit Period” | 17-Apr-2017 | 18-May-2017 |
--| 1.4.8 | 199 | Require commonName in Root and Intermediate Certificates | 9-May-2017 | 8-June-2017 |
--| 1.4.9 | 204 | Forbid DTPs from doing Domain/IP Ownership | 11-July-2017 | 11-Aug-2017 |
--| 1.5.0 | 212 | Canonicalise formal name of the Baseline Requirements | 1-Sept-2017 | 1-Oct-2017 |
--| 1.5.1 | 197 | Effective Date of Ballot 193 Provisions | 1-May-2017 | 2-June-2017 |
--| 1.5.2 | 190 | Add Validation Methods with Minor Corrections | 19-Sept-2017 | 19-Oct-2017 |
--| 1.5.3 | 214 | CAA Discovery CNAME Errata | 27-Sept-2017 | 27-Oct-2017 |
--| 1.5.4 | 215 | Fix Ballot 190 Errata | 4‐Oct‐2017 | 5‐Nov‐2017 |
--| 1.5.5 | 217 | Sunset RFC 2527 | 21‐Dec‐2017 | 9‐Mar‐2018 |
--| 1.5.6 | 218 | Remove validation methods #1 and #5 | 5‐Feb‐2018 | 9‐Mar‐2018 |
--| 1.5.7 | 220 | Minor Cleanups (Spring 2018) | 30‐Mar‐2018 | 29‐Apr‐2018 |
--| 1.5.8 | 219 | Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag | 10-Apr-2018 | 10-May-2018 |
--| 1.5.9 | 223 | Update BR Section 8.4 for CA audit criteria | 15-May-2018 | 14-June-2018 |
--| 1.6.0 | 224 | WhoIs and RDAP | 22-May-2018 | 22-June-2018 |
--| 1.6.1 | SC6 | Revocation Timeline Extension | 14-Sep-2018 | 14-Oct-2018 |
--| 1.6.2 | SC12 | Sunset of Underscores in dNSNames | 9-Nov-2018 | 10-Dec-2018 |
--| 1.6.3 | SC13 | CAA Contact Property and Associated E-mail Validation Methods | 25-Dec-2018 | 1-Feb-2019 |
--| 1.6.4 | SC14 | Updated Phone Validation Methods | 31-Jan-2019 | 16-Mar-2019 |
--| 1.6.4 | SC15 | Remove Validation Method Number 9 | 5-Feb-2019 | 16-Mar-2019 |
--| 1.6.4 | SC7 | Update IP Address Validation Methods | 8-Feb-2019 | 16-Mar-2019 |
--| 1.6.5 | SC16 | Other Subject Attributes | 15-Mar-2019 | 16-Apr-2019 |
--| 1.6.6 | SC19 | Phone Contact with DNS CAA Phone Contact v2 | 20-May-2019 | 9-Sep-2019 |
--| 1.6.7 | SC23 | Precertificates | 14-Nov-2019 | 19-Dec-2019 |
--| 1.6.7 | SC24 | Fall Cleanup v2 | 12-Nov-2019 | 19-Dec-2019 |
--| 1.6.8 | SC25 | Define New HTTP Domain Validation Methods v2 | 31-Jan-2020 | 3-Mar-2020 |
--| 1.6.9 | SC27 | Version 3 Onion Certificates | 19-Feb-2020 | 27-Mar-2020 |
--| 1.7.0 | SC29 | Pandoc-Friendly Markdown Formatting Changes | 20-Mar-2020 | 4-May-2020 |
--| 1.7.1 | SC30 | Disclosure of Registration / Incorporating Agency | 13-Jul-2020 | 20-Aug-2020 |
--| 1.7.1 | SC31 | Browser Alignment | 16-Jul-2020 | 20-Aug-2020 |
--| 1.7.2 | SC33 | TLS Using ALPN Method | 14-Aug-2020 | 22-Sept-2020 |
--| 1.7.3 | SC28 | Logging and Log Retention | 10-Sep-2020 | 19-Oct-2020 |
--| 1.7.3 | SC35 | Cleanups and Clarifications | 9-Sep-2020 | 19-Oct-2020 |
--| 1.7.4 | SC41 | Reformat the BRs, EVGs, and NCSSRs | 24-Feb-2021 | 5-Apr-2021 |
--| 1.7.5 | SC42 | 398-day Re-use Period | 22-Apr-2021 | 2-Jun-2021 |
--| 1.7.6 | SC44 | Clarify Acceptable Status Codes | 30-Apr-2021 | 3-Jun-2021 |
--| 1.7.7 | SC46 | Sunset the CAA Exception for DNS Operator | 2-Jun-2021 | 12-Jul-2021 |
--| 1.7.8 | SC45 | Wildcard Domain Validation | 2-Jun-2021 | 13-Jul-2021 |
--
--\* Effective Date and Additionally Relevant Compliance Date(s)
-+| Date              | Changes                                            | Version |
-+|-------------------|----------------------------------------------------|---------|
-+| May 5, 2015 | Original | 1.0 |
-+| September 9, 2015 | Added DV SSL OID, added/corrected a number of policy URIs, clarifications to Procedure for Revocation Request, substantial changes to all of Section 9 regarding legal matters, other minor fixes/improvements | 1.1 |
-+| May 5, 2016 | Add info about tlsFeature extension, serialNumber in Subject Distinguished Name field. | 1.2 |
-+| April 13, 2017 | Simplify Section 1.2, "Document Name and Identification. Simplify Section 3.2.2.2, "Performance of Electronic Identification." Validation methods in use are detailed in CPS. Update CPS section numbers for CRL and OCSP profiles. Remove Section 10, "Certificate Profiles." Profiles are now in our CPS. | 1.3 |
-+| May 22, 2017 | Complete rewrite. | 2.0 |
-+| February 6, 2018 | Update text of Section 6.1.7 to match Baseline Requirements v1.5.1. | 2.1 |
-+| September 20, 2018 | Define Certificate Problem Report in Section 1.6.1. Update Section 3.2.2.4 "Validation of Domain Authorization or Control" to match latest BRs but omit methods we do not use. Add additional revocation reason to Section 4.9.1.1 for compliance with upcoming BR revision. Minor updates to Sections 4.9.3 and 4.9.5. | 2.2 |
-+| July 3, 2019 | Remove IP address validation information which is not applicable. Update sections 4.9.1.1, 4.9.1.2, and 4.9.5 to match current BRs. Other minor updates (e.g. capitalization). | 2.3 |
-+| January 21, 2020 | Make structure more exactly match RFC 3647 recommendation. Audit use of phrase No Stipulation and eliminate blank sections. Add policy information for IP address validation. | 2.4 |
-+| October 27, 2020 | List ISRG Root X2 in section 1.1. Update sections 3.2.2.4, 3.2.2.5, 3.2.2.6, 3.2.2.8, 4.2.1, 4.9.10, 7.1.2, and 7.1.3 regarding validation methods, OCSP, certificate profiles, and cryptographic algorithms, to match Baseline Requirements. | 2.5 |
-+| April 2, 2021 | Update ISRG physical address. | 2.6 |
-+| June 8, 2021 | Update Sections 4.2.1, 4.2.2, 4.9.1.1, 6.3.2, and 7.1.4.2.1 to match BRs v1.7.6. Define Internal Name in Section 1.6.1. | 2.7 |
-+| DD Month, YYYY | Sync against Baseline Requirements v1.7.8. | 2.8 |
- 
- ### 1.2.2 Relevant Dates
- 
-@@ -172,7 +95,7 @@ The CA/Browser Forum is a voluntary organization of Certification Authorities an
- 
- ### 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>.
-+Certification Authority (CA) is defined in [Section 1.6](#16-definitions-and-acronyms).
- 
- ### 1.3.2 Registration Authorities
- 
-@@ -202,13 +125,10 @@ As defined in [Section 1.6.1](#161-definitions).
- 
- ### 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>.
-+"Relying Party" and "Application Software Supplier" are defined in [Section 1.6.1](#161-definitions).
- 
- ### 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.1 Appropriate Certificate Uses
-@@ -221,23 +141,31 @@ No stipulation.
- 
- ## 1.5 Policy administration
- 
--The Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates present criteria established by the CA/Browser Forum for use by Certification Authorities when issuing, maintaining, and revoking publicly-trusted 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 <questions@cabforum.org>. The Forum members value all input, regardless of source, and will seriously consider all such input.
--
- ### 1.5.1 Organization Administering the Document
- 
--No stipulation.
-+This CP document is maintained by the ISRG Policy Management Authority.
- 
- ### 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.
-+The ISRG PMA can be contacted at:
-+
-+Policy Management Authority<br>
-+Internet Security Research Group<br>
-+P.O. Box 18666<br>
-+Minneapolis, MN 55418-0666<br>
-+USA<br>
-+
-+Issues can be filed via the GitHub repository where this document is maintained:
-+
-+<https://github.com/letsencrypt/cp-cps>
- 
- ### 1.5.3 Person Determining CPS suitability for the policy
- 
--No stipulation.
-+The ISRG Policy Management Authority is responsible for determining the suitability of this CP. ISRG policy is informed by results and recommendations received from an independent auditor.
- 
- ### 1.5.4 CPS approval procedures
- 
--No stipulation.
-+The ISRG Policy Management Authority approves any revisions to this CP document after formal review.
- 
- ## 1.6 Definitions and Acronyms
- 
-@@ -414,7 +342,7 @@ The script outputs:
- 
- **Required Website Content**: Either a Random Value or a Request Token, together with additional information that uniquely identifies the Subscriber, as specified by the CA.
- 
--**Requirements**: The Baseline Requirements found in this document.
-+**Requirements**: Policy requirements outlined in this document.
- 
- **Reserved IP Address**: An IPv4 or IPv6 address that the IANA has marked as reserved:
- 
-@@ -444,8 +372,6 @@ The script outputs:
- 
- **Terms of Use**: Provisions regarding the safekeeping and acceptable uses of a Certificate issued in accordance with these Requirements when the Applicant/Subscriber is an Affiliate of the CA or is the CA.
- 
--**Test Certificate**: This term is no longer used in these Baseline Requirements.
--
- **Trustworthy System**: Computer hardware, software, and procedures that are: reasonably secure from intrusion and misuse; provide a reasonable level of availability, reliability, and correct operation; are reasonably suited to performing their intended functions; and enforce the applicable security policy.
- 
- **Unregistered Domain Name**: A Domain Name that is not a Registered Domain Name.
-@@ -967,7 +893,7 @@ This stipulation does not prevent the CA from checking CAA records at any other
- 
- When processing CAA records, CAs MUST process the issue, issuewild, and iodef property tags as specified in RFC 8659, although they are not required to act on the contents of the iodef property tag. Additional property tags MAY be supported, but MUST NOT conflict with or supersede the mandatory property tags set out in this document. CAs MUST respect the critical flag and not issue a certificate if they encounter an unrecognized property tag with this flag set.
- 
--RFC 8659 requires that CAs "MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA RRset or (2) an exception specified in the relevant CP or CPS applies." For issuances conforming to these Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following:
-+RFC 8659 requires that CAs "MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA RRset or (2) an exception specified in the relevant CP or CPS applies." For issuances conforming to these Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following:
- 
- * CAA checking is optional for certificates for which a Certificate Transparency pre-certificate was created and logged in at least two public logs, and for which CAA was checked.
- * CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in [Section 7.1.5](#715-name-constraints), where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant.
-@@ -1902,7 +1828,7 @@ b. semantics that, if included, will mislead a Relying Party about the certifica
- 
- #### 7.1.2.5 Application of RFC 5280
- 
--For purposes of clarification, a Precertificate, as described in RFC 6962 - Certificate Transparency, shall not be considered to be a "certificate" subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements.
-+For purposes of clarification, a Precertificate, as described in RFC 6962 - Certificate Transparency, shall not be considered to be a "certificate" subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Requirements.
- 
- ### 7.1.3 Algorithm object identifiers
- 
-@@ -2274,7 +2200,7 @@ The CA SHALL at all times:
- 3. Comply with the audit requirements set forth in this section; and
- 4. Be licensed as a CA in each jurisdiction where it operates, if licensing is required by the law of such jurisdiction for the issuance of Certificates.
- 
--**Implementers' Note**: Version 1.1.6 of the SSL Baseline Requirements was published on July 29, 2013. Version 2.0 of WebTrust's Principles and Criteria for Certification Authorities - SSL Baseline with Network Security and ETSI's Electronic Signatures and Infrastructures (ESI) 102 042 incorporate version 1.1.6 of these Baseline Requirements and version 1.0 of the Network and Certificate System Security Requirements. The CA/Browser Forum continues to improve the Baseline Requirements while WebTrust and ETSI also continue to update their audit criteria. We encourage all CAs to conform to each revision herein on the date specified without awaiting a corresponding update to an applicable audit criterion. In the event of a conflict between an existing audit criterion and a guideline revision, we will communicate with the audit community and attempt to resolve any uncertainty, and we will respond to implementation questions directed to <questions@cabforum.org>. Our coordination with compliance auditors will continue as we develop guideline revision cycles that harmonize with the revision cycles for audit criteria, the compliance auditing periods and cycles of CAs, and the CA/Browser Forum's guideline implementation dates.
-+**Implementers' Note**: Version 1.1.6 of the SSL Baseline Requirements was published on July 29, 2013. Version 2.0 of WebTrust's Principles and Criteria for Certification Authorities - SSL Baseline with Network Security and ETSI's Electronic Signatures and Infrastructures (ESI) 102 042 incorporate version 1.1.6 of these Requirements and version 1.0 of the Network and Certificate System Security Requirements. The CA/Browser Forum continues to improve the Baseline Requirements while WebTrust and ETSI also continue to update their audit criteria. We encourage all CAs to conform to each revision herein on the date specified without awaiting a corresponding update to an applicable audit criterion. In the event of a conflict between an existing audit criterion and a guideline revision, we will communicate with the audit community and attempt to resolve any uncertainty, and we will respond to implementation questions directed to <questions@cabforum.org>. Our coordination with compliance auditors will continue as we develop guideline revision cycles that harmonize with the revision cycles for audit criteria, the compliance auditing periods and cycles of CAs, and the CA/Browser Forum's guideline implementation dates.
- 
- ## 8.1 Frequency or circumstances of assessment
- 
-@@ -2468,7 +2394,7 @@ The Subscriber Agreement or Terms of Use MUST contain provisions imposing on the
- 
- 6. **Termination of Use of Certificate**: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise.
- 7. **Responsiveness**: An obligation to respond to the CA's instructions concerning Key Compromise or Certificate misuse within a specified time period.
--8. **Acknowledgment and Acceptance**: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or Terms of Use or if revocation is required by the CA's CP, CPS, or these Baseline Requirements.
-+8. **Acknowledgment and Acceptance**: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or Terms of Use or if revocation is required by the CA's CP or CPS.
- 
- ### 9.6.4 Relying party representations and warranties
- 

tools/lint/README.md

@@ -0,0 +1,61 @@
+# CP/CPS Linter
+
+This tool performs a variety of simple checks on the CP/CPS to ensure that it
+is in compliance with the Baseline Requirements. It is superficial: a clean
+lint check is a necessary but not sufficient condition for full compliance.
+
+Usage:
+
+```sh
+$ go run . /path/to/cps.md
+heading "### 3.1.3 Anonymity or pseudonymity of subscribers" found out-of-order on line 199
+heading "### 4.4.2 Publication of the certificate by the CA" not found
+empty section found at line 71
+empty section found at line 272
+exit status 1
+```
+
+This tool is used by GitHub Actions to check every PR against this repo.
+
+## Checks
+
+The linter looks for compliance with Ballot SC-074, which added the following
+text to the Baseline Requirements, Section 2.2:
+
+> the Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with section 6 of RFC 3647 and MUST:
+>
+> * include at least every section and subsection defined in section 6 of RFC 3647;
+> * only use the words "No Stipulation" to mean that the particular document imposes no requirements related to that section; and
+> * contain no sections that are blank and have no subsections.
+
+### RFC 3647 Outline
+
+A significant portion of this linter's work is confirming that the structure of
+the CP/CPS matches the outline laid out in [RFC 3647, Section
+6](https://datatracker.ietf.org/doc/html/rfc3647#section-6). This outline is
+reproduced in [outline.txt](outline.txt), which was produced using the following
+procedure:
+
+1. Copy-paste the whole of Section 6 into a plaintext document.
+2. Remove the leading text, and the page headers and footers.
+3. Unwrap all section titles which were broken onto multiple lines.
+4. Replace all sequences of more than one space (`  `) with a single space.
+5. Remove the `(11)` footnote indicator which follows some entries.
+6. Prepend each line with a number of `#` equal to its section depth.
+
+The lint tool then ensures that every line in this file appears in the CP/CPS,
+exactly as written, in order.
+
+### No Empty Sections
+
+The linter also looks for any places where two section header lines separated
+only by whitespace have the same or decreasing section depth (e.g. "1.2.3"
+followed by "1.3"), indicating that the first of the two sections has no
+content.
+
+### Use of "No Stipulation"
+
+This linter does **not** check whether the phrase "No Stipulation" has been used
+to mean anything other than that "that the particular document imposes no
+requirements related to that section", since doing so is a semantic (not
+syntactic) matter.

tools/lint/go.mod

@@ -0,0 +1,3 @@
+module github.com/letsencrypt/cp-cps/tools/lint
+
+go 1.22.2

tools/lint/main.go

@@ -0,0 +1,115 @@
+package main
+
+import (
+	"bufio"
+	_ "embed"
+	"fmt"
+	"os"
+	"slices"
+	"strings"
+)
+
+//go:embed outline.txt
+var outline string
+
+func main() {
+	if len(os.Args) < 2 {
+		fmt.Fprintln(os.Stderr, "must provide path to document to check")
+		os.Exit(1)
+	}
+
+	file, err := os.Open(os.Args[1])
+	if err != nil {
+		fmt.Fprintln(os.Stderr, "opening document:", err)
+		os.Exit(1)
+	}
+	defer file.Close()
+	scanner := bufio.NewScanner(file)
+
+	var lines []string
+	for scanner.Scan() {
+		lines = append(lines, scanner.Text())
+	}
+	if err := scanner.Err(); err != nil {
+		fmt.Fprintln(os.Stderr, "reading document:", err)
+		os.Exit(1)
+	}
+
+	anyErr := false
+
+	errs := make(chan error)
+	go func() {
+		lintHeadings(lines, errs)
+		close(errs)
+	}()
+	for err = range errs {
+		anyErr = true
+		fmt.Fprintln(os.Stderr, err)
+	}
+
+	errs = make(chan error)
+	go func() {
+		lintEmptySections(lines, errs)
+		close(errs)
+	}()
+	for err = range errs {
+		anyErr = true
+		fmt.Fprintln(os.Stderr, err)
+	}
+
+	if anyErr {
+		os.Exit(1)
+	}
+
+	fmt.Println("lint checks complete; no findings")
+}
+
+// lintHeadings tries to locate every heading that we expect to exist, and
+// checks that they appear in the correct order.
+func lintHeadings(lines []string, errs chan<- error) {
+	outline = strings.TrimSpace(outline)
+	headings := strings.Split(outline, "\n")
+	headingLines := make([]int, len(headings))
+
+	for i, heading := range headings {
+		headingLines[i] = slices.Index(lines, heading)
+	}
+
+	for i, lineNo := range headingLines {
+		if lineNo == -1 {
+			errs <- fmt.Errorf("heading %q not found", headings[i])
+			continue
+		}
+
+		if i > 0 && lineNo <= headingLines[i-1] {
+			errs <- fmt.Errorf("heading %q found out-of-order on line %d", headings[i], lineNo)
+			continue
+		}
+	}
+}
+
+// lintEmptySections looks for places where two section headings occur with
+// nothing other than empty lines between them, and the second section is of
+// equal or lesser depth (being of greater depth is fine, that's a subsection).
+func lintEmptySections(lines []string, errs chan<- error) {
+	lastHeadingDepth := 0
+	sectionBodySeen := false
+	for i, line := range lines {
+		if line == "" {
+			continue
+		}
+
+		if strings.HasPrefix(line, "#") {
+			currHeadingDepth := len(line) - len(strings.TrimLeft(line, "#"))
+			if currHeadingDepth <= lastHeadingDepth && !sectionBodySeen {
+				errs <- fmt.Errorf("empty section found at line %d", i)
+			}
+
+			lastHeadingDepth = currHeadingDepth
+			sectionBodySeen = false
+			continue
+		}
+
+		sectionBodySeen = true
+	}
+}

tools/lint/outline.txt

@@ -0,0 +1,270 @@
+# 1. INTRODUCTION
+## 1.1 Overview
+## 1.2 Document name and identification
+## 1.3 PKI participants
+### 1.3.1 Certification authorities
+### 1.3.2 Registration authorities
+### 1.3.3 Subscribers
+### 1.3.4 Relying parties
+### 1.3.5 Other participants
+## 1.4 Certificate usage
+### 1.4.1 Appropriate certificate uses
+### 1.4.2 Prohibited certificate uses
+## 1.5 Policy administration
+### 1.5.1 Organization administering the document
+### 1.5.2 Contact person
+### 1.5.3 Person determining CPS suitability for the policy
+### 1.5.4 CPS approval procedures
+## 1.6 Definitions and acronyms
+# 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
+## 2.1 Repositories
+## 2.2 Publication of certification information
+## 2.3 Time or frequency of publication
+## 2.4 Access controls on repositories
+# 3. IDENTIFICATION AND AUTHENTICATION
+## 3.1 Naming
+### 3.1.1 Types of names
+### 3.1.2 Need for names to be meaningful
+### 3.1.3 Anonymity or pseudonymity of subscribers
+### 3.1.4 Rules for interpreting various name forms
+### 3.1.5 Uniqueness of names
+### 3.1.6 Recognition, authentication, and role of trademarks
+## 3.2 Initial identity validation
+### 3.2.1 Method to prove possession of private key
+### 3.2.2 Authentication of organization identity
+### 3.2.3 Authentication of individual identity
+### 3.2.4 Non-verified subscriber information
+### 3.2.5 Validation of authority
+### 3.2.6 Criteria for interoperation
+## 3.3 Identification and authentication for re-key requests
+### 3.3.1 Identification and authentication for routine re-key
+### 3.3.2 Identification and authentication for re-key after revocation
+## 3.4 Identification and authentication for revocation request
+# 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
+## 4.1 Certificate Application
+### 4.1.1 Who can submit a certificate application
+### 4.1.2 Enrollment process and responsibilities
+## 4.2 Certificate application processing
+### 4.2.1 Performing identification and authentication functions
+### 4.2.2 Approval or rejection of certificate applications
+### 4.2.3 Time to process certificate applications
+## 4.3 Certificate issuance
+### 4.3.1 CA actions during certificate issuance
+### 4.3.2 Notification to subscriber by the CA of issuance of certificate
+## 4.4 Certificate acceptance
+### 4.4.1 Conduct constituting certificate acceptance
+### 4.4.2 Publication of the certificate by the CA
+### 4.4.3 Notification of certificate issuance by the CA to other entities
+## 4.5 Key pair and certificate usage
+### 4.5.1 Subscriber private key and certificate usage
+### 4.5.2 Relying party public key and certificate usage
+## 4.6 Certificate renewal
+### 4.6.1 Circumstance for certificate renewal
+### 4.6.2 Who may request renewal
+### 4.6.3 Processing certificate renewal requests
+### 4.6.4 Notification of new certificate issuance to subscriber
+### 4.6.5 Conduct constituting acceptance of a renewal certificate
+### 4.6.6 Publication of the renewal certificate by the CA
+### 4.6.7 Notification of certificate issuance by the CA to other entities
+## 4.7 Certificate re-key
+### 4.7.1 Circumstance for certificate re-key
+### 4.7.2 Who may request certification of a new public key
+### 4.7.3 Processing certificate re-keying requests
+### 4.7.4 Notification of new certificate issuance to subscriber
+### 4.7.5 Conduct constituting acceptance of a re-keyed certificate
+### 4.7.6 Publication of the re-keyed certificate by the CA
+### 4.7.7 Notification of certificate issuance by the CA to other entities
+## 4.8 Certificate modification
+### 4.8.1 Circumstance for certificate modification
+### 4.8.2 Who may request certificate modification
+### 4.8.3 Processing certificate modification requests
+### 4.8.4 Notification of new certificate issuance to subscriber
+### 4.8.5 Conduct constituting acceptance of modified certificate
+### 4.8.6 Publication of the modified certificate by the CA
+### 4.8.7 Notification of certificate issuance by the CA to other entities
+## 4.9 Certificate revocation and suspension
+### 4.9.1 Circumstances for revocation
+### 4.9.2 Who can request revocation
+### 4.9.3 Procedure for revocation request
+### 4.9.4 Revocation request grace period
+### 4.9.5 Time within which CA must process the revocation request
+### 4.9.6 Revocation checking requirement for relying parties
+### 4.9.7 CRL issuance frequency (if applicable)
+### 4.9.8 Maximum latency for CRLs (if applicable)
+### 4.9.9 On-line revocation/status checking availability
+### 4.9.10 On-line revocation checking requirements
+### 4.9.11 Other forms of revocation advertisements available
+### 4.9.12 Special requirements re key compromise
+### 4.9.13 Circumstances for suspension
+### 4.9.14 Who can request suspension
+### 4.9.15 Procedure for suspension request
+### 4.9.16 Limits on suspension period
+## 4.10 Certificate status services
+### 4.10.1 Operational characteristics
+### 4.10.2 Service availability
+### 4.10.3 Optional features
+## 4.11 End of subscription
+## 4.12 Key escrow and recovery
+### 4.12.1 Key escrow and recovery policy and practices
+### 4.12.2 Session key encapsulation and recovery policy and practices
+# 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS
+## 5.1 Physical controls
+### 5.1.1 Site location and construction
+### 5.1.2 Physical access
+### 5.1.3 Power and air conditioning
+### 5.1.4 Water exposures
+### 5.1.5 Fire prevention and protection
+### 5.1.6 Media storage
+### 5.1.7 Waste disposal
+### 5.1.8 Off-site backup
+## 5.2 Procedural controls
+### 5.2.1 Trusted roles
+### 5.2.2 Number of persons required per task
+### 5.2.3 Identification and authentication for each role
+### 5.2.4 Roles requiring separation of duties
+## 5.3 Personnel controls
+### 5.3.1 Qualifications, experience, and clearance requirements
+### 5.3.2 Background check procedures
+### 5.3.3 Training requirements
+### 5.3.4 Retraining frequency and requirements
+### 5.3.5 Job rotation frequency and sequence
+### 5.3.6 Sanctions for unauthorized actions
+### 5.3.7 Independent contractor requirements
+### 5.3.8 Documentation supplied to personnel
+## 5.4 Audit logging procedures
+### 5.4.1 Types of events recorded
+### 5.4.2 Frequency of processing log
+### 5.4.3 Retention period for audit log
+### 5.4.4 Protection of audit log
+### 5.4.5 Audit log backup procedures
+### 5.4.6 Audit collection system (internal vs. external)
+### 5.4.7 Notification to event-causing subject
+### 5.4.8 Vulnerability assessments
+## 5.5 Records archival
+### 5.5.1 Types of records archived
+### 5.5.2 Retention period for archive
+### 5.5.3 Protection of archive
+### 5.5.4 Archive backup procedures
+### 5.5.5 Requirements for time-stamping of records
+### 5.5.6 Archive collection system (internal or external)
+### 5.5.7 Procedures to obtain and verify archive information
+## 5.6 Key changeover
+## 5.7 Compromise and disaster recovery
+### 5.7.1 Incident and compromise handling procedures
+### 5.7.2 Computing resources, software, and/or data are corrupted
+### 5.7.3 Entity private key compromise procedures
+### 5.7.4 Business continuity capabilities after a disaster
+## 5.8 CA or RA termination
+# 6. TECHNICAL SECURITY CONTROLS
+## 6.1 Key pair generation and installation
+### 6.1.1 Key pair generation
+### 6.1.2 Private key delivery to subscriber
+### 6.1.3 Public key delivery to certificate issuer
+### 6.1.4 CA public key delivery to relying parties
+### 6.1.5 Key sizes
+### 6.1.6 Public key parameters generation and quality checking
+### 6.1.7 Key usage purposes (as per X.509 v3 key usage field)
+## 6.2 Private Key Protection and Cryptographic Module Engineering Controls
+### 6.2.1 Cryptographic module standards and controls
+### 6.2.2 Private key (n out of m) multi-person control
+### 6.2.3 Private key escrow
+### 6.2.4 Private key backup
+### 6.2.5 Private key archival
+### 6.2.6 Private key transfer into or from a cryptographic module
+### 6.2.7 Private key storage on cryptographic module
+### 6.2.8 Method of activating private key
+### 6.2.9 Method of deactivating private key
+### 6.2.10 Method of destroying private key
+### 6.2.11 Cryptographic Module Rating
+## 6.3 Other aspects of key pair management
+### 6.3.1 Public key archival
+### 6.3.2 Certificate operational periods and key pair usage periods
+## 6.4 Activation data
+### 6.4.1 Activation data generation and installation
+### 6.4.2 Activation data protection
+### 6.4.3 Other aspects of activation data
+## 6.5 Computer security controls
+### 6.5.1 Specific computer security technical requirements
+### 6.5.2 Computer security rating
+## 6.6 Life cycle technical controls
+### 6.6.1 System development controls
+### 6.6.2 Security management controls
+### 6.6.3 Life cycle security controls
+## 6.7 Network security controls
+## 6.8 Time-stamping
+# 7. CERTIFICATE, CRL, AND OCSP PROFILES
+## 7.1 Certificate profile
+### 7.1.1 Version number(s)
+### 7.1.2 Certificate extensions
+### 7.1.3 Algorithm object identifiers
+### 7.1.4 Name forms
+### 7.1.5 Name constraints
+### 7.1.6 Certificate policy object identifier
+### 7.1.7 Usage of Policy Constraints extension
+### 7.1.8 Policy qualifiers syntax and semantics
+### 7.1.9 Processing semantics for the critical Certificate Policies extension
+## 7.2 CRL profile
+### 7.2.1 Version number(s)
+### 7.2.2 CRL and CRL entry extensions
+## 7.3 OCSP profile
+### 7.3.1 Version number(s)
+### 7.3.2 OCSP extensions
+# 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
+## 8.1 Frequency or circumstances of assessment
+## 8.2 Identity/qualifications of assessor
+## 8.3 Assessor's relationship to assessed entity
+## 8.4 Topics covered by assessment
+## 8.5 Actions taken as a result of deficiency
+## 8.6 Communication of results
+# 9. OTHER BUSINESS AND LEGAL MATTERS
+## 9.1 Fees
+### 9.1.1 Certificate issuance or renewal fees
+### 9.1.2 Certificate access fees
+### 9.1.3 Revocation or status information access fees
+### 9.1.4 Fees for other services
+### 9.1.5 Refund policy
+## 9.2 Financial responsibility
+### 9.2.1 Insurance coverage
+### 9.2.2 Other assets
+### 9.2.3 Insurance or warranty coverage for end-entities
+## 9.3 Confidentiality of business information
+### 9.3.1 Scope of confidential information
+### 9.3.2 Information not within the scope of confidential information
+### 9.3.3 Responsibility to protect confidential information
+## 9.4 Privacy of personal information
+### 9.4.1 Privacy plan
+### 9.4.2 Information treated as private
+### 9.4.3 Information not deemed private
+### 9.4.4 Responsibility to protect private information
+### 9.4.5 Notice and consent to use private information
+### 9.4.6 Disclosure pursuant to judicial or administrative process
+### 9.4.7 Other information disclosure circumstances
+## 9.5 Intellectual property rights
+## 9.6 Representations and warranties
+### 9.6.1 CA representations and warranties
+### 9.6.2 RA representations and warranties
+### 9.6.3 Subscriber representations and warranties
+### 9.6.4 Relying party representations and warranties
+### 9.6.5 Representations and warranties of other participants
+## 9.7 Disclaimers of warranties
+## 9.8 Limitations of liability
+## 9.9 Indemnities
+## 9.10 Term and termination
+### 9.10.1 Term
+### 9.10.2 Termination
+### 9.10.3 Effect of termination and survival
+## 9.11 Individual notices and communications with participants
+## 9.12 Amendments
+### 9.12.1 Procedure for amendment
+### 9.12.2 Notification mechanism and period
+### 9.12.3 Circumstances under which OID must be changed
+## 9.13 Dispute resolution provisions
+## 9.14 Governing law
+## 9.15 Compliance with applicable law
+## 9.16 Miscellaneous provisions
+### 9.16.1 Entire agreement
+### 9.16.2 Assignment
+### 9.16.3 Severability
+### 9.16.4 Enforcement (attorneys' fees and waiver of rights)
+### 9.16.5 Force Majeure
+## 9.17 Other provisions