[cabf_validation] nameConstraints on technically constrained sub-CAs
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Thu Sep 2 08:41:11 UTC 2021
On 1/9/2021 9:20 μ.μ., Ryan Sleevi via Validation wrote:
> 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
> 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,
> 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 184.108.40.206.
> 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 220.127.116.11, 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 18.104.22.168/22.214.171.124
> 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 126.96.36.199.
> At the core, the question seems to be whether 188.8.131.52 applies to _all_
> extensions (including those specified in 184.108.40.206/.2/.3
> <http://220.127.116.11/.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 18.104.22.168 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 22.214.171.124 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 <http://microsoft.com>" in for a
> certificate, issued to me, without verifying I, the Applicant, am
> authorized for "microsoft.com <http://microsoft.com>"?
> If 126.96.36.199 applies to all extensions/fields, then the answer is "No" -
> because this would violate 188.8.131.52 (a)(ii) and 184.108.40.206 (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 220.127.116.11 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 18.104.22.168 (f) clearly applies to the "id-kp-sleeviAuth"
> subCA (as shown by 22.214.171.124 (g) clearly placing requirements on not-TLS
> CAs still having to conform to 126.96.36.199), because 188.8.131.52 (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_ 184.108.40.206.
> 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
> 220.127.116.11 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_
> * 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. 18.104.22.168 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.
> 22.214.171.124 does apply, in particular, 126.96.36.199(a)(ii) and 188.8.131.52(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 184.108.40.206 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.
Whether NC is REQUIRED or not for a non-TLS subCA (a Certificate with
basicConstraints cA:true and EKU extension with KeyPurposeID that DOES
NOT include anyExtendedKeyUsageor id-kp-serverAuth) to be considered
"Technically Constrained", has been clarified at least in the Mozilla
Root Program since 2016
It is not required.
In fact, HARICA was reading 7.1.5 in the very strict way that Ryan is
suggesting, and our first Technically Constrained subCAs, even those
that only had the KeyPurposeId of id-kp-emailProtection, ALSO had a NC
extension with denied subtrees for dNSName and IPAddress values. After
discussions with the Mozilla Root store Managers, it was determined that
it was not necessary to add the NC if the subCA had an EKU extension and
did not have the id-kp-serverAuth or the anyEKU KeyPurposeId for them to
be considered Technically Constrained.
> Validation mailing list
> Validation at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Validation