<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 7:36 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvZiNbz7Tr5fGzsPA72o1OuW1okTCrEH4pjpagrE8OBSmg@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 11:58
AM Dimitris Zacharopoulos (HARICA) <<a
href="mailto:dzacharo@harica.gr" moz-do-not-send="true">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" 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>
</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>
</div>
</div>
</blockquote>
<br>
If a Browser (especially the Mozilla Root Program which is based on
an open community where industry experts and security researchers
contribute) has a certain interpretation of the BRs, this does have
some weight in the industry. The same thing applies when you,
representing Google Chrome, have a certain interpretation of the BRs
that some CAs find ambiguous.<br>
<br>
If I understand correctly, you are arguing that Mozilla is relaxing
a BR rule without doing so in their Root Program Policy and I am
saying that this is one possible interpretation of the current BRs.
Mozilla didn't interpret the BRs like you did and said "we don't
care if you violate that requirement". They didn't see it as a
violation, ever. And so did the auditors of all CAs out there that
have used the same Root hierachy for non-TLS certificates, otherwise
we would have seen audit reports with incidents highlighting that
issue.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvZiNbz7Tr5fGzsPA72o1OuW1okTCrEH4pjpagrE8OBSmg@mail.gmail.com">
<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>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>
<br>
I mentioned the Mozilla communications because we are talking about
industry experts and security researchers who are reading the BRs,
just like everyone else. Their opinion has some weight in the
interpretation of the BRs and CAs often seek clarifications and
interpretations in the m.d.s.p. community.<br>
<br>
Taking the current BRs, in section 7.1.5, reading from the top:<br>
<p>"For a Subordinate CA Certificate to be considered Technically
Constrained, the certificate MUST include an Extended Key Usage
(EKU) extension specifying all extended key usages that the
Subordinate CA Certificate is authorized to issue certificates
for. The <code>anyExtendedKeyUsage</code> KeyPurposeId MUST NOT
appear within this extension."</p>
<p>Let's pick anything but "id-kp-serverAuth". Moving to the next
paragraph:<br>
</p>
<p>"If the Subordinate CA Certificate includes the id-kp-serverAuth
extended key usage, then the Subordinate CA Certificate MUST
include the Name Constraints X.509v3 extension with constraints on
<code>dNSName</code>, <code>iPAddress</code> and <code>DirectoryName</code>
as follows:"</p>
Not applicable because we do not have "id-kp-serverAuth". BTW, the
rendering of a. b. c. under that paragraph doesn't render properly
on GitHub Markdown flavor :)<br>
<br>
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>
<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvZiNbz7Tr5fGzsPA72o1OuW1okTCrEH4pjpagrE8OBSmg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</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>
<br>
Like I said already, the current language seems to have different
interpretations and we should clarify it. Was it ever the intent to
include both EKU and NC in all cases of EKU? It would be a very easy
thing to write had that been the intent from Browser members. CAs
could easily follow. If these arguments were discussed when 7.1.5
was drafted, it should be in the archives.<br>
<br>
<br>
</body>
</html>