<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 2:19 PM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</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>
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></div></blockquote><div><br></div><div>Again, I'm asking you to support your interpretation with the BRs.</div><div><br></div><div>You're basically saying "Mozilla didn't get upset at us", and you're not referencing any of the BRs or the subsequent discussions.</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>
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.
</div></blockquote><div><br></div><div>You're not actually arguing that though, as that would imply you've given some evidence to support your conclusion. You haven't addressed any of the substance, you've just said "Well, no, Mozilla said so". I realize this might seem very direct, but I think it's absolutely critical that if you're going to argue something is a valid interpretation of the BRs, you at least need to show your work.</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> 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></div></blockquote><div><br></div><div>I'm sorry, is this the "Well, our auditor didn't say anything, so this must not be a violation"?</div><div><br></div><div>Again, show your work :)</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>
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></div></blockquote><div><br></div><div>It has relevance to Mozilla's program, but we're talking about the BRs.</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>
Taking the current BRs, in section 7.1.5, reading from the top:<br></div></blockquote><div><br></div><div>Let's refer back to the original message: <a href="https://archive.cabforum.org/pipermail/validation/2021-September/001689.html">https://archive.cabforum.org/pipermail/validation/2021-September/001689.html</a> , so you can make it clear which point you disagree with.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<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></div></blockquote><div>Yes. This is #1, #2, and #3.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<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></div></blockquote><div><br></div><div>Yes, this is #7 - #9, which we agree with.</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>
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><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></div></div>