From b42a6c0b8fafcd5845e16ad1279b616e7e2d59d0 Mon Sep 17 00:00:00 2001 From: Rich Smith Date: Tue, 12 May 2026 10:52:51 -0500 Subject: [PATCH 1/5] Moves DNSSEC validation requirements from section 3.2.2.4 and 3.2.2.8 and consolidates them into a new section 3.2.2.10 --- docs/BR.md | 93 ++++++++++++++++++++++++++++++++---------------------- 1 file changed, 55 insertions(+), 38 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 89e0d518..d4980d27 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.2.6 +subtitle: Version 2.2.x author: - CA/Browser Forum -date: 31-March-2026 +date: xx-xx-2026 copyright: | Copyright 2026 CA/Browser Forum @@ -161,6 +161,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2.2.4 | SC096 | Carve-out for DNSSEC verification logging requirements | 2026-01-14 | 2026-02-17 | | 2.2.5 | SC097 | Sunset all remaining use of SHA-1 signatures in Certificates and CRLs | 2026-02-24 | 2026-02-25 | | 2.2.6 | SC095 | Clean-up 2025 | 2026-02-27 | 2026-03-31 | +| 2.2.x | SC100 | DNSSEC Clarification and Consolidation | 2026-XX-XX | 2026-XX-XX | \* Effective Date and Additionally Relevant Compliance Date(s) @@ -178,9 +179,9 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2026-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. | | 2026-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. | | 2026-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT rely on Method 3.2.2.4.8 to issue Subscriber Certificates. | -| 2026-03-15 | [3.2.2.8.1](#32281-dnssec-validation-of-caa-records) | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. | -| 2026-03-15 | [3.2.2.8.1](#32281-dnssec-validation-of-caa-records) | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. | -| 2026-03-15 | [3.2.2.8.1](#32281-dnssec-validation-of-caa-records) | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. | +| 2026-03-15 | [3.2.2.10.2](#322102-applicability-and-scope) | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. | +| 2026-03-15 | [3.2.2.10.4](#322104-prohibition-on-disabling-dnssec-validation) | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. | +| 2026-03-15 | [3.2.2.10.5](#322105-dnssec-validation-errors) | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. | | 2026-03-15 | [4.2.1](#421-performing-identification-and-authentication-functions) | Subject Identity Information validation maximum data reuse period is 398 days. | | 2026-03-15 | [4.2.1](#421-performing-identification-and-authentication-functions) | Domain Name and IP Address validation maximum data reuse period is 200 days. | | 2026-03-15 | [4.2.2](#422-approval-or-rejection-of-certificate-applications) | CAs SHALL NOT issue Certificates containing Domain Names that end in an IP Reverse Zone Suffix. | @@ -740,22 +741,7 @@ The CA SHALL confirm that prior to issuance, the CA has validated each Fully-Qua Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document) prior to Certificate issuance. For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate. -Effective 2026-03-15: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective MUST: - -- perform DNSSEC validation using the algorithm defined in [RFC 4035, Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and -- support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and -- support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and -- properly handle the security concerns enumerated in [RFC 6840, Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). - -Effective 2026-03-15: - -For e-mail Domain Validation methods described in sections 3.2.2.4.4, 3.2.2.4.13, 3.2.2.4.14, DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS CNAME, CAA, TXT queries attempting to obtain the Authorization Domain Name associated with the validation of domain authorization or control by the Primary Network Perspective and CAs MUST NOT use local policy to disable DNSSEC validation. For all other DNS queries, DNSSEC validation back to the IANA DNSSEC root trust anchor SHOULD be performed and CAs SHOULD NOT use local policy to disable DNSSEC validation. - -For all other Domain Validation methods, DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective and CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. - -DNSSEC validation back to the IANA DNSSEC root trust anchor is considered outside the scope of self-audits performed to fulfill the requirements in [Section 8.7](#87-self-audits). - -DNSSEC validation back to the IANA DNSSEC root trust anchor is considered outside the scope of the logging requirements of [Section 5.4.1](#541-types-of-events-recorded). +DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control, and CAA record lookups by the Primary Network Perspective in accordance with [Section 3.2.2.10](#32210-dnssec-validation-requirements). CAs SHALL maintain a record of which domain validation method, including relevant BR version number, they used to validate every domain. @@ -1172,24 +1158,9 @@ CAs are permitted to treat a record lookup failure as permission to issue if: - the lookup has been retried at least once; and - the CA has confirmed that the domain is "Insecure" as defined in [RFC 4035, Section 4.3](https://datatracker.ietf.org/doc/html/rfc4035#section-4.3). -CAs MUST document potential issuances that were prevented by a CAA record in sufficient detail to provide feedback to the CA/Browser Forum on the circumstances, and SHOULD dispatch reports of such issuance requests to the contact(s) stipulated in the CAA iodef record(s), if present. CAs are not expected to support URL schemes in the iodef record other than mailto: or https:. - -##### 3.2.2.8.1 DNSSEC Validation of CAA Records +See also [Section 3.2.2.10](#32210-dnssec-validation-requirements) for DNSSEC validation requirements applicable to CAA record lookups. -Effective 2026-03-15: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with CAA record lookups performed by the Primary Network Perspective MUST: - -- perform DNSSEC validation using the algorithm defined in [RFC 4035, Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and -- support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and -- support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and -- properly handle the security concerns enumerated in [RFC 6840, Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). - -Effective 2026-03-15: CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. - -Effective 2026-03-15: DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. - -DNSSEC validation back to the IANA DNSSEC root trust anchor MAY be performed on all DNS queries associated with CAA record lookups performed by Remote Network Perspectives as part of Multi-Perspective Issuance Corroboration. - -DNSSEC validation back to the IANA DNSSEC root trust anchor is considered outside the scope of self-audits performed to fulfill the requirements in [Section 8.7](#87-self-audits). +CAs MUST document potential issuances that were prevented by a CAA record in sufficient detail to provide feedback to the CA/Browser Forum on the circumstances, and SHOULD dispatch reports of such issuance requests to the contact(s) stipulated in the CAA iodef record(s), if present. CAs are not expected to support URL schemes in the iodef record other than mailto: or https:. #### 3.2.2.9 Multi-Perspective Issuance Corroboration @@ -1270,6 +1241,52 @@ Phased Implementation Timeline: - Effective 2026-12-15, 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.2.10 DNSSEC Validation Requirements + +This section consolidates all DNSSEC validation requirements applicable to DNS queries performed during domain validation ([Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control)) and CAA record processing ([Section 3.2.2.8](#3228-caa-records)). + +##### 3.2.2.10.1 DNS Resolver Requirements + +The DNS resolver used by the Primary Network Perspective for all DNS queries associated with the validation of domain authorization or control and for CAA record lookups MUST: + +- perform DNSSEC validation using the algorithm defined in [RFC 4035, Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and +- support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and +- support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and +- properly handle the security concerns enumerated in [RFC 6840, Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). + +##### 3.2.2.10.2 Applicability and Scope + +DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed by the Primary Network Perspective on all DNS queries associated with: + +1. the validation of domain authorization or control as described in [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control); and +2. CAA record lookups as described in [Section 3.2.2.8](#3228-caa-records). + +##### 3.2.2.10.3 Email Domain Validation Methods - Partial Exception + +For the e-mail-based Domain Validation methods described in sections 3.2.2.4.4, 3.2.2.4.13, and 3.2.2.4.14: + +- DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS CNAME, CAA, and TXT queries performed by the Primary Network Perspective used to obtain the Authorization Domain Name, and CAs MUST NOT use local policy to disable DNSSEC validation on those queries. +- For all other DNS queries associated with these methods performed by the Primary Network Perspective, DNSSEC validation back to the IANA DNSSEC root trust anchor SHOULD be performed and CAs SHOULD NOT use local policy to disable DNSSEC validation. + +##### 3.2.2.10.4 Prohibition on Disabling DNSSEC Validation + +For all Domain Validation methods other than those listed in [Section 3.2.2.10.3](#322103-email-domain-validation-methods---partial-exception), and for all CAA record lookups, CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control or with CAA record lookups performed by the Primary Network Perspective. + +##### 3.2.2.10.5 DNSSEC Validation Errors + +DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. + +##### 3.2.2.10.6 Remote Network Perspectives + +DNSSEC validation back to the IANA DNSSEC root trust anchor MAY be performed on all DNS queries associated with the validation of domain authorization or control and for CAA record lookups performed by Remote Network Perspectives as part of Multi-Perspective Issuance Corroboration. + +##### 3.2.2.10.7 Exclusions + +The full set of DNS lookup information related to DNSSEC validation back to the IANA DNSSEC root trust anchor is considered outside the scope of: + +1. self-audits performed to fulfill the requirements in [Section 8.7](#87-self-audits); and +2. the logging requirements of [Section 5.4.1](#541-types-of-events-recorded). + ### 3.2.3 Authentication of individual identity If an Applicant subject to this [Section 3.2.3](#323-authentication-of-individual-identity) is a natural person, then the CA SHALL verify the Applicant's name, Applicant's address, and the authenticity of the certificate request. From 6eb6b47a0ba9dece01b96dd600da6ac1ce4f709b Mon Sep 17 00:00:00 2001 From: Rich Smith Date: Thu, 14 May 2026 10:19:56 -0500 Subject: [PATCH 2/5] Add pointer to exceptions from 3.2.2.10.3 in 3.2.2.10.5 for clarity. --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index d4980d27..27392c82 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1274,7 +1274,7 @@ For all Domain Validation methods other than those listed in [Section 3.2.2.10.3 ##### 3.2.2.10.5 DNSSEC Validation Errors -DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. +Except as may be allowed for in section 3.2.2.10.3, DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. ##### 3.2.2.10.6 Remote Network Perspectives From 814b7703954968fa502a07090801b4fee2fb68da Mon Sep 17 00:00:00 2001 From: Rich Smith Date: Fri, 26 Jun 2026 12:16:21 -0500 Subject: [PATCH 3/5] Updated in accordance with section changes brought about in SC-098/BR v2.2.8 --- docs/BR.md | 107 +++++++++++++++++++++++------------------------------ 1 file changed, 46 insertions(+), 61 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index ce031d9b..5675289e 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -161,9 +161,9 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2.2.4 | SC096 | Carve-out for DNSSEC verification logging requirements | 2026-01-14 | 2026-02-17 | | 2.2.5 | SC097 | Sunset all remaining use of SHA-1 signatures in Certificates and CRLs | 2026-02-24 | 2026-02-25 | | 2.2.6 | SC095 | Clean-up 2025 | 2026-02-27 | 2026-03-31 | -| 2.2.x | SC100 | DNSSEC Clarification and Consolidation | 2026-XX-XX | 2026-XX-XX | | 2.2.7 | SC099 | Improve Recording of Validation Method | 2026-04-18 | 2026-05-19 | | 2.2.8 | SC098 | Process RFC 8657 CAA Parameters | 2026-05-13 | 2026-06-16 | +| 2.2.x | SC100 | DNSSEC Clarification and Consolidation | 2026-XX-XX | 2026-XX-XX | \* Effective Date and Additionally Relevant Compliance Date(s) @@ -181,9 +181,9 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2026-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. | | 2026-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. | | 2026-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT rely on Method 3.2.2.4.8 to issue Subscriber Certificates. | -| 2026-03-15 | [3.2.2.10.2](#322102-applicability-and-scope) | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. | -| 2026-03-15 | [3.2.2.10.4](#322104-prohibition-on-disabling-dnssec-validation) | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. | -| 2026-03-15 | [3.2.2.10.5](#322105-dnssec-validation-errors) | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. | +| 2026-03-15 | [4.2.2.2.2](#42222-applicability-and-scope) | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. | +| 2026-03-15 | [4.2.2.2.4](#42224-prohibition-on-disabling-dnssec-validation) | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. | +| 2026-03-15 | [4.2.2.2.5](#42225-dnssec-validation-errors) | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. | | 2026-03-15 | [4.2.1](#421-performing-identification-and-authentication-functions) | Subject Identity Information validation maximum data reuse period is 398 days. | | 2026-03-15 | [4.2.1](#421-performing-identification-and-authentication-functions) | Domain Name and IP Address validation maximum data reuse period is 200 days. | | 2026-03-15 | [4.2.2](#422-approval-or-rejection-of-certificate-applications) | CAs SHALL NOT issue Certificates containing Domain Names that end in an IP Reverse Zone Suffix. | @@ -752,7 +752,7 @@ The CA SHALL confirm that prior to issuance, the CA has validated each Fully-Qua Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document) prior to Certificate issuance. For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate. -DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control, and CAA record lookups by the Primary Network Perspective in accordance with [Section 3.2.2.10](#32210-dnssec-validation-requirements). +DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed in accordance with [Section 4.2.2.2](#4222-dnssec-validation-requirements) on all DNS queries associated with the validation of domain authorization or control, and CAA record lookups by the Primary Network Perspective. **Note**: FQDNs may be listed in Subscriber Certificates using `dNSName`s in the `subjectAltName` extension or in Subordinate CA Certificates via `dNSName`s in `permittedSubtrees` within the Name Constraints extension. @@ -1148,7 +1148,7 @@ Refer to [Section 4.2.2.1](#4221-caa-record-processing) for CAA record processin ##### 3.2.2.8.1 DNSSEC Validation of CAA Records -Refer to [Section 4.2.2.1.3](#42213-dnssec-validation-of-caa-records) for DNSSEC validation of CAA record processing requirements. +Refer to [Section 4.2.2.2](#4222-dnssec-validation-requirements) for DNSSEC validation of CAA record processing requirements. #### 3.2.2.9 Multi-Perspective Issuance Corroboration @@ -1229,52 +1229,6 @@ Phased Implementation Timeline: - Effective 2026-12-15, 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.2.10 DNSSEC Validation Requirements - -This section consolidates all DNSSEC validation requirements applicable to DNS queries performed during domain validation ([Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control)) and CAA record processing ([Section 3.2.2.8](#3228-caa-records)). - -##### 3.2.2.10.1 DNS Resolver Requirements - -The DNS resolver used by the Primary Network Perspective for all DNS queries associated with the validation of domain authorization or control and for CAA record lookups MUST: - -- perform DNSSEC validation using the algorithm defined in [RFC 4035, Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and -- support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and -- support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and -- properly handle the security concerns enumerated in [RFC 6840, Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). - -##### 3.2.2.10.2 Applicability and Scope - -DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed by the Primary Network Perspective on all DNS queries associated with: - -1. the validation of domain authorization or control as described in [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control); and -2. CAA record lookups as described in [Section 3.2.2.8](#3228-caa-records). - -##### 3.2.2.10.3 Email Domain Validation Methods - Partial Exception - -For the e-mail-based Domain Validation methods described in sections 3.2.2.4.4, 3.2.2.4.13, and 3.2.2.4.14: - -- DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS CNAME, CAA, and TXT queries performed by the Primary Network Perspective used to obtain the Authorization Domain Name, and CAs MUST NOT use local policy to disable DNSSEC validation on those queries. -- For all other DNS queries associated with these methods performed by the Primary Network Perspective, DNSSEC validation back to the IANA DNSSEC root trust anchor SHOULD be performed and CAs SHOULD NOT use local policy to disable DNSSEC validation. - -##### 3.2.2.10.4 Prohibition on Disabling DNSSEC Validation - -For all Domain Validation methods other than those listed in [Section 3.2.2.10.3](#322103-email-domain-validation-methods---partial-exception), and for all CAA record lookups, CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control or with CAA record lookups performed by the Primary Network Perspective. - -##### 3.2.2.10.5 DNSSEC Validation Errors - -Except as may be allowed for in section 3.2.2.10.3, DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. - -##### 3.2.2.10.6 Remote Network Perspectives - -DNSSEC validation back to the IANA DNSSEC root trust anchor MAY be performed on all DNS queries associated with the validation of domain authorization or control and for CAA record lookups performed by Remote Network Perspectives as part of Multi-Perspective Issuance Corroboration. - -##### 3.2.2.10.7 Exclusions - -The full set of DNS lookup information related to DNSSEC validation back to the IANA DNSSEC root trust anchor is considered outside the scope of: - -1. self-audits performed to fulfill the requirements in [Section 8.7](#87-self-audits); and -2. the logging requirements of [Section 5.4.1](#541-types-of-events-recorded). - ### 3.2.3 Authentication of individual identity If an Applicant subject to this [Section 3.2.3](#323-authentication-of-individual-identity) is a natural person, then the CA SHALL verify the Applicant's name, Applicant's address, and the authenticity of the certificate request. @@ -1395,6 +1349,8 @@ CAs are permitted to treat a record lookup failure as permission to issue if: CAs MUST document potential issuances that were prevented by a CAA record in sufficient detail to provide feedback to the CA/Browser Forum on the circumstances, and SHOULD dispatch reports of such issuance requests to the contact(s) stipulated in the CAA iodef record(s), if present. CAs are not expected to support URL schemes in the iodef record other than mailto: or https:. +DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed in accordance with [Section 4.2.2.2](#4222-dnssec-validation-requirements) on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. + ##### 4.2.2.1.1 CAA Multi-Perspective Issuance Corroboration Some methods relied upon for validating the Applicant's ownership or control of the subject domain(s) (see [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control)) or IP address(es) (see [Section 3.2.2.5](#3225-authentication-for-an-ip-address)) to be listed in a certificate require CAA records to be retrieved and processed from additional remote Network Perspectives before Certificate issuance (see [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration)). To corroborate the Primary Network Perspective, a remote Network Perspective's CAA check response MUST be interpreted as permission to issue, regardless of whether the responses from both Perspectives are byte-for-byte identical. Additionally, a CA MAY consider the response from a remote Network Perspective as corroborating if one or both of the Perspectives experience an acceptable CAA record lookup failure, as defined in [Section 4.2.2.1](#4221-caa-record-processing). @@ -1413,22 +1369,51 @@ In addition, *Effective 2027-03-15*: - If the CA supports domain validation methods that are not registered in the [IANA ACME Validation Methods registry](https://www.iana.org/assignments/acme/acme.xhtml#acme-validation-methods), the CA MUST interpret and process `validationmethods` labels formed by concatenating the string ‘ca-tbr-’ with the BR 3.2.2.4 subsection number, e.g. ‘ca-tbr-7’ represents the DNS method described in TLS BR 3.2.2.4.7. If a CA performs domain validation using a mechanism that can be represented by multiple labels (e.g. 'http-01' and 'ca-tbr-19'), the CA SHOULD accept any of the labels as granting permission to issue. - The canonical representation of validationmethods labels is lowercase letters. However, the CA MAY perform case insensitive matching of labels. If the CA does perform case insensitive matching of labels, this practice MUST be documented in their CP and/or CPS. -##### 4.2.2.1.3 DNSSEC Validation of CAA Records +#### 4.2.2.2 DNSSEC Validation Requirements + +This section consolidates all DNSSEC validation requirements applicable to DNS queries performed during domain validation ([Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control)) and CAA record processing ([Section 3.2.2.8](#3228-caa-records)). + +##### 4.2.2.2.1 DNS Resolver Requirements -DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with CAA record lookups performed by the Primary Network Perspective MUST: +The DNS resolver used by the Primary Network Perspective for all DNS queries associated with the validation of domain authorization or control and for CAA record lookups MUST: -- perform DNSSEC validation using the algorithm defined in [RFC 4035 Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and -- support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and +- perform DNSSEC validation using the algorithm defined in [RFC 4035, Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and +- support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and - support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and -- properly handle the security concerns enumerated in [RFC 6840 Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). +- properly handle the security concerns enumerated in [RFC 6840, Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). + +##### 4.2.2.2.2 Applicability and Scope + +DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed by the Primary Network Perspective on all DNS queries associated with: + +1. the validation of domain authorization or control as described in [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control); and +2. CAA record lookups as described in [Section 4.2.2.1](#4221-caa-record-processing). + +##### 4.2.2.2.3 Email Domain Validation Methods - Partial Exception + +For the e-mail-based Domain Validation methods described in sections 3.2.2.4.4, 3.2.2.4.13, and 3.2.2.4.14: + +- DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS CNAME, CAA, and TXT queries performed by the Primary Network Perspective used to obtain the Authorization Domain Name, and CAs MUST NOT use local policy to disable DNSSEC validation on those queries. +- For all other DNS queries associated with these methods performed by the Primary Network Perspective, DNSSEC validation back to the IANA DNSSEC root trust anchor SHOULD be performed and CAs SHOULD NOT use local policy to disable DNSSEC validation. + +##### 4.2.2.2.4 Prohibition on Disabling DNSSEC Validation -CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. +For all Domain Validation methods other than those listed in [Section 4.2.2.2.3](#42223-email-domain-validation-methods---partial-exception), and for all CAA record lookups, CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control or with CAA record lookups performed by the Primary Network Perspective. -DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. +##### 4.2.2.2.5 DNSSEC Validation Errors -DNSSEC validation back to the IANA DNSSEC root trust anchor MAY be performed on all DNS queries associated with CAA record lookups performed by Remote Network Perspectives as part of Multi-Perspective Issuance Corroboration. +Except as may be allowed for in section 4.2.2.2.3, DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. -DNSSEC validation back to the IANA DNSSEC root trust anchor is considered outside the scope of self-audits performed to fulfill the requirements in [Section 8.7](#87-self-audits). +##### 4.2.2.2.6 Remote Network Perspectives + +DNSSEC validation back to the IANA DNSSEC root trust anchor MAY be performed on all DNS queries associated with the validation of domain authorization or control and for CAA record lookups performed by Remote Network Perspectives as part of Multi-Perspective Issuance Corroboration. + +##### 4.2.2.2.7 Exclusions + +The full set of DNS lookup information related to DNSSEC validation back to the IANA DNSSEC root trust anchor is considered outside the scope of: + +1. self-audits performed to fulfill the requirements in [Section 8.7](#87-self-audits); and +2. the logging requirements of [Section 5.4.1](#541-types-of-events-recorded). ### 4.2.3 Time to process certificate applications From aaeba9fa53b4741129bc5ba05e1ebbab250ebae7 Mon Sep 17 00:00:00 2001 From: Rich Smith Date: Fri, 26 Jun 2026 12:30:00 -0500 Subject: [PATCH 4/5] Fix a couple of section links --- docs/BR.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 5675289e..ae715ab1 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1371,7 +1371,7 @@ In addition, *Effective 2027-03-15*: #### 4.2.2.2 DNSSEC Validation Requirements -This section consolidates all DNSSEC validation requirements applicable to DNS queries performed during domain validation ([Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control)) and CAA record processing ([Section 3.2.2.8](#3228-caa-records)). +This section consolidates all DNSSEC validation requirements applicable to DNS queries performed during domain validation ([Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control)) and CAA record processing ([Section 4.2.2.1](#4221-caa-record-processing)). ##### 4.2.2.2.1 DNS Resolver Requirements @@ -1391,7 +1391,7 @@ DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed by ##### 4.2.2.2.3 Email Domain Validation Methods - Partial Exception -For the e-mail-based Domain Validation methods described in sections 3.2.2.4.4, 3.2.2.4.13, and 3.2.2.4.14: +For the e-mail-based Domain Validation methods described in sections [3.2.2.4.4](#32244-email-to-a-constructed-address), [3.2.2.4.13](#322413-email-to-dns-caa-contact), and [3.2.2.4.14](#322414-email-to-dns-txt-contact): - DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS CNAME, CAA, and TXT queries performed by the Primary Network Perspective used to obtain the Authorization Domain Name, and CAs MUST NOT use local policy to disable DNSSEC validation on those queries. - For all other DNS queries associated with these methods performed by the Primary Network Perspective, DNSSEC validation back to the IANA DNSSEC root trust anchor SHOULD be performed and CAs SHOULD NOT use local policy to disable DNSSEC validation. @@ -1402,7 +1402,7 @@ For all Domain Validation methods other than those listed in [Section 4.2.2.2.3] ##### 4.2.2.2.5 DNSSEC Validation Errors -Except as may be allowed for in section 4.2.2.2.3, DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. +Except as may be allowed for in section [4.2.2.2.3](#42223-email-domain-validation-methods---partial-exception), DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. ##### 4.2.2.2.6 Remote Network Perspectives From b6dd09f33c3ef9a88672332faca3c4cbcb391276 Mon Sep 17 00:00:00 2001 From: Rich Smith Date: Fri, 26 Jun 2026 14:13:07 -0500 Subject: [PATCH 5/5] Eradicate the phrase "back to the IANA DNSSEC root trust anchor," from DNSSEC validation requirement phrasing. Section 4.2.2.2.1 makes it clear that DNSSEC validation must be carried out in conformance with RFC 4035. --- docs/BR.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index ae715ab1..b664204f 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -178,10 +178,10 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2025-03-15 | [3.2.2.9](#3229-multi-perspective-issuance-corroboration) | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. | | 2025-07-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates. | | 2025-12-01 | [5.7.1.2](#5712-mass-revocation-plans) | CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements. | -| 2026-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. | +| 2026-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | DNSSEC validation MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. | | 2026-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. | | 2026-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT rely on Method 3.2.2.4.8 to issue Subscriber Certificates. | -| 2026-03-15 | [4.2.2.2.2](#42222-applicability-and-scope) | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. | +| 2026-03-15 | [4.2.2.2.2](#42222-applicability-and-scope) | DNSSEC validation MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. | | 2026-03-15 | [4.2.2.2.4](#42224-prohibition-on-disabling-dnssec-validation) | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. | | 2026-03-15 | [4.2.2.2.5](#42225-dnssec-validation-errors) | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. | | 2026-03-15 | [4.2.1](#421-performing-identification-and-authentication-functions) | Subject Identity Information validation maximum data reuse period is 398 days. | @@ -752,7 +752,7 @@ The CA SHALL confirm that prior to issuance, the CA has validated each Fully-Qua Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document) prior to Certificate issuance. For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate. -DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed in accordance with [Section 4.2.2.2](#4222-dnssec-validation-requirements) on all DNS queries associated with the validation of domain authorization or control, and CAA record lookups by the Primary Network Perspective. +DNSSEC validation MUST be performed in accordance with [Section 4.2.2.2](#4222-dnssec-validation-requirements) on all DNS queries associated with the validation of domain authorization or control, and CAA record lookups by the Primary Network Perspective. **Note**: FQDNs may be listed in Subscriber Certificates using `dNSName`s in the `subjectAltName` extension or in Subordinate CA Certificates via `dNSName`s in `permittedSubtrees` within the Name Constraints extension. @@ -1349,7 +1349,7 @@ CAs are permitted to treat a record lookup failure as permission to issue if: CAs MUST document potential issuances that were prevented by a CAA record in sufficient detail to provide feedback to the CA/Browser Forum on the circumstances, and SHOULD dispatch reports of such issuance requests to the contact(s) stipulated in the CAA iodef record(s), if present. CAs are not expected to support URL schemes in the iodef record other than mailto: or https:. -DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed in accordance with [Section 4.2.2.2](#4222-dnssec-validation-requirements) on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. +DNSSEC validation MUST be performed in accordance with [Section 4.2.2.2](#4222-dnssec-validation-requirements) on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. ##### 4.2.2.1.1 CAA Multi-Perspective Issuance Corroboration @@ -1384,7 +1384,7 @@ The DNS resolver used by the Primary Network Perspective for all DNS queries ass ##### 4.2.2.2.2 Applicability and Scope -DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed by the Primary Network Perspective on all DNS queries associated with: +DNSSEC validation MUST be performed by the Primary Network Perspective on all DNS queries associated with: 1. the validation of domain authorization or control as described in [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control); and 2. CAA record lookups as described in [Section 4.2.2.1](#4221-caa-record-processing). @@ -1393,8 +1393,8 @@ DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed by For the e-mail-based Domain Validation methods described in sections [3.2.2.4.4](#32244-email-to-a-constructed-address), [3.2.2.4.13](#322413-email-to-dns-caa-contact), and [3.2.2.4.14](#322414-email-to-dns-txt-contact): -- DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS CNAME, CAA, and TXT queries performed by the Primary Network Perspective used to obtain the Authorization Domain Name, and CAs MUST NOT use local policy to disable DNSSEC validation on those queries. -- For all other DNS queries associated with these methods performed by the Primary Network Perspective, DNSSEC validation back to the IANA DNSSEC root trust anchor SHOULD be performed and CAs SHOULD NOT use local policy to disable DNSSEC validation. +- DNSSEC validation MUST be performed on all DNS CNAME, CAA, and TXT queries performed by the Primary Network Perspective used to obtain the Authorization Domain Name, and CAs MUST NOT use local policy to disable DNSSEC validation on those queries. +- For all other DNS queries associated with these methods performed by the Primary Network Perspective, DNSSEC validation SHOULD be performed and CAs SHOULD NOT use local policy to disable DNSSEC validation. ##### 4.2.2.2.4 Prohibition on Disabling DNSSEC Validation @@ -1410,7 +1410,7 @@ DNSSEC validation back to the IANA DNSSEC root trust anchor MAY be performed on ##### 4.2.2.2.7 Exclusions -The full set of DNS lookup information related to DNSSEC validation back to the IANA DNSSEC root trust anchor is considered outside the scope of: +The full set of DNS lookup information related to DNSSEC validation is considered outside the scope of: 1. self-audits performed to fulfill the requirements in [Section 8.7](#87-self-audits); and 2. the logging requirements of [Section 5.4.1](#541-types-of-events-recorded).