From eff3d4710271f0ab03130ca8fee74eefd9fb41de Mon Sep 17 00:00:00 2001 From: Wayne Thayer Date: Wed, 28 Feb 2024 11:09:30 -0700 Subject: [PATCH 01/11] Add method 3.2.2.4.21 --- docs/BR.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/BR.md b/docs/BR.md index c85365b1f..11f89a0c1 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -908,6 +908,12 @@ The token (as defined in RFC 8737, Section 3) MUST NOT be used for more than 30 **Note**: Once the FQDN has been validated using this method, 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.21 DNS Change using ACME Account ID + +Confirming the Applicant's control over a FQDN by validating domain control of the FQDN using the “dns-account‐01” challenge in draft 00 of “ACME Scoped DNS Challenges,” available at [https://www.ietf.org/archive/id/draft-ietf-acme-scoped-dns-challenges-00.html](https://www.ietf.org/archive/id/draft-ietf-acme-scoped-dns-challenges-00.html). + +**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 if the scope of the challenge is "domain". This method is suitable for validating Wildcard Domain Names if the scope of the challenge is "wildcard". + #### 3.2.2.5 Authentication for an IP Address This section defines the permitted processes and procedures for validating the Applicant’s ownership or control of an IP Address listed in a Certificate. From 098fefd2ef36e72b42b9c82fb5de6f33e43c0b74 Mon Sep 17 00:00:00 2001 From: Wayne Thayer Date: Thu, 29 Feb 2024 10:03:28 -0700 Subject: [PATCH 02/11] Add token expiration --- docs/BR.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 11f89a0c1..d229fc12f 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -912,7 +912,9 @@ The token (as defined in RFC 8737, Section 3) MUST NOT be used for more than 30 Confirming the Applicant's control over a FQDN by validating domain control of the FQDN using the “dns-account‐01” challenge in draft 00 of “ACME Scoped DNS Challenges,” available at [https://www.ietf.org/archive/id/draft-ietf-acme-scoped-dns-challenges-00.html](https://www.ietf.org/archive/id/draft-ietf-acme-scoped-dns-challenges-00.html). -**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 if the scope of the challenge is "domain". This method is suitable for validating Wildcard Domain Names if the scope of the challenge is "wildcard". +The token (as defined in this draft RFC) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for the token, 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 Domain Labels of the validated FQDN if the scope of the challenge is "domain" as defined in this draft RFC. This method is suitable for validating Wildcard Domain Names if the scope of the challenge is "wildcard" as defined in this draft RFC. #### 3.2.2.5 Authentication for an IP Address From d820f37f9e1550805c210dcaf5162b7f86ccfb69 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?I=C3=B1igo=20Barreira?= <92998585+barrini@users.noreply.github.com> Date: Wed, 2 Oct 2024 17:45:19 +0300 Subject: [PATCH 03/11] SC-077: Update WebTrust Audit name in Section 8.4 and References (#514) (#543) * SC-077: Update WebTrust Audit name in Section 8.4 and References (#514) * Add updated WebTrust Audit name Update 8.4 to reference updated WebTrust document names * Update BR.md --------- Co-authored-by: Clint Wilson * Update BR.md New TLS BRs version according to ballot SC77 --------- Co-authored-by: Clint Wilson Co-authored-by: Clint Wilson --- docs/BR.md | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index d9b61fc57..f8bdab1eb 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,11 +1,11 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates -subtitle: Version 2.0.7 +subtitle: Version 2.0.8 author: - CA/Browser Forum -date: 6-September-2024 +date: 2-October-2024 @@ -144,6 +144,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2.0.5 | SC73 | Compromised and weak keys | 3-May-2024 | 1-July-2024 | | 2.0.6 | SC75 | Pre-sign linting | 28-June-2024 | 6-August-2024 | | 2.0.7 | SC67 | Require Multi-Perspective Issuance Corroboration | 2-August-2024 | 6-September-2024 | +| 2.0.8 | SC77 | Update WebTrust Audit name in Section 8.4 and References | 2-September-2024 | 2-October-2024 | \* Effective Date and Additionally Relevant Compliance Date(s) @@ -614,6 +615,8 @@ RFC8954, Request for Comments: 8954, Online Certificate Status Protocol (OCSP) N WebTrust for Certification Authorities, SSL Baseline with Network Security, available at +[WebTrust Principles and Criteria for Certification Authorities – SSL Baseline](https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/principles-and-criteria) + 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 @@ -3496,11 +3499,16 @@ The CA's audit SHALL be performed by a Qualified Auditor. A Qualified Auditor me The CA SHALL undergo an audit in accordance with one of the following schemes: -1. "WebTrust for CAs v2.1 or newer" AND "WebTrust for CAs SSL Baseline with Network Security v2.3 or newer"; or -2. ETSI EN 319 411-1 v1.2.2, which includes normative references to ETSI EN 319 401 (the latest version of the referenced ETSI documents should be applied); or -3. If a Government CA is required by its Certificate Policy to use a different internal audit scheme, it MAY use such scheme provided that the audit either - a. encompasses all requirements of one of the above schemes or - b. consists of comparable criteria that are available for public review. +1. WebTrust: + * "Principles and Criteria for Certification Authorities" Version 2.2 or newer; and either + * "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security" Version 2.7 or newer; or + * "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline" Version 2.8 or newer and "WebTrust Principles and Criteria for Certification Authorities – Network Security" Version 1.0 or newer +2. ETSI: + * ETSI EN 319 411-1 v1.4.1 or newer, which includes normative references to ETSI EN 319 401 (the latest version of the referenced ETSI documents should be applied); or +3. Other: + * If a Government CA is required by its Certificate Policy to use a different internal audit scheme, it MAY use such scheme provided that the audit either + a. encompasses all requirements of one of the above schemes; or + b. consists of comparable criteria that are available for public review. Whichever scheme is chosen, it MUST incorporate periodic monitoring and/or accountability procedures to ensure that its audits continue to be conducted in accordance with the requirements of the scheme. From 911e47e2657de64a7455ba16319b96ffdb5816cd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?I=C3=B1igo=20Barreira?= <92998585+barrini@users.noreply.github.com> Date: Fri, 8 Nov 2024 12:04:37 +0100 Subject: [PATCH 04/11] =?UTF-8?q?SC-078=20-=20Subject=20organizationName?= =?UTF-8?q?=20alignment=20for=20DBA=20/=20Assumed=20Name=20(#=E2=80=A6=20(?= =?UTF-8?q?#552)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * SC-078 - Subject organizationName alignment for DBA / Assumed Name (#545) * Align with EVG and SBRs * Align IV with OV * Remove AssumedName Usage Co-authored-by: Corey Bonnell * Remove AssumedName Usage Co-authored-by: Corey Bonnell --------- Co-authored-by: Corey Bonnell * Update BR.md Update of date, version, ... --------- Co-authored-by: Martijn Katerbarg Co-authored-by: Corey Bonnell --- docs/BR.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index f8bdab1eb..ca03f6b29 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,11 +1,12 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates -subtitle: Version 2.0.8 +subtitle: Version 2.0.9 author: - CA/Browser Forum -date: 2-October-2024 +date: 8-November-2024 + @@ -145,6 +146,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2.0.6 | SC75 | Pre-sign linting | 28-June-2024 | 6-August-2024 | | 2.0.7 | SC67 | Require Multi-Perspective Issuance Corroboration | 2-August-2024 | 6-September-2024 | | 2.0.8 | SC77 | Update WebTrust Audit name in Section 8.4 and References | 2-September-2024 | 2-October-2024 | +| 2.0.9 | SC78 | Subject organizationName alignment for DBA / Assumed Name | 2-October-2024 | 8-November-2024 \* Effective Date and Additionally Relevant Compliance Date(s) @@ -2491,7 +2493,7 @@ Table: Individual Validated `subject` Attributes | `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `postalCode` | NOT RECOMMENDED | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `streetAddress` | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. Multiple instances MAY be present. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `organizationName` | NOT RECOMMENDED | If present, MUST contain the Subject's name or DBA. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `organizationName` | NOT RECOMMENDED | If present, MUST contain the Subject's name and/or DBA/tradename. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations. If both are included, the DBA/tradename SHALL appear first, followed by the Subject's name in parentheses. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `surname` | MUST | The Subject's surname. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `givenName` | MUST | The Subject's given name. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `organizationalUnitName` | MUST NOT | - | - | @@ -2524,7 +2526,7 @@ Table: Organization Validated `subject` Attributes | `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.2.1](#3221-identity) | | `postalCode` | NOT RECOMMENDED | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.2.1](#3221-identity)) | | `streetAddress` | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. Multiple instances MAY be present.| [Section 3.2.2.1](#3221-identity) | -| `organizationName` | MUST | The Subject's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | +| `organizationName` | MUST | The Subject's name and/or DBA/tradename. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". If both are included, the DBA/tradename SHALL appear first, followed by the Subject's name in parentheses. | [Section 3.2.2.2](#3222-dbatradename) | | `surname` | MUST NOT | - | - | | `givenName` | MUST NOT | - | - | | `organizationalUnitName` | MUST NOT | - | - | From ed6b5458d8927d6d5398822911e2182c8cf83ce6 Mon Sep 17 00:00:00 2001 From: Martijn Katerbarg Date: Thu, 14 Nov 2024 15:41:36 +0100 Subject: [PATCH 05/11] Update upload-artifact to v4 due to github deprecation (#562) --- .github/workflows/build-draft-docs.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/build-draft-docs.yml b/.github/workflows/build-draft-docs.yml index f156aa54a..a8af8a55c 100644 --- a/.github/workflows/build-draft-docs.yml +++ b/.github/workflows/build-draft-docs.yml @@ -28,7 +28,7 @@ jobs: docx: true lint: true draft: ${{ !(github.event_name == 'push' && github.repository == 'cabforum/servercert' && github.ref == 'refs/heads/main') }} - - uses: actions/upload-artifact@v3 + - uses: actions/upload-artifact@v4 with: name: ${{ matrix.document }}-${{ github.event.pull_request.head.sha || github.sha }}-${{ github.event_name }} path: | From 3b19b48cfb86e457ba679a67e51ed00fd3c5f5f5 Mon Sep 17 00:00:00 2001 From: Aaron Gable Date: Thu, 14 Nov 2024 07:05:57 -0800 Subject: [PATCH 06/11] Ballot SC-76: Clarify and improve OCSP requirements (#535) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Ballot SC-XX: Clarify and improve OCSP requirements This ballot attempts to address three concerns: - The confusion around "reserved" serials, which do not actually exist because all Precertificate serials are assumed to also exist in corresponding Certificates and are therefore actually "assigned"; - Confusion around whether, and how quickly, OCSP responders must begin providing authoritative responses for Certificates and Precertificates; and - Confusion around whether and how the OCSP requirements apply to Certificates which do not contain an AIA OCSP URL, but for which the CA's OCSP responder is still willing to provide responses. Addresses https://github.com/mozilla/pkipolicy/issues/280 Addresses https://github.com/cabforum/servercert/issues/422 * Respond to comments, and reorganize further * Empty line before bullets * Address comments * Use singular, use "published or made available" * Use the singular even more * Discussion period feedback from Trev * Update BR.md --------- Co-authored-by: Iñigo Barreira <92998585+barrini@users.noreply.github.com> --- docs/BR.md | 56 ++++++++++++++++++++++++------------------------------ 1 file changed, 25 insertions(+), 31 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index ca03f6b29..ba1dcc58a 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,11 +1,11 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates -subtitle: Version 2.0.9 +subtitle: Version 2.1.0 author: - CA/Browser Forum -date: 8-November-2024 +date: 14-November-2024 @@ -146,7 +146,8 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2.0.6 | SC75 | Pre-sign linting | 28-June-2024 | 6-August-2024 | | 2.0.7 | SC67 | Require Multi-Perspective Issuance Corroboration | 2-August-2024 | 6-September-2024 | | 2.0.8 | SC77 | Update WebTrust Audit name in Section 8.4 and References | 2-September-2024 | 2-October-2024 | -| 2.0.9 | SC78 | Subject organizationName alignment for DBA / Assumed Name | 2-October-2024 | 8-November-2024 +| 2.0.9 | SC78 | Subject organizationName alignment for DBA / Assumed Name | 2-October-2024 | 8-November-2024 | +| 2.1.0 | SC76 | Clarify and improve OCSP requirements | 14-November-2024 | 15-January-2025 | \* Effective Date and Additionally Relevant Compliance Date(s) @@ -200,11 +201,13 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2023-09-15 | Section 7 (and others) | CAs MUST use the updated Certificate Profiles passed in Version 2.0.0 | | 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | | 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | +| 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | | 2025-03-15 | 4.3.1.2 | The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | | 2025-03-15 | 8.7 | The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits. | | 2025-03-15 | 3.2.2.9 | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. | + ## 1.3 PKI Participants The CA/Browser Forum is a voluntary organization of Certification Authorities and suppliers of Internet browser and other relying-party software applications. @@ -1465,50 +1468,41 @@ No stipulation. ### 4.9.9 On-line revocation/status checking availability -The following SHALL apply for communicating the status of Certificates which include an Authority Information Access extension with an id-ad-ocsp accessMethod. - -OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either: +The validity interval of an OCSP response is the difference in time between the `thisUpdate` and `nextUpdate` field, inclusive. For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds. -1. Be signed by the CA that issued the Certificates whose revocation status is being checked, or -2. Be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose -revocation status is being checked. +A certificate serial is "assigned" if: -In the latter case, the OCSP signing Certificate MUST contain an extension of type `id-pkix-ocsp-nocheck`, as -defined by RFC6960. +- a Certificate or Precertificate with that serial number has been issued by the Issuing CA; or +- a Precertificate with that serial number has been issued by a Precertificate Signing Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile), associated with the Issuing CA. -### 4.9.10 On-line revocation checking requirements +A certificate serial is "unassigned" if it is not "assigned". -The following SHALL apply for communicating the status of Certificates which include an Authority Information Access extension with an id-ad-ocsp accessMethod. +The following SHALL apply for communicating the status of Certificates and Precertificates which include an Authority Information Access extension with an id-ad-ocsp accessMethod. OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019. The CA MAY process the Nonce extension (`1.3.6.1.5.5.7.48.1.2`) in accordance with RFC 8954. -The validity interval of an OCSP response is the difference in time between the `thisUpdate` and `nextUpdate` field, inclusive. For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds. +For the status of a Subscriber Certificate or its corresponding Precertificate: -For the status of Subscriber Certificates: +- Effective 2025-01-15, an authoritative OCSP response MUST be available (i.e. the responder MUST NOT respond with the "unknown" status) starting no more than 15 minutes after the Certificate or Precertificate is first published or otherwise made available. +- For OCSP responses with validity intervals less than sixteen hours, the CA SHALL provide an updated OCSP response prior to one-half of the validity period before the nextUpdate. +- For OCSP responses with validity intervals greater than or equal to sixteen hours, the CA SHALL provide an updated OCSP response at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate. -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. -4. For OCSP responses with validity intervals greater than or equal to sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate. +For the status of a Subordinate CA Certificate, the CA SHALL provide an updated OCSP response at least every twelve months, and within 24 hours after revoking the Certificate. -For the status of Subordinate CA Certificates: +The following SHALL apply for communicating the status of *all* Certificates for which an OCSP responder is willing or required to respond. -* The CA SHALL update information provided via an Online Certificate Status Protocol +OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either: - i. at least every twelve months; and - ii. within 24 hours after revoking a Subordinate CA Certificate. +1. be signed by the CA that issued the Certificates whose revocation status is being checked, or +2. be signed by an OCSP Responder which complies with the OCSP Responder Certificate Profile in [Section 7.1.2.8](#7128-ocsp-responder-certificate-profile). -If the OCSP responder receives a request for the status of a certificate serial number that is "unused", then the responder SHOULD NOT respond with a "good" status. If the OCSP responder is for a CA that is not Technically Constrained in line with [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), the responder MUST NOT respond with a "good" status for such requests. +OCSP responses for Subscriber Certificates MUST have a validity interval greater than or equal to eight hours and less than or equal to ten days. -The OCSP responder MAY provide definitive responses about "reserved" certificate serial numbers, as if there was a corresponding Certificate that matches the Precertificate [RFC6962]. +If the OCSP responder receives a request for the status of a certificate serial number that is "unassigned", then the responder SHOULD NOT respond with a "good" status. If the OCSP responder is for a CA that is not Technically Constrained in line with [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), the responder MUST NOT respond with a "good" status for such requests. -A certificate serial number within an OCSP request is one of the following three options: +### 4.9.10 On-line revocation checking requirements -1. "assigned" if a Certificate with that serial number has been issued by the Issuing CA, using any current or previous key associated with that CA subject; or -2. "reserved" if a Precertificate [RFC6962] with that serial number has been issued by - a. the Issuing CA; or - b. a Precertificate Signing Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile), associated with the Issuing CA; or -3. "unused" if neither of the previous conditions are met. +No Stipulation. ### 4.9.11 Other forms of revocation advertisements available From 38f098f3e278f6e80ba7495906819de78c35cd68 Mon Sep 17 00:00:00 2001 From: Paul van Brouwershaven Date: Mon, 18 Nov 2024 10:41:45 +0100 Subject: [PATCH 07/11] SC-079v2 - Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate (#544) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate * Add exception Subscriber Certificates that chain up directly to the Certificate issued under this Certificate Profile * Update policyIdentifier description * Remove condition, a Cross-Certified Subordinate CA Certificate MUST always contain this extension Co-authored-by: Corey Bonnell * Update BR.md --------- Co-authored-by: Corey Bonnell Co-authored-by: Iñigo Barreira <92998585+barrini@users.noreply.github.com> --- docs/BR.md | 51 ++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 46 insertions(+), 5 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index ba1dcc58a..d634f4820 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -148,6 +148,8 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2.0.8 | SC77 | Update WebTrust Audit name in Section 8.4 and References | 2-September-2024 | 2-October-2024 | | 2.0.9 | SC78 | Subject organizationName alignment for DBA / Assumed Name | 2-October-2024 | 8-November-2024 | | 2.1.0 | SC76 | Clarify and improve OCSP requirements | 14-November-2024 | 15-January-2025 | +| 2.1.1 | SC79 | Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate | 18-November-2024 | 15-January-2025 | + \* Effective Date and Additionally Relevant Compliance Date(s) @@ -199,15 +201,13 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2023-01-15 | 7.2.2 | Sharded or partitioned CRLs MUST have a distributionPoint | | 2023-07-15 | 4.9.1.1 and 7.2.2 | New CRL entries MUST have a revocation reason code | | 2023-09-15 | Section 7 (and others) | CAs MUST use the updated Certificate Profiles passed in Version 2.0.0 | -| 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | +| 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | | 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | | 2025-03-15 | 4.3.1.2 | The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | | 2025-03-15 | 8.7 | The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits. | | 2025-03-15 | 3.2.2.9 | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. | - - ## 1.3 PKI Participants The CA/Browser Forum is a voluntary organization of Certification Authorities and suppliers of Internet browser and other relying-party software applications. @@ -2093,7 +2093,7 @@ The `subject` MUST comply with the requirements of [Section 7.1.4](#714-name-for | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.2.6](#71226-cross-certified-subordinate-ca-certificate-certificate-policies) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | | `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | @@ -2171,6 +2171,47 @@ Each included Extended Key Usage key usage purpose: CAs MUST NOT include additional key usage purposes unless the CA is aware of a reason for including the key usage purpose in the Certificate. +##### 7.1.2.2.6 Cross-Certified Subordinate CA Certificate Certificate Policies + +The Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: + + +Table: No Policy Restrictions (Affiliated CA) + +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, and if the Subordinate CA is an Affiliate of the Issuing CA, then the Issuing CA MAY use the `anyPolicy` Policy Identifier, which MUST be the only `PolicyInformation` value. | +|     `anyPolicy` | MUST | | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | + + +Table: Policy Restricted + +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | One of the following policy identifiers: | +|     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The CA MUST include at least one Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)) transitively issued by this Certificate. | +|     `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. | +|     Any other identifier | MAY | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | + + +This Profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST include at least one Reserved Certificate Policy Identifier. If any Subscriber Certificates will chain up directly to the Certificate issued under this Certificate Profile, this Cross-Certified Subordinate CA Certificate MUST contain exactly one Reserved Certificate Policy Identifier. + + +**Note**: policyQualifiers is NOT RECOMMENDED to be present in any Certificate issued under this Certificate Profile because this information increases the size of the Certificate without providing any value to a typical Relying Party, and the information may be obtained by other means when necessary. + + +If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: + + +Table: Permitted `policyQualifiers` + +| __Qualifier ID__ | __Presence__ | __Field Type__ | __Contents__ | +| --- | - | - | ----- | +| `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | +| Any other qualifier | MUST NOT | - | - | + #### 7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate Profile This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will not be used to issue TLS certificates directly or transitively. @@ -2951,7 +2992,7 @@ Table: No Policy Restrictions (Affiliated CA) | __Field__ | __Presence__ | __Contents__ | | --- | - | ------ | -| `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, the Subordinate CA MUST be an Affiliate of the Issuing CA. The Certificate Policies extension MUST contain only a single `PolicyInformation` value, which MUST contain the `anyPolicy` Policy Identifier. | +| `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, and if the Subordinate CA is an Affiliate of the Issuing CA, then the Issuing CA MAY use the `anyPolicy` Policy Identifier, which MUST be the only `PolicyInformation` value. | |     `anyPolicy` | MUST | | | `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | From 096810820d605d1a2c90a9b10e4ef36ed65bd6cc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?I=C3=B1igo=20Barreira?= <92998585+barrini@users.noreply.github.com> Date: Mon, 18 Nov 2024 11:05:49 +0100 Subject: [PATCH 08/11] Update BR.md (#563) --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index d634f4820..a7c9b0cb7 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,11 +1,11 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates -subtitle: Version 2.1.0 +subtitle: Version 2.1.1 author: - CA/Browser Forum -date: 14-November-2024 +date: 18-November-2024 From b7fd69b36171d81930e7758482984ce957a1ce7a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?I=C3=B1igo=20Barreira?= <92998585+barrini@users.noreply.github.com> Date: Mon, 16 Dec 2024 17:50:13 +0100 Subject: [PATCH 09/11] =?UTF-8?q?Ballot=20SC-080=20V3:=20"Sunset=20the=20u?= =?UTF-8?q?se=20of=20WHOIS=20to=20identify=20Domain=20Contact=E2=80=A6=20(?= =?UTF-8?q?#560)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Ballot SC-080 V3: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods" (#555) BRs release version 2.1.2 --- docs/BR.md | 245 +++++++++++++++++++++++++++++------------------------ 1 file changed, 136 insertions(+), 109 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index a7c9b0cb7..8af1ad23d 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,15 +1,11 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates -subtitle: Version 2.1.1 +subtitle: Version 2.1.2 author: - CA/Browser Forum -date: 18-November-2024 - - - - +date: 16-December-2024 copyright: | Copyright 2024 CA/Browser Forum @@ -49,107 +45,107 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse ### 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 | -| 1.7.9 | SC47 | Sunset subject:organizationalUnitName | 30-Jun-2021 | 16-Aug-2021 | -| 1.8.0 | SC48 | Domain Name and IP Address Encoding | 22-Jul-2021 | 25-Aug-2021 | -| 1.8.1 | SC50 | Remove the requirements of 4.1.1 | 22-Nov-2021 | 23-Dec-2021 | -| 1.8.2 | SC53 | Sunset for SHA-1 OCSP Signing | 26-Jan-2022 | 4-Mar-2022 | -| 1.8.3 | SC51 | Reduce and Clarify Log and Records Archival Retention Requirements | 01-Mar-2022 | 15-Apr-2022 | -| 1.8.4 | SC54 | Onion Cleanup | 24-Mar-2022 | 23-Apr-2022 | -| 1.8.5 | SC56 | 2022 Cleanup | 25-Oct-2022 | 30-Nov-2022 | -| 1.8.6 | SC58 | Require distributionPoint in sharded CRLs | 7-Nov-2022 | 11-Dec-2022 | -| 1.8.7 | SC61 | New CRL entries must have a Revocation Reason Code | 1-Apr-2023 | 15-Jul-2023 | -| 2.0.0 | SC62 | Certificate Profiles Update | 22-Apr-2023 | 15-Sep-2023 | -| 2.0.1 | SC63 | Make OCSP optional, require CRLs, and incentivize automation | 17-Aug-2023 | 15-Mar-2024 | -| 2.0.2 | SC66 | 2023 Cleanup | 23-Nov-2023 | 8-Jan-2024 | -| 2.0.3 | SC69 | Clarify router and firewall logging requirements | 13-March-2024 | 15-April-2024 | -| 2.0.4 | SC65 | Convert EVGs into RFC 3647 format | 15-March-2024 | 15-May-2024 | -| 2.0.5 | SC73 | Compromised and weak keys | 3-May-2024 | 1-July-2024 | -| 2.0.6 | SC75 | Pre-sign linting | 28-June-2024 | 6-August-2024 | -| 2.0.7 | SC67 | Require Multi-Perspective Issuance Corroboration | 2-August-2024 | 6-September-2024 | -| 2.0.8 | SC77 | Update WebTrust Audit name in Section 8.4 and References | 2-September-2024 | 2-October-2024 | -| 2.0.9 | SC78 | Subject organizationName alignment for DBA / Assumed Name | 2-October-2024 | 8-November-2024 | -| 2.1.0 | SC76 | Clarify and improve OCSP requirements | 14-November-2024 | 15-January-2025 | -| 2.1.1 | SC79 | Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate | 18-November-2024 | 15-January-2025 | - +| **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-Jul-2013 | 29-Jul-2013 | +| 1.1.7 | 112 | Replace Definition of "Internal Server Name" with "Internal Name" | 3-Apr-2014 | 3-Apr-2014 | +| 1.1.8 | 120 | Affiliate Authority to Verify Domain | 5-Jun-2014 | 5-Jun-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-Apr-2015 | 2-Apr-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-Jul-2016 | 1-Jul-2016 | +| 1.3.7 | 164 | Certificate Serial Number Entropy | 8-Jul-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-Jul-2016 | 11-Sep-2016 | +| 1.4.1 | 175 | Addition of givenName and surname | 7-Sep-2016 | 7-Sep-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-Jun-2017 | +| 1.4.9 | 204 | Forbid DTPs from doing Domain/IP Ownership | 11-Jul-2017 | 11-Aug-2017 | +| 1.5.0 | 212 | Canonicalise formal name of the Baseline Requirements | 1-Sep-2017 | 1-Oct-2017 | +| 1.5.1 | 197 | Effective Date of Ballot 193 Provisions | 1-May-2017 | 2-Jun-2017 | +| 1.5.2 | 190 | Add Validation Methods with Minor Corrections | 19-Sep-2017 | 19-Oct-2017 | +| 1.5.3 | 214 | CAA Discovery CNAME Errata | 27-Sep-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 | +| 1.7.9 | SC47 | Sunset subject:organizationalUnitName | 30-Jun-2021 | 16-Aug-2021 | +| 1.8.0 | SC48 | Domain Name and IP Address Encoding | 22-Jul-2021 | 25-Aug-2021 | +| 1.8.1 | SC50 | Remove the requirements of 4.1.1 | 22-Nov-2021 | 23-Dec-2021 | +| 1.8.2 | SC53 | Sunset for SHA-1 OCSP Signing | 26-Jan-2022 | 4-Mar-2022 | +| 1.8.3 | SC51 | Reduce and Clarify Log and Records Archival Retention Requirements | 01-Mar-2022 | 15-Apr-2022 | +| 1.8.4 | SC54 | Onion Cleanup | 24-Mar-2022 | 23-Apr-2022 | +| 1.8.5 | SC56 | 2022 Cleanup | 25-Oct-2022 | 30-Nov-2022 | +| 1.8.6 | SC58 | Require distributionPoint in sharded CRLs | 7-Nov-2022 | 11-Dec-2022 | +| 1.8.7 | SC61 | New CRL entries must have a Revocation Reason Code | 1-Apr-2023 | 15-Jul-2023 | +| 2.0.0 | SC62 | Certificate Profiles Update | 22-Apr-2023 | 15-Sep-2023 | +| 2.0.1 | SC63 | Make OCSP optional, require CRLs, and incentivize automation | 17-Aug-2023 | 15-Mar-2024 | +| 2.0.2 | SC66 | 2023 Cleanup | 23-Nov-2023 | 8-Jan-2024 | +| 2.0.3 | SC69 | Clarify router and firewall logging requirements | 13-Mar-2024 | 15-Apr-2024 | +| 2.0.4 | SC65 | Convert EVGs into RFC 3647 format | 15-Mar-2024 | 15-May-2024 | +| 2.0.5 | SC73 | Compromised and weak keys | 3-May-2024 | 1-Jul-2024 | +| 2.0.6 | SC75 | Pre-sign linting | 28-Jun-2024 | 6-Aug-2024 | +| 2.0.7 | SC67 | Require Multi-Perspective Issuance Corroboration | 2-Aug-2024 | 6-Sep-2024 | +| 2.0.8 | SC77 | Update WebTrust Audit name in Section 8.4 and References | 2-Sep-2024 | 2-Oct-2024 | +| 2.0.9 | SC78 | Subject organizationName alignment for DBA / Assumed Name | 2-Oct-2024 | 8-Nov-2024 | +| 2.1.0 | SC76 | Clarify and improve OCSP requirements | 26-Sep-2024 | 14-Nov-2024 | +| 2.1.1 | SC79 | Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate | 30-Sep-2024 | 14-Nov-2024 | +| 2.1.2 | SC80 | Strengthen WHOIS lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15 | 7-Nov-2024 | 16-Dec-2024 | \* Effective Date and Additionally Relevant Compliance Date(s) @@ -203,10 +199,12 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2023-09-15 | Section 7 (and others) | CAs MUST use the updated Certificate Profiles passed in Version 2.0.0 | | 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | -| 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | +| 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | +| 2025-01-15 | 3.2.2.4 | CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information. | | 2025-03-15 | 4.3.1.2 | The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | | 2025-03-15 | 8.7 | The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits. | -| 2025-03-15 | 3.2.2.9 | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. | +| 2025-03-15 | 3.2.2.9 | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. | +| 2025-07-15 | 3.2.2.4 | CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates. | ## 1.3 PKI Participants @@ -757,6 +755,17 @@ The Random Value SHALL remain valid for use in a confirming response for no more **Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +Effective January 15, 2025: +- When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. +- When obtaining Domain Contact information for a requested Domain Name the CA: + - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. + - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. + - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. + +Effective July 15, 2025: +- The CA MUST NOT rely on this method. +- Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates. + ##### 3.2.2.4.3 Phone Contact with Domain Contact This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates. @@ -826,6 +835,13 @@ Confirming the Applicant's control over the FQDN by validating the Applicant is **Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +Effective January 15, 2025: +- When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. +- When obtaining Domain Contact information for a requested Domain Name the CA: + - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. + - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. + - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. + ##### 3.2.2.4.13 Email to DNS CAA Contact Confirming the Applicant's control over the FQDN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to a DNS CAA Email Contact. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659, Section 3. @@ -862,6 +878,17 @@ The Random Value SHALL remain valid for use in a confirming response for no more **Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +Effective January 15, 2025: +- When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. +- When obtaining Domain Contact information for a requested Domain Name the CA: + - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. + - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. + - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. + +Effective July 15, 2025: +- The CA MUST NOT rely on this method. +- Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates. + ##### 3.2.2.4.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. From 3acd0030135a1134572158c9c08982de20aee89d Mon Sep 17 00:00:00 2001 From: Martijn Katerbarg Date: Mon, 24 Feb 2025 10:37:25 +0100 Subject: [PATCH 10/11] SC083: Winter 2024-2025 Cleanup Ballot (#561) BRs release version 2.1.3 --- docs/BR.md | 113 +++++++++++++++++++++++++++-------------------------- 1 file changed, 58 insertions(+), 55 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 8af1ad23d..c01d966f8 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,14 +1,14 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates -subtitle: Version 2.1.2 +subtitle: Version 2.1.3 author: - CA/Browser Forum -date: 16-December-2024 +date: 24-February-2025 copyright: | - Copyright 2024 CA/Browser Forum + Copyright 2025 CA/Browser Forum This work is licensed under the Creative Commons Attribution 4.0 International license. --- @@ -146,6 +146,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2.1.0 | SC76 | Clarify and improve OCSP requirements | 26-Sep-2024 | 14-Nov-2024 | | 2.1.1 | SC79 | Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate | 30-Sep-2024 | 14-Nov-2024 | | 2.1.2 | SC80 | Strengthen WHOIS lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15 | 7-Nov-2024 | 16-Dec-2024 | +| 2.1.3 | SC83 | Winter 2024-2025 Cleanup Ballot | 23-Jan-2025 | 24-Feb-2025 | \* Effective Date and Additionally Relevant Compliance Date(s) @@ -311,7 +312,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **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 (): "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." +**CAA**: From RFC 8659 (): "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." **CA Key Pair**: A Key Pair where the Public Key appears as the Subject Public Key Info in one or more Root CA Certificate(s) and/or Subordinate CA Certificate(s). @@ -353,7 +354,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **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 Label**: From RFC 8499 (): "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 Label**: From RFC 8499 (): "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. @@ -393,7 +394,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Key Pair**: The Private Key and its associated Public Key. -**LDH Label**: From RFC 5890 (): "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." +**LDH Label**: From RFC 5890 (): "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. @@ -403,7 +404,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Network Perspective**: Related to Multi-Perspective Issuance Corroboration. A system (e.g., a cloud-hosted server instance) or collection of network components (e.g., a VPN and corresponding infrastructure) for sending outbound Internet traffic associated with a domain control validation method and/or CAA check. The location of a Network Perspective is determined by the point where unencapsulated outbound Internet traffic is typically first handed off to the network infrastructure providing Internet connectivity to that perspective. -**Non-Reserved LDH Label**: From RFC 5890 (): "The set of valid LDH labels that do not have '`--`' in the third and fourth positions." +**Non-Reserved LDH Label**: From RFC 5890 (): "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. @@ -494,7 +495,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 or an IP Address 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. @@ -518,7 +519,7 @@ The script outputs: **Validation Specialist**: Someone who performs the information verification duties specified by these Requirements. -**Validity Period**: From RFC 5280 (): "The period of time from notBefore through notAfter, inclusive." +**Validity Period**: From RFC 5280 (): "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. @@ -526,7 +527,7 @@ The script outputs: **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 (): "The class of labels that begin with the prefix `"xn--"` (case independent), but otherwise conform to the rules for LDH labels." +**XN-Label**: From RFC 5890 (): "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 @@ -565,15 +566,13 @@ ETSI EN 319 403, Electronic Signatures and Infrastructures (ESI); Trust Service ETSI EN 319 411-1, Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements -ETSI TS 102 042, Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates. - 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. +FIPS 186-5, Federal Information Processing Standards Publication - Digital Signature Standard (DSS), Information Technology Laboratory, National Institute of Standards and Technology, February 2023. -ISO 21188:2006, Public key infrastructure for financial services -- Practices and policy framework. +ISO 21188:2018, Public key infrastructure for financial services -- Practices and policy framework. Network and Certificate System Security Requirements, Version 1.7, available at @@ -630,7 +629,7 @@ By convention, this document omits time and timezones when listing effective req # 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES -The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. +The CA SHALL develop, implement, enforce, and at least once every 366 days update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. ## 2.1 Repositories @@ -644,7 +643,7 @@ The Certificate Policy and/or Certification Practice Statement MUST be structure 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): -> [Name of CA] conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates published at . In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document. +> [Name of CA] conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates published at . In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document. The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are @@ -798,14 +797,16 @@ This method has been retired and MUST NOT be used. Prior validations using this ##### 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 Domain 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 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 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 3.2.2.14.3 of the EV Guidelines). + 1. 30 days; or + 2. 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 3.2.2.14.3 of the EV Guidelines). -CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective. +CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective. **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. @@ -813,9 +814,9 @@ CAs using this method MUST implement Multi-Perspective Issuance Corroboration as Confirming the Applicant's control over the FQDN by confirming that the Applicant controls an IP address returned from a DNS lookup for A or AAAA records for the FQDN in accordance with [Section 3.2.2.5](#3225-authentication-for-an-ip-address). -CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same IP address as the Primary Network Perspective. +CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same IP address as the Primary Network Perspective. -**Note**: Once the FQDN has been validated using this method, 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. +**Note**: Once the FQDN has been validated using this method, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs separate validations for each of those other FQDNs using authorized methods. This method is NOT suitable for validating Wildcard Domain Names. ##### 3.2.2.4.9 Test Certificate @@ -850,7 +851,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. -CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the selected contact address used for domain validation observed by the Primary Network Perspective. +CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same selected contact address used for domain validation as the Primary Network Perspective. **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. @@ -862,7 +863,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. -CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the selected contact address used for domain validation observed by the Primary Network Perspective. +CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same selected contact address used for domain validation as the Primary Network Perspective. **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. @@ -899,7 +900,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. -CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the selected contact address used for domain validation observed by the Primary Network Perspective. +CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same selected contact address used for domain validation as the Primary Network Perspective. **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. @@ -913,7 +914,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. -CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the selected contact address used for domain validation observed by the Primary Network Perspective. +CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same selected contact address used for domain validation as the Primary Network Perspective. **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. @@ -944,10 +945,10 @@ If a Random Value is used, then: 1. The CA MUST provide a Random Value unique to the certificate request. 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. -Except for Onion Domain Names, CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective. +Except for Onion Domain Names, CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective. **Note**: - * 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 separate validations for each of those other FQDNs using authorized methods. This method is NOT suitable for validating Wildcard Domain Names. ##### 3.2.2.4.19 Agreed-Upon Change to Website - ACME @@ -965,10 +966,10 @@ If the CA follows redirects, the following apply: 2. Redirects MUST be to resource URLs with either the "http" or "https" scheme. 3. Redirects MUST be to resource URLs accessed via Authorized Ports. -Except for Onion Domain Names, CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective. +Except for Onion Domain Names, CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. token) as the Primary Network Perspective. **Note**: - * 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 separate validations for each of those other FQDNs using authorized methods. This method is NOT suitable for validating Wildcard Domain Names. ##### 3.2.2.4.20 TLS Using ALPN @@ -976,9 +977,9 @@ Confirming the Applicant's control over a FQDN by validating domain control of t The token (as defined in RFC 8737, Section 3) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for the token, in which case the CA MUST follow its CPS. -Except for Onion Domain Names, CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same token as the Primary Network Perspective. +Except for Onion Domain Names, CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. token) as the Primary Network Perspective. -**Note**: Once the FQDN has been validated using this method, 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. +**Note**: Once the FQDN has been validated using this method, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs separate validations for each of those other FQDNs using authorized methods. This method is NOT suitable for validating Wildcard Domain Names. #### 3.2.2.5 Authentication for an IP Address @@ -999,7 +1000,7 @@ If a Random Value is used, the CA SHALL provide a Random Value unique to the cer i. 30 days or 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). -CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective. +CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective. ##### 3.2.2.5.2 Email, Fax, SMS, or Postal Mail to IP Address Contact @@ -1019,7 +1020,7 @@ The Random Value SHALL remain valid for use in a confirming response for no more Confirming the Applicant’s control over the IP Address by obtaining a Domain Name associated with the IP Address through a reverse-IP lookup on the IP Address and then verifying control over the FQDN using a method permitted under [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). -CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same FQDN as the Primary Network Perspective. +CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same FQDN as the Primary Network Perspective. ##### 3.2.2.5.4 Any Other Method @@ -1041,13 +1042,13 @@ The Random Value SHALL remain valid for use in a confirming response for no more Confirming the Applicant's control over the IP Address by performing the procedure documented for an "http-01" challenge in RFC 8738. -CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same token as the Primary Network Perspective. +CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. token) as the Primary Network Perspective. ##### 3.2.2.5.7 ACME "tls-alpn-01" method for IP Addresses Confirming the Applicant's control over the IP Address by performing the procedure documented for a "tls-alpn-01" challenge in RFC 8738. -CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same token as the Primary Network Perspective. +CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. token) as the Primary Network Perspective. #### 3.2.2.6 Wildcard Domain Validation @@ -1056,7 +1057,7 @@ Wildcard Domain Name in the Certificate is "registry-controlled" or is a "public 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)](), and to retrieve a fresh copy regularly. +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)](), and to retrieve a fresh copy regularly. If using the PSL, a CA SHOULD consult the "ICANN DOMAINS" section only, not the "PRIVATE DOMAINS" section. The PSL is updated regularly to contain new gTLDs delegated by ICANN, which are listed in the "ICANN DOMAINS" section. A CA is not prohibited from issuing a Wildcard Certificate to the Registrant of an entire gTLD, provided that control of the entire namespace is demonstrated in an appropriate way. @@ -1111,11 +1112,11 @@ The set of responses from the relied upon Network Perspectives MUST provide the Results or information obtained from one Network Perspective MUST NOT be reused or cached when performing validation through subsequent Network Perspectives (e.g., different Network Perspectives cannot rely on a shared DNS cache to prevent an adversary with control of traffic from one Network Perspective from poisoning the DNS cache used by other Network Perspectives). The network infrastructure providing Internet connectivity to a Network Perspective MAY be administered by the same organization providing the computational services required to operate the Network Perspective. All communications between a remote Network Perspective and the CA MUST take place over an authenticated and encrypted channel relying on modern protocols (e.g., over HTTPS). -A Network Perspective MAY use a recursive DNS resolver that is NOT co-located with the Network Perspective. However, the DNS resolver used by the Network Perspective MUST fall within the same Regional Internet Registry service region as the Network Perspective relying upon it. Furthermore, for any pair of DNS resolvers used on a Multi-Perspective Issuance Corroboration attempt, the straight-line distance between the two States, Provinces, or Countries the DNS resolvers reside in MUST be at least 500 km. The location of a DNS resolver is determined by the point where unencapsulated outbound DNS queries are typically first handed off to the network infrastructure providing Internet connectivity to that DNS resolver. +A Network Perspective MAY use a recursive DNS resolver that is NOT co-located with the Network Perspective. However, the DNS resolver used by the Network Perspective MUST fall within the same Regional Internet Registry service region as the Network Perspective relying upon it. Furthermore, for any pair of DNS resolvers used on a Multi-Perspective Issuance Corroboration attempt, the straight-line distance between the two DNS resolvers MUST be at least 500 km. The location of a DNS resolver is determined by the point where unencapsulated outbound DNS queries are typically first handed off to the network infrastructure providing Internet connectivity to that DNS resolver. CAs MAY immediately retry Multi-Perspective Issuance Corroboration using the same validation method or an alternative method (e.g., a CA can immediately retry validation using "Email to DNS TXT Contact" if "Agreed-Upon Change to Website - ACME" does not corroborate the outcome of Multi-Perspective Issuance Corroboration). When retrying Multi-Perspective Issuance Corroboration, CAs MUST NOT rely on corroborations from previous attempts. There is no stipulation regarding the maximum number of validation attempts that may be performed in any period of time. -The "Quorum Requirements" Table describes quorum requirements related to Multi-Perspective Issuance Corroboration. If the CA does NOT rely on the same set of Network Perspectives for both Domain Authorization or Control and CAA Record checks, the quorum requirements MUST be met for both sets of Network Perspectives (i.e.,the Domain Authorization or Control set and the CAA record check set). Network Perspectives are considered distinct when the straight-line distance between the two States, Provinces, or Countries they reside in is at least 500 km. Network Perspectives are considered "remote" when they are distinct from the Primary Network Perspective and the other Network Perspectives represented in a quorum. +The "Quorum Requirements" Table describes quorum requirements related to Multi-Perspective Issuance Corroboration. If the CA does NOT rely on the same set of Network Perspectives for both Domain Authorization or Control and CAA Record checks, the quorum requirements MUST be met for both sets of Network Perspectives (i.e.,the Domain Authorization or Control set and the CAA record check set). Network Perspectives are considered distinct when the straight-line distance between them is at least 500 km. Network Perspectives are considered "remote" when they are distinct from the Primary Network Perspective and the other Network Perspectives represented in a quorum. A CA MAY reuse corroborating evidence for CAA record quorum compliance for a maximum of 398 days. After issuing a Certificate to a domain, remote Network Perspectives MAY omit retrieving and processing CAA records for the same domain or its subdomains in subsequent Certificate requests from the same Applicant for up to a maximum of 398 days. @@ -1156,10 +1157,10 @@ If any of the above considerations are performed by a Delegated Third Party, the Phased Implementation Timeline: - *Effective September 15, 2024*, the CA SHOULD implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. - *Effective March 15, 2025*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MAY proceed with certificate issuance if the number of remote Network Perspectives that do not corroborate the determinations made by the Primary Network Perspective ("non-corroborations") is greater than allowed in the Quorum Requirements table. -- *Effective September 15, 2025*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MUST NOT proceed with certificate issuance if the number of non-corroborations is greater than allowed in the Quorum Requirements table. -- *Effective March 15, 2026*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least three (3) remote Network Perspectives. The CA MUST NOT proceed with certificate issuance if the number of non-corroborations is greater than allowed in the Quorum Requirements table and if the remote Network Perspectives that do corroborate the determinations made by the Primary Network Perspective do not fall within the service regions of at least two (2) distinct Regional Internet Registries. -- *Effective June 15, 2026*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least four (4) remote Network Perspectives. The CA MUST NOT proceed with certificate issuance if the number of non-corroborations is greater than allowed in the Quorum Requirements table and if the remote Network Perspectives that do corroborate the determinations made by the Primary Network Perspective do not fall within the service regions of at least two (2) distinct Regional Internet Registries. -- *Effective December 15, 2026*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least five (5) remote Network Perspectives. The CA MUST NOT proceed with certificate issuance if the number of non-corroborations is greater than allowed in the Quorum Requirements table and if the remote Network Perspectives that do corroborate the determinations made by the Primary Network Perspective do not fall within the service regions of at least two (2) distinct Regional Internet Registries. +- *Effective September 15, 2025*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. +- *Effective March 15, 2026*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least three (3) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. +- *Effective June 15, 2026*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least four (4) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. +- *Effective December 15, 2026*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least five (5) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. ### 3.2.3 Authentication of individual identity @@ -1468,7 +1469,7 @@ No stipulation. ### 4.9.7 CRL issuance frequency -CRLs must be available via a publicly-accessible HTTP URL (i.e., "published"). +CRLs MUST be available via a publicly-accessible HTTP URL (i.e., "published"). Within twenty-four (24) hours of issuing its first Certificate, the CA MUST generate and publish either: - a full and complete CRL; OR @@ -1639,7 +1640,7 @@ Based on the Risk Assessment, the CA SHALL develop, implement, and maintain a se ### 5.2.2 Number of Individuals Required per Task -The CA Private Key SHALL be backed up, stored, and recovered only by personnel in trusted roles using, at least, dual control in a physically secured environment. +The CA Private Key SHALL be backed up, stored, and recovered only by personnel in Trusted Roles using, at least, dual control in a physically secured environment. ### 5.2.3 Identification and authentication for each role @@ -1998,7 +1999,7 @@ The CA MAY perform Linting on the corpus of its unexpired, un-revoked Subscriber ## 7.1 Certificate profile -The CA SHALL meet the technical requirements set forth in [Section 2.2 - Publication of Information](#22-publication-of-information), [Section 6.1.5 - Key Sizes](#615-key-sizes), and [Section 6.1.6 - Public Key Parameters Generation and Quality Checking](#616-public-key-parameters-generation-and-quality-checking). +The CA SHALL meet the technical requirements set forth in [Section 6.1.5 - Key Sizes](#615-key-sizes), and [Section 6.1.6 - Public Key Parameters Generation and Quality Checking](#616-public-key-parameters-generation-and-quality-checking). Prior to 2023-09-15, the CA SHALL issue Certificates in accordance with the profile specified in these Requirements or the profile specified in version 1.8.6 of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Effective 2023-09-15, the CA SHALL issue Certificates in accordance with the profile specified in these Requirements. @@ -2059,7 +2060,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | `basicConstraints` | MUST | Y | See [Section 7.1.2.1.4](#71214-root-ca-basic-constraints) | | `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST NOT | N | - | +| `extKeyUsage` | MUST NOT | - | - | | `certificatePolicies` | NOT RECOMMENDED | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2151,7 +2152,7 @@ Table: Cross-Certified Subordinate CA with Restricted EKU | ---- | - | - | ----- | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.5](#71225-cross-certified-subordinate-ca-extended-key-usage---restricted) | -[^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.13) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. +[^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.12) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. [^name_constraints]: See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) for further requirements, including regarding criticality of this extension. @@ -2586,7 +2587,7 @@ Table: Organization Validated `subject` Attributes | `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.2.1](#3221-identity) | | `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.2.1](#3221-identity) | | `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.2.1](#3221-identity) | -| `postalCode` | NOT RECOMMENDED | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.2.1](#3221-identity)) | +| `postalCode` | NOT RECOMMENDED | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.2.1](#3221-identity) | | `streetAddress` | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. Multiple instances MAY be present.| [Section 3.2.2.1](#3221-identity) | | `organizationName` | MUST | The Subject's name and/or DBA/tradename. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". If both are included, the DBA/tradename SHALL appear first, followed by the Subject's name in parentheses. | [Section 3.2.2.2](#3222-dbatradename) | | `surname` | MUST NOT | - | - | @@ -2745,6 +2746,8 @@ Table: `GeneralName` within a `subjectAltName` extension | `iPAddress` | Y | The entry MUST contain the IPv4 or IPv6 address that the CA has confirmed the Applicant controls or has been granted the right to use through a method specified in [Section 3.2.2.5](#3225-authentication-for-an-ip-address). The entry MUST NOT contain a Reserved IP Address. | | `registeredID` | N | - | +**Note**: As an explicit exception from RFC 5280, P-Labels are permitted to not conform to IDNA 2003. These Requirements allow for the inclusion of P-Labels that do not conform with IDNA 2003 to support newer versions of the Unicode character repertoire, among other improvements to the various IDNA standards. + #### 7.1.2.8 OCSP Responder Certificate Profile If the Issuing CA does not directly sign OCSP responses, it MAY make use of an OCSP Authorized Responder, as defined by [RFC 6960](https://tools.ietf.org/html/rfc6960#section-4.2.2.2). The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for. @@ -3029,13 +3032,13 @@ Table: Policy Restricted | __Field__ | __Presence__ | __Contents__ | | --- | - | ------ | | `policyIdentifier` | MUST | One of the following policy identifiers: | -|     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The CA MUST include at least one Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)) directly or transitively issued by this Certificate. | +|     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The CA MUST include exactly one Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)) directly or transitively issued by this Certificate. | |     `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. | |     Any other identifier | MAY | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | | `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | -This Profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier. +The Policy Restricted profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier. **Note**: policyQualifiers is NOT RECOMMENDED to be present in any Certificate issued under this Certificate Profile because this information increases the size of the Certificate without providing any value to a typical Relying Party, and the information may be obtained by other means when necessary. @@ -3425,7 +3428,7 @@ A full and complete CRL is a CRL whose scope includes all Certificates issued by A partitioned CRL (sometimes referred to as a "sharded CRL") is a CRL with a constrained scope, such as all Certificates issued by the CA during a certain period of time ("temporal sharding"). Aside from the presence of the Issuing Distribution Point extension (OID 2.5.29.28) in partitioned CRLs, both CRL formats are syntactically the same from the perspective of this profile. -Minimally, CAs MUST issue either a "full and complete" CRL or a set of "partitioned" CRLs which cover the complete set of Certificates issued by the CA. In other words, if issuing only partitioned CRLs, the combined scope of those CRLs must be equivalent to that of a full and complete CRL. +Minimally, CAs MUST issue either a "full and complete" CRL or a set of "partitioned" CRLs which cover the complete set of Certificates issued by the CA within 7 days of such CA issuing its first certificate. In other words, if issuing only partitioned CRLs, the combined scope of those CRLs must be equivalent to that of a full and complete CRL. CAs MUST NOT issue indirect CRLs (i.e., the issuer of the CRL is not the issuer of all Certificates that are included in the scope of the CRL). @@ -3533,7 +3536,7 @@ The CA SHALL at all times: 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 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 . 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) 319 411-1 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 . 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 @@ -3550,7 +3553,7 @@ If the CA does not have a currently valid Audit Report indicating compliance wit The CA's audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills: 1. Independence from the subject of the audit; -2. The ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme (see [Section 8.4](#84-topics-covered-by-assessment)); +2. The ability to conduct an audit that addresses the criteria specified in an eligible audit scheme (see [Section 8.4](#84-topics-covered-by-assessment)); 3. Employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function; 4. (For audits conducted in accordance with any one of the ETSI standards) accredited in accordance with ISO 17065 applying the requirements specified in ETSI EN 319 403; 5. (For audits conducted in accordance with the WebTrust standard) licensed by WebTrust; @@ -3580,7 +3583,7 @@ The audit MUST be conducted by a Qualified Auditor, as specified in [Section 8.2 For Delegated Third Parties which are not Enterprise RAs, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in [Section 8.4](#84-topics-covered-by-assessment), that provides an opinion whether the Delegated Third Party's performance complies with either the Delegated Third Party's practice statement or the CA's Certificate Policy and/or Certification Practice Statement. If the opinion is that the Delegated Third Party does not comply, then the CA SHALL not allow the Delegated Third Party to continue performing delegated functions. -The audit period for the Delegated Third Party SHALL NOT exceed one year (ideally aligned with the CA's audit). However, if the CA or Delegated Third Party is under the operation, control, or supervision of a Government Entity and the audit scheme is completed over multiple years, then the annual audit MUST cover at least the core controls that are required to be audited annually by such scheme plus that portion of all non-core controls that are allowed to be conducted less frequently, but in no case may any non-core control be audited less often than once every three years. +The audit period for the Delegated Third Party SHALL NOT exceed one year (ideally aligned with the CA's audit). ## 8.5 Actions taken as a result of deficiency From 9649b6c270bc6881b13a2f539112b9eadd2daa2a Mon Sep 17 00:00:00 2001 From: Wayne Thayer Date: Fri, 28 Feb 2025 16:20:56 -0700 Subject: [PATCH 11/11] Update version --- docs/BR.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 3796c9c70..1b85bcfff 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,11 +1,11 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates -subtitle: Version 2.1.3 +subtitle: Version 2.1.4 author: - CA/Browser Forum -date: 24-February-2025 +date: 27-February-2025 copyright: | Copyright 2025 CA/Browser Forum @@ -147,6 +147,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2.1.1 | SC79 | Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate | 30-Sep-2024 | 14-Nov-2024 | | 2.1.2 | SC80 | Strengthen WHOIS lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15 | 7-Nov-2024 | 16-Dec-2024 | | 2.1.3 | SC83 | Winter 2024-2025 Cleanup Ballot | 23-Jan-2025 | 24-Feb-2025 | +| 2.1.4 | SC84 | DNS Labeled with ACME Account ID Validation Method | 28-Jan-2025 | 27-Feb-2025 | \* Effective Date and Additionally Relevant Compliance Date(s)