<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 6:34 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvZzBc80xm3F_dRt8PgRAc2=W6A-VRxfjXfz43b0ZiDT2w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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>
<br>
<blockquote type="cite"
cite="mid:CACvaWvZzBc80xm3F_dRt8PgRAc2=W6A-VRxfjXfz43b0ZiDT2w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<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>
<br>
<blockquote type="cite"
cite="mid:CACvaWvZzBc80xm3F_dRt8PgRAc2=W6A-VRxfjXfz43b0ZiDT2w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<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>
<br>
<blockquote type="cite"
cite="mid:CACvaWvZzBc80xm3F_dRt8PgRAc2=W6A-VRxfjXfz43b0ZiDT2w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>However, it's still requiring that, even if a distinct
EKU is present, because it's issued from a BR CA, the
certificates the BR CA issues need to be well-formed. </div>
</div>
</div>
</blockquote>
<br>
I support this statement. The certificate that is signed by a Root
subject to the BRs must be well-formed. I was commenting on whether
the NC extension is required or not for a non-TLS issuing CA. If a
CA chooses to add a NC, it should be well-formed according to
RFC5280.<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvZzBc80xm3F_dRt8PgRAc2=W6A-VRxfjXfz43b0ZiDT2w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>That seems to have some concern raised, by Corey, and
that's why we're trying to resolve, by making sure we have a
correct understanding about what the BRs require, so that we
can make sure that the profiles work is properly seen as
strictly relaxing, not adding new restrictions.</div>
</div>
</div>
</blockquote>
<br>
Totally onboard with that which is why I am sharing these thoughts
and past experience on this topic.<br>
<br>
Dimitris.<br>
</body>
</html>