<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 2/9/2021 9:35 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvazve5yLcmywizwGEyTdNfFguKBa1uFMR6ejseA-2KGnA@mail.gmail.com">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> The rest of the section describes requirements for Name
Constraints IF they are required. One can read it as they are
only required "If the Subordinate CA Certificate includes the
id-kp-serverAuth extended key usage" because that is clearly
written in the second paragraph. The intent about NCs is
unclear for subCAs that do not have the id-kp-serverAuth
extended key usage.<br>
</div>
</blockquote>
<div><br>
</div>
<div>It appears you disagree with the #10 - #13 here. You're
saying that this section "only" applies for id-kp-serverAuth.</div>
<div><br>
</div>
<div>This is not how this section reads, but it also means you've
ignored the Section 7.1.2.4 requirements here, as well as those
in Section 1.6.1. Could you explain why you believe it's OK to
ignore these?</div>
</blockquote>
<br>
When you are discussing about 1.6.1 I assume you are referring to
the definition of <br>
<br>
"<strong>Technically Constrained Subordinate CA Certificate</strong>:
A Subordinate CA certificate which uses a combination of Extended
Key Usage settings and Name Constraint settings to limit the scope
within which the Subordinate CA Certificate may issue Subscriber or
additional Subordinate CA Certificates."<br>
<br>
Let me first state that I am not a native English speaker and my
reading could have some obvious errors for which I would hope the
native English speakers will correct :)<br>
<br>
When it comes to <b>Subscriber Certificates</b> the scope of the
BRs are server TLS Certificates. Therefore the definition applies to
"within which<b> the Subordinate CA Certificate may issue Subscriber</b>
or additional Subordinate CA <b>Certificates</b>", which points to
the TLS technically constrained subCAs for which a combination of
EKU AND NC is required, as described in 7.1.5.<br>
<br>
Regarding 7.1.2.4, I'm not sure which part you assume I am ignoring.
Is it the part about RFC 5280 requirements for well-formed fields?<br>
<br>
I read your email in
<a class="moz-txt-link-freetext" href="https://archive.cabforum.org/pipermail/validation/2021-September/001689.html">https://archive.cabforum.org/pipermail/validation/2021-September/001689.html</a><br>
<br>
but the discussion about 7.1.2.4 is probably not so clear to me. I
will try to re-read it and hopefully see your points clearer.<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvazve5yLcmywizwGEyTdNfFguKBa1uFMR6ejseA-2KGnA@mail.gmail.com">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>You will note, for example, that the
profiles work is trying to relax this and
actually allow the EKU-or-NC. </div>
</div>
</div>
</blockquote>
<br>
If the SCWG is looking it from the server TLS point
of view, "technically constrained" should focus on
the technical capabilities of validating a trust
path that would enable a <b>server TLS</b>
end-entity certificate. In the attempt to describe
the profiles for TLS and non-TLS issuing CAs, and as
the certificate profiles work is trying to clarify,
for the first case we should need both EKU
(serverAuth) and NC, while for the non-TLS we should
constrain with just the EKU (must not include
serverAuth or anyEKU).<br>
</div>
</blockquote>
<div><br>
</div>
<div>As mentioned above, that's <b>not</b> reflective
in current Browser members applications behave. This
is why the current language requires the And, and
doesn't say Or. The "id-kp-serverAuth" EE cert from an
"id-kp-emailProtection" will validate in RFC 5280-only
implementations, and, for Apple's case, will validate
in Apple's supported implementations. So yes, it
matters :)</div>
</div>
</div>
</blockquote>
<br>
The IF statement of the second paragraph has a MUST for the NC
extension, only if the keyPurposeId is "id-kp-serverAuth".<br>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, we're not disagreeing here.</div>
<div><br>
</div>
<div>You appear, however, to be taking that "If" clause to also
extend to each subsequent paragraph, despite that being contrary
to the Definition of a Technically Constrained Sub-CA, and
despite the requirements of 7.1.2.4. I don't understand how or
why you're reaching that conclusion, other than saying "Well,
Mozilla did this for their root program", which, again, seems
largely irrelevant for the BR discussion here.</div>
</blockquote>
<br>
I hope my answer gives you some idea how one could come to that
conclusion. <br>
<br>
Dimitris.<br>
</body>
</html>