SC-100: DNSSEC Clarification and Consolidation#667
Conversation
… and consolidates them into a new section 3.2.2.10
|
|
||
| - 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 |
There was a problem hiding this comment.
Going to move all of this to 4.2.2.2 after SC-098 is out of IPR review. Additional changes will be needed in order to align with the new structure created by that ballot.
|
|
||
| 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. |
There was a problem hiding this comment.
do you need to add MX records for validation?
There was a problem hiding this comment.
No. The carve-out in this section making other sorts of queries SHOULD rather than MUST was specifically aimed at not requiring DNSSEC validation before sending an email.
| 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 |
There was a problem hiding this comment.
BCP around nsec3 parameters - https://datatracker.ietf.org/doc/rfc9276/
There was a problem hiding this comment.
As this ballot is designed to simply clean up and consolidate the existing language, I have chosen not to add language around the new RFC, as doing so may considerably change the requirements, depending upon the language in the RFC. A ballot which incorporates new RFC requirements into the BR requires significantly more care, review and discussion than a ballot which is primarily moving existing requirements around and tweaking some language a bit for clarity.
richardwsmith
left a comment
richardwsmith
left a comment
There was a problem hiding this comment.
This line is clunky and needs some wordsmithing
|
|
||
| ##### 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. |
richardwsmith
left a comment
richardwsmith
left a comment
There was a problem hiding this comment.
PR has been updated to align with section changes brought about by the incorporation of SC-098 in BR v2.2.8
…m 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.
2 participants
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