<div dir="ltr">On GitHub, Corey and I have been discussing the nameConstraints for technically constrained sub-CAs, and I suggested that we bring this discussion to the list.<div><br></div><div>The discussion to date is at <a href="https://github.com/sleevi/cabforum-docs/pull/36#discussion_r690338670">https://github.com/sleevi/cabforum-docs/pull/36#discussion_r690338670</a></div><div><br></div><div>The context here is that the Certificate Profiles attempts to express our existing requirements on nameConstraints in a way that is unambiguous. In the course of discussing this, Corey raised concerns that would appear to suggest that this is a misrepresentation of our current requirements. Without wanting to put words into Corey's mouth (please, read the discussion), I wanted to provide context and understanding about our current requirements for nameConstraints.</div><div><br></div><div>In the BRs today, our existing requirements on nameConstraints are primarily concentrated in Section 7.1.5, <a href="https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf#page=83">https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf#page=83</a></div><div><br></div><div>The requirements broken down by 7.1.5 paragraphs are:</div><div><ol><li>P1: A technically constrained sub-CA must include an EKU</li><li>P1: A technically-constrained sub-CA must only specify EKUs that the sub-CAs is authorized for.</li><li>P1: A technically-constrained sub-CA must not contain anyEKU</li><li>P2: If id-kp-serverAuth is present, dNSName nameConstraints must be present.</li><li>P2: If id-kp-serverAuth is present, iPAddress nameConstraints must be present.</li><li>P2: If id-kp-serverAuth is present, directoryName must be present.</li><li>P3(a): (If id-kp-serverAuth is present, from P2), the CA must validate each dNSName in the permitted subtrees according to 3.2.2.4.</li><li>P3(b): (If id-kp-serverAuth is present, from P2), the CA must validate each IP address in the permitted subtrees (implicit: in line with 3.2.2.5, but not explicitly stated)</li><li>P3(c): (If id-kp-serverAuth is present, from P3), the CA MUST validate each DN in the permitted subtrees such that certificates containing that DN will be in according to <a href="http://7.1.2.4/7.1.2.5">7.1.2.4/7.1.2.5</a></li><li>P4: If _any_ subCA is prohibited from issuing IP addresses, then the full range must be specified in the excludedSubtrees.</li><li>P4. If _any_ sub-CA is _not_ prohibited from issuing IP addresses, and it contains nameConstraints, it must specify at least one IP address in permitted subtrees.</li><li>P5: If _any_ sub-CA is prohibited from issuing DNS names, then the full range must be specified in the excluded subtrees.</li><li>P5. If _any_ sub-CA is _not_ prohibited from issuing DNS names, and it contains nameConstraints, it must specify at least one DNS name in permitted subtrees.</li></ol><div>However, we have _additional_ requirements that come from 7.1.2.4.</div><div><br></div><div>At the core, the question seems to be whether 7.1.2.4 applies to _all_ extensions (including those specified in <a href="http://7.1.2.1/.2/.3">7.1.2.1/.2/.3</a>), or whether it only applies to those not explicitly specified. This is, as it so frequently is, a question about:</div></div><div><ul><li>Whether the second sentence ("The CA SHALL NOT ...") is a restatement of the first sentence ("All other fields"), or whether it's a separate requirement.</li><li>Whether the second sentence should be read as ("Certificate extension ... not specified in") - that is, that "not specified in" refers to all four values enumerated, and thus 7.1.2.4 doesn't apply to any specified fields/values - or whether it should be read as ("(Certificate Extension) or (other data not specified in ...)") - that "not specified in" refers specifically to "other data", and that 7.1.2.4 applies to all certificate contents.</li></ul><div>Why this matters:</div></div><div><br></div><div>At question here is whether a certificate with a non-TLS EKU, issued from a TLS CA, can contain arbitrary values within the permittedSubtrees nameConstraints extension, without being a violation of the BRs.</div><div><br></div><div>For example, imagine id-kp-sleeviAuth. Can I put a dNSName nameConstraint of "<a href="http://microsoft.com">microsoft.com</a>" in for a certificate, issued to me, without verifying I, the Applicant, am authorized for "<a href="http://microsoft.com">microsoft.com</a>"?</div><div><br></div><div>If 7.1.2.4 applies to all extensions/fields, then the answer is "No" - because this would violate 7.1.2.4 (a)(ii) and 7.1.2.4 (b) - namely, it's information that would mislead relying parties about the information the CA validated, and it's information that applies in a private context (judging by the EKU), but that that the Applicant hasn't demonstrated the right to assert publicly.</div><div><br></div><div>If 7.1.2.4 does not apply, then it's OK to issue that certificate. It would equally be OK to issue a certificate with a DNS nameConstraint of "@#$)()" (i.e. an invalid DNS name). The argument for this is that even though 7.1.2.2 (f) clearly applies to the "id-kp-sleeviAuth" subCA (as shown by 7.1.2.2 (g) clearly placing requirements on not-TLS CAs still having to conform to 7.1.2.2), because 7.1.2.2 (f) references 7.1.5, and because 7.1.5 only specifies rules for permittedSubtrees in certificates with id-kp-serverAuth (#7 - #9 in the above list), then for any other certificate EKU, CAs can put in any arbitrary value or field, _despite_ 7.1.2.4.</div><div><br></div><div>The discussion also argues that a permittedSubtree dNSName of "@#$)()" is not an RFC 5280 violation, but beyond thinking that argument has no merit, I also don't believe it's relevant unless/until we sort out the 7.1.2.4 requirement.</div><div><br></div><div>This matters for thinking about the interaction between the SCWG BRs and any SMCWG work product. If you have a Root CA subject to the BRs, and it issues a sub-CA that contains an id-kp-emailProtection EKU (only), then under the current definition of the BRs, it is _not_ technically constrained (This is <a href="https://github.com/cabforum/servercert/issues/314">https://github.com/cabforum/servercert/issues/314</a> ). That's because technically constrained, today, is specified as both EKU _and_ nameConstraints.</div><div><ul><li>Does the emailProtection sub-CA need to have an IPAddress exclusion? (#10 and #11 on the above requirements)</li><li>Does the emailProtection sub-CA need to have a dNSName exclusion? (#12 and #13 on the above requirements)</li><li>Can the emailProtection sub-CA contain any value it wants for other nameConstraints, such as rfc822Name? (i.e. 7.1.2.4 doesn't apply) Or is the issuance _of_ the Sub-CA (not what the sub-CA issues, but what the root issues) subject to the BRs, and thus the issuing CA still has to perform some form of validation? (i.e. 7.1.2.4 does apply, in particular, 7.1.2.4(a)(ii) and 7.1.2.4(b))</li></ul><div>Concretely: If a BR-compliant Root CA issues a sub-CA, with an EKU of id-kp-emailProtection, and an rfc822Name constraint of "@#$*(.com", is that a BR violation or not?</div></div><div><br></div><div>It would appear that Corey is suggesting it would not be a BR violation, because RFC 5280, Section 4.2.1.10 does explicitly specify the syntax of the rfc822Name nameConstraint, other than saying it contains a "MAY specify a particular mailbox, all addresses at a particular host, or all mailboxes in a domain", and so that requirement should be read as no restriction at all on the syntax of the field (both because it's a MAY, and because it doesn't say "preferred name syntax" or other form of ABNF).</div><div><br></div><div>I don't agree with that conclusion, but this seems important to resolve sooner than later, and with broader (list) discussion.<br></div></div>