<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 1/9/2021 9:20 μ.μ., Ryan Sleevi via
Validation wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0100017ba297a16f-fed6dc99-a256-4c2e-a3ef-74838bb607df-000000@email.amazonses.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">microsoft.com</a>" in for a
certificate, issued to me, without verifying I, the Applicant,
am authorized for "<a href="http://microsoft.com"
moz-do-not-send="true">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"
moz-do-not-send="true">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>
</blockquote>
<br>
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 <span style="color: rgba(0, 0, 0, 0.87);
font-family: Roboto, RobotoDraft, Helvetica, Arial, sans-serif;
font-size: 14px; font-style: normal; font-variant-ligatures:
normal; font-variant-caps: normal; font-weight: 400;
letter-spacing: normal; orphans: 2; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;
text-decoration-thickness: initial; text-decoration-style:
initial; text-decoration-color: initial; display: inline
!important; float: none;">anyExtendedKeyUsage<span> </span></span>or
<span style="color: rgba(0, 0, 0, 0.87); font-family: Roboto,
RobotoDraft, Helvetica, Arial, sans-serif; font-size: 14px;
font-style: normal; font-variant-ligatures: normal;
font-variant-caps: normal; font-weight: 400; letter-spacing:
normal; orphans: 2; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
text-decoration-thickness: initial; text-decoration-style:
initial; text-decoration-color: initial; display: inline
!important; float: none;">id-kp-serverAuth</span>) to be
considered "Technically Constrained", has been clarified at least in
the <a moz-do-not-send="true"
href="https://groups.google.com/g/mozilla.dev.security.policy/c/f5-URPoNarI/m/PVdH28BFAAAJ">Mozilla
Root Program since 2016</a>. It is not required.<br>
<br>
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.<br>
<br>
Dimitris.<br>
<br>
<blockquote type="cite"
cite="mid:0100017ba297a16f-fed6dc99-a256-4c2e-a3ef-74838bb607df-000000@email.amazonses.com"><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Validation mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Validation@cabforum.org">Validation@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/validation">https://lists.cabforum.org/mailman/listinfo/validation</a>
</pre>
</blockquote>
<br>
</body>
</html>