Baseline Requirements: nameConstraints definition is ambiguous

[sleevi]

Version 1.6.7 defines the nameConstraints within Section 7.1.5, and states

(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the Applicant has registered the dNSName or has been authorized by the domain registrant to act on the registrant's behalf in line with the verification practices of section 3.2.2.4.
(b) For each iPAddress range in permittedSubtrees, the CA MUST confirm that the Applicant has been assigned the iPAddress range or has been authorized by the assigner to act on the assignee's behalf.

Issue 1: Ambiguous parsing of dNSName requirements

The existence of the "or" clause leaves it ambiguous whether the trailing clause applies to both conditions, or only the second condition. That is, it can be read as:

(registered the dNSName) OR (has been authorized by the domain registrant to act on the registrant's behalf in line with the verification practices of Section 3.2.2.4)

or it can be read as

(registered the dNSName OR has been authorized by the domain name registrant to act on the registrant's behalf) in line with the verification practices of Section 3.2.2.4

The latter reading is, I believe, the intended reading, and is certainly the intended expectation. However, as structured, this is not entirely clear to readers.

Issue 2: Ambiguous whether Reserved IP Address or Internal Names are permitted

The prohibition on Internal Names comes within Section 7.1.4.2.1, which is for the Subject Alternative Name Extension. This includes the explicit statement:

CAs SHALL NOT issue certificates with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name.

However, this does not clearly prohibit a nameConstraints extension with such a Reserved IP Address or Internal Name.

This is implicit in the existing requirements and definition.

• For domain names, "registered the dNSName" requires the name is registrable, and thus delegated, and thus not an Internal Name.
• For IP addresses, "assigned the iPAddress" requires the address is assignable, and thus delegated to a Regional Internet Registry, and thus not within the Reserved IP address space.

However, this can and should be made more explicit. Given that it's already odd that 7.1.4.2.1, which applies to the SAN, is placing a constraint on the commonName, it likely makes more sense to lift the prohibition on Internal Names and Reserved IP Addresses to a common validation section, such as Section 3.2.2.4 and Section 3.2.2.5, so that it's explicit that these addresses cannot be validated as required. It then becomes possible to reference these sections within the Certificate Profile as part of the validation requirements.

[barrini]

F2F 60 decision to assign to Clint for review

[barrini]

Still ongoing