<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 2, 2021 at 11:58 AM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> wrote:<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>
<br>
<br>
<div>On 2/9/2021 6:34 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Sep 2, 2021 at 4:41
AM Dimitris Zacharopoulos (HARICA) via Validation <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>>
wrote:</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> 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;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">id-kp-serverAuth</span>)
to be considered "Technically Constrained", has been
clarified at least in the <a href="https://groups.google.com/g/mozilla.dev.security.policy/c/f5-URPoNarI/m/PVdH28BFAAAJ" target="_blank">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>
</div>
</blockquote>
<div><br>
</div>
<div>I'm not sure I understand your reply here.</div>
<div><br>
Are you trying to say that CAs are free to ignore the BRs if
one root program says so?</div>
</div>
</div>
</blockquote>
<br>
No. I am saying that it's a reasonable interpretation of the current
BRs and that a subCA that contains an EKU without id-kp-serverAuth
or anyEKU should be considered technically constrained because it
cannot create a valid TLS end-entity certificate. Or, put
differently, even if a TLS end-entity certificate is issued, it
should not validate successfully because of the EKU chaining
restrictions.<br></div></blockquote><div><br></div><div>I fail to see how you can say that "Because one program said something", that it's fine to reinterpret the BRs according to that.</div><div><br></div><div>Apple doesn't implement EKU chaining, and so the BR requirement makes sense given Apple's implementation. I really must push back on this, because I want to make sure that CAs aren't arguing that a given program can _loosen_ the BRs arbitrarily. They may choose to ignore a violation for their own program, as is their prerogative, and we absolutely see programs put more stringent requirements in their programs than the BRs, but I don't believe we can say that "Mozilla said it was OK, so now it's OK for everyone" is somehow acceptable.</div><div> </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">
<div>I can understand wanting to talk about what the _future_
requirements should say, but I think the context of what the
_current_ requirements require is relevant here, since the
concern is the profiles expressing that requirement.</div>
</div>
</div>
</blockquote>
<br>
I am talking about the current requirements.<br></div></blockquote><div><br></div><div>OK, then you need to support your argument with the current BRs, and not one Root Program.</div><div> </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">
<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>