[cabf_validation] nameConstraints on technically constrained sub-CAs

Ryan Sleevi sleevi at google.com
Wed Sep 1 18:20:02 UTC 2021


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.

The discussion to date is at
https://github.com/sleevi/cabforum-docs/pull/36#discussion_r690338670

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.

In the BRs today, our existing requirements on nameConstraints are
primarily concentrated in Section 7.1.5,
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf#page=83

The requirements broken down by 7.1.5 paragraphs are:

   1. P1: A technically constrained sub-CA must include an EKU
   2. P1: A technically-constrained sub-CA must only specify EKUs that the
   sub-CAs is authorized for.
   3. P1: A technically-constrained sub-CA must not contain anyEKU
   4. P2: If id-kp-serverAuth is present, dNSName nameConstraints must be
   present.
   5. P2: If id-kp-serverAuth is present, iPAddress nameConstraints must be
   present.
   6. P2: If id-kp-serverAuth is present, directoryName must be present.
   7. 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.
   8. 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)
   9. 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 7.1.2.4/7.1.2.5
   10. P4: If _any_ subCA is prohibited from issuing IP addresses, then the
   full range must be specified in the excludedSubtrees.
   11. 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.
   12. P5: If _any_ sub-CA is prohibited from issuing DNS names, then the
   full range must be specified in the excluded subtrees.
   13. 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.

However, we have _additional_ requirements that come from 7.1.2.4.

At the core, the question seems to be whether 7.1.2.4 applies to _all_
extensions (including those specified in 7.1.2.1/.2/.3), or whether it only
applies to those not explicitly specified. This is, as it so frequently is,
a question about:

   - 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.
   - 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.

Why this matters:

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.

For example, imagine id-kp-sleeviAuth. Can I put a dNSName nameConstraint
of "microsoft.com" in for a certificate, issued to me, without verifying I,
the Applicant, am authorized for "microsoft.com"?

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.

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.

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.

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 https://github.com/cabforum/servercert/issues/314 ).
That's because technically constrained, today, is specified as both EKU
_and_ nameConstraints.

   - Does the emailProtection sub-CA need to have an IPAddress exclusion?
   (#10 and #11 on the above requirements)
   - Does the emailProtection sub-CA need to have a dNSName exclusion? (#12
   and #13 on the above requirements)
   - 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))

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?

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).

I don't agree with that conclusion, but this seems important to resolve
sooner than later, and with broader (list) discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210901/6781f81a/attachment.html>


More information about the Validation mailing list