[cabf_validation] nameConstraints on technically constrained sub-CAs

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 
> https://github.com/sleevi/cabforum-docs/pull/36#discussion_r690338670 
> <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 
> <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
>     <http://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 
> <http://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 <http://microsoft.com>" in for a 
> certificate, issued to me, without verifying I, the Applicant, am 
> authorized for "microsoft.com <http://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 
> <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.

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 
<https://groups.google.com/g/mozilla.dev.security.policy/c/f5-URPoNarI/m/PVdH28BFAAAJ>. 
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.

Dimitris.

>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/validation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210902/d0fa9647/attachment-0001.html>