<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 8, 2021 at 1:01 PM 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>
<div>On 2/9/2021 10:46 μ.μ., 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 3:12
PM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr" target="_blank">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> 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>
</div>
</blockquote>
<div><br>
</div>
<div>Thanks for clarifying your interpretation. This would
seem to suggest that you support the following conclusions:</div>
<div>
<ul>
<li>If I issue a certificate with
basicConstraints=CA:false, and id-kp-emailProtection</li>
<ul>
<li>It must comply with RFC 5280 (because 7.1.2.4
applies to ALL Certificates)</li>
<li>You would assert that this is a "Certificate, but
not a Subscriber Certificate, nor a CA Certificate" -
is that a correct understanding of how you sort the
definitions?</li>
</ul>
</ul>
</div>
</div>
</div>
</blockquote>
<br>
This certificate would be issued by a non-TLS subCA so I don't think
your interpretation is correct. The product of that issuance is out
of BRs scope. In my understanding, when the BRs mention "Subscriber
Certificates", these are TLS end-entity Certificates.<br></div></blockquote><div><br></div><div>I think you're conflating two things here, but I think I can understand.</div><div><br></div><div>I tried to use the term "Certificate" here, because that's the term 7.1.2.4 used. I can understand you reiterating that you believe "Subscriber Certificate" is only that which contains id-kp-serverAuth or (according to the BRs) id-kp-clientAuth. I'm asking what do you call the thing-that-is-issued that contains id-kp-emailProtection? 7.1.2.4 seems to be consistent that this is a "Certificate" - do you disagree?</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">
<div>
<ul>
<li>If I issue a certificate with
basicConstraints=CA:true, and id-kp-emailProtection</li>
<ul>
<li>This certificate is a Subordinate CA Certificate,
subject to 7.1.2.2. This should be obvious by
7.1.2.2(g) explicitly applying to such certificates,
as well as the explicit language in Section 8.1</li>
<li>Because this Certificate is Subject to 7.1.2.2, it's
also subject to 7.1.5, because of 7.1.2.2(h)</li>
</ul>
</ul>
</div>
</div>
</div>
</blockquote>
<br>
You probably mean 7.1.2.2(g), yes we are in agreement.<br></div></blockquote><div><br></div><div>No, I meant (h). My point of highlighting (h) is that it's very clear that the scope of the BRs _also_ includes, today, "Subordinate CA certificates that are not used to issue TLS certificates". It's the last paragraph of (h).</div><div><br></div><div>Because (h) is clear that it applies to sub-CAs not used to issue TLS certificates, my point (where we seem to agree) is that 7.1.2.2(g) <i>also</i> applies to "Subordinate CA Certificates that are <b>not used to issue TLS certificates</b>".</div><div><br></div><div>Hopefully we also agree that 7.1.2.4 also applies to these?</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>
<ul>
<ul>
<li>This certificate is also subject to 7.1.2.4, because
it is a "Subordinate CA Certificate" (because of
Section 8.1, as well as the definition of Subordinate
CA in Section 1.6.1)</li>
</ul>
</ul>
</div>
</div>
</div>
</blockquote>
<br>
I think you are strangely interpreting 8.1 and extending it for
non-TLS subCAs and what those non-TLS subCAs produce. </div></blockquote><div><br></div><div>I think the overlooking of 7.1.2.2(h) may explain this confusion.</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>My
understanding is that 8.1 invokes the technical restrictions of
7.1.5 and mandates self-audits per section 8.7 only for TLS subCAs.
It doesn't make any sense for the BRs to require self-audits for a
non-TLS subCA that is technically restricted by not having the
id-kp-serverAuth EKU, that signs -say- Time-Stamping or Code Signing
Certificates.<br></div></blockquote><div><br></div><div>It does, if we say 7.1.2.2(h) applies, and that 7.1.2.4 applies.</div><div><br></div><div>7.1.2.4 states the scope is <b>All Certificates</b>. It appears you're treating this narrowly, as "<b>All certificates that can issue or be used as Subscriber certificates"</b>, but that's not what it says. Such an interpretation also wouldn't be consistent with 7.1.2.2(h) (again, not (g)).</div><div><br></div><div>Equally, Section 8.1 seems 100% unambiguous what the scope is. It specifically defines what "capable of being used to issue new certificates" as, and it seems you're reading additional restrictions that are not stated.</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>
<div>Here's where things get messy: A certificate with
basicConstraints=CA:true and id-kp-emailProtection is a CA
Certificate that "within which the Subordinate CA
Certificate <b>may issue</b> Subscriber or <b>additional
Subordinate CA Certificates</b>". That is, because this
sub-CA can further issue additional subject CAs, it's a
Subordinate CA that is in scope of 7.1.2.2, and 7.1.2.4,
and thus, it is <i><b>not</b></i> Technically Constrained
unless it has both "a combination of Extended Key Usage
settings <b>and</b> Name Constraint settings".</div>
<div><br>
</div>
<div>Do you see how that conclusion is reached, even if what
the Subordinate CA issues aren't TLS certificates?</div>
</div>
</div>
</div>
</blockquote>
<br>
I don't, because the BRs assume that the EKU is an effective
technical measure for trust-building so if a second-level subCA has
id-kp-emailProtection and issues a subordinate that has
id-kp-serverAuth, the produced end-entity certificates out of that
last subCA should not be trusted because it would be blocked by the
first subCA issued by the Root which is the Trust Anchor.<br></div></blockquote><div><br></div><div>No, the BRs don't assume this, nor do Root Programs, most notably, Apple's, not when it comes to Root Program compliance. I'm saying there's no text in the BRs to support this interpretation of id-kp-emailProtection sub-CAs being the cut-off point.</div><div><br></div><div>I am trying to <i>introduce</i> such language in the BRs, which is strictly relaxing the requirements, but that's not the current requirement. Corey raised the concern that he believed I was <i>introducing</i> new stricter requirements, and I'm trying to point out how our existing BRs are _more_ strict than the profiles work, or understand what language folks currently believe the BRs to carve things out, to make sure we address it.</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>Yes. The context here, to make sure it's clear, is the
suggestion that if a subordinate CA has an
"id-kp-emailProtection", the BRs don't apply to it
(hopefully it's clear they do, re: 7.1.2.4 and 7.1.2.2(h))
and that it would be a change in existing requirements to
say the BRs do apply, and that the fields must be
well-formed. </div>
<div><br>
</div>
</div>
</div>
</blockquote>
<br>
Again, you probably mean 7.1.2.2(g).<br></div></blockquote><div><br></div><div>Again, I don't :) You know me, I try to be very explicit and precise, especially in these disagreements :)</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'm trying to highlight that:</div>
<div>
<ul>
<li>The BRs currently place rules on <i>all</i> Certificates
issued by a BR compliant CA (7.1.2.4)</li>
<li>The rules in 7.1.2.2 currently apply to <i>all</i> Subordinate
CA certificates (as evidenced by 7.1.2.2(h)), regardless
of EKU</li>
<li>That, regardless of EKU, as it stands today in the
BRs, a sub-CA is not technically constrained unless it
has both EKU and nameConstraints</li>
<ul>
<li>This is because a sub-CA can <i>always</i> issue
more sub-CAs. If pathLenConstraint isn't present, or
is greater than zero, then they can issue <i>any</i> type
of sub-CA. If pathLenConstraint is present, and is
zero, they can still issue self-issued sub-CAs, which
are still sub-CAs.</li>
</ul>
</ul>
<div>The question/concern raised by Corey is whether or not
the BRs can/should have an opinion about what the contents
of a dNSName nameConstraint should contain for a
certificate that only has id-kp-emailProtection. My belief
is the BRs today already express an opinion, but not
clearly, and the profiles work is just trying to clarify
the existing requirements. It would appear Corey (and
again, not trying to misrepresent, so much as capture what
I understand) is suggesting that the BRs do not have an
opinion today (that 7.1.2.4 doesn't apply, nor do the
latter two paragraphs of 7.1.5, nor the definition in
1.6.1), and thus, expressing an opinion is a new, more
restrictive requirement.</div>
</div>
</div>
</div>
</blockquote>
<br>
I mostly agree with Corey on this. My interpretation of the BRs is
that they apply to the Issuer. The Issuer is audited for the things
it signs. If the Root is subject to the BRs, then the product of
that Root, whether it is a TLS subCA or a non-TLS subCA should be in
scope (invoking 7.1.2.2g, 7.1.2.4, 7.1.5, 8.1 for the Root as the
Issuer). This means that even non-TLS subCA Certificates must be
well-formed, must adhere to RFC 5280 rules. My interpretation (and
probably the interpretation of Mozilla) of section 7.1.5 is that it
allows for a Root to issue a Technically Constrained non-TLS subCA
without requiring a NC extension.</div></blockquote><div><br></div><div>Mozilla allows this. The BRs don't.</div><div><br></div><div>Where I think we are in agreement is that if, today, the BRs apply to the Issuer, then they apply to everything they sign. </div><div><ul><li>If a TLS capable CA signs a non-TLS sub-CA, then, today, that non-TLS sub-CA is unambiguously subject to 7.1.2.4 in now that non-TLS sub-CA is formed. Do you agree with this?</li><li>That non-TLS sub-CA is _also_ subject to 8.1 of the BRs. This language is very explicit.</li></ul></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
Once the non-TLS subCA has been issued, whatever actions that
non-TLS subCA does as an Issuer, is out of BRs scope. </div></blockquote><div><br></div><div>Not today. 8.1 is quite clear on that. Similarly, if we agree that 7.1.2.2(h) applies to this non-TLS sub-CA, then we have to agree that 7.1.2.4 applies _at least_ to the profile of this non-TLS sub-CA.</div><div><br></div><div>It seems you're arguing that 7.1.2.4 doesn't apply to anything that non-TLS sub-CA issues. I don't think the language in 7.1.2.4 currently supports that conclusion, but I'm hoping you can provide reference to the BRs where/why this is. This is where the distinction of "Certificates" vs "Subscriber Certificates" was coming in - it seems that you're saying that what a non-TLS sub-CA issues isn't a Certificate, but that would conflict with Section 8.1. It seems further you're saying 8.1 doesn't apply to those non-TLS sub-CAs, but the language in 8.1 seems very clear it does.</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 also agree and realize that the BRs are silent about the non-TLS
CA certificate profile but section 7.1.2.2 seems reasonable to me
for non-TLS CA Certificates. It would be nice to clarify these
non-TLS CA profiles in the profiles ballot and CAs could check their
non-TLS CA profiles chained to the same TLS hierarchies to report
possible conflicts. However, we must be sensitive to the fact that,
for better or worse, there are still mixed hierarchies in use out
there, that are used in non-TLS Internet use cases.<br></div></blockquote><div><br></div><div>Right, to recap the discussion:</div><div><br></div><div>Similar to OCSP responder profile (which is already part of the profiles work, and seemed uncontroversial), there is language about what a non-TLS sub-CA looks like. This language is derived from the requirements of 7.1.2.2(h), 7.1.2.2(g), and 7.1.2.4 of the BRs today (and 7.1.5, which is referenced by 7.1.2.2(h)). Specifically, for non-TLS sub-CAs, it requires that dNS and iPAddress nameConstraints be "well-formed" values (i.e. actual domain names or IP addresses). It further requires that if the non-TLS sub-CA will not issue TLS certificates, then these fields are part of the excludedSubtrees, consistent with the existing 7.1.5 language.</div><div><br></div><div>So far, the concern seems to be:</div><div>- 7.1.2.2(h) doesn't apply to non-TLS sub CAs (despite 7.1.2.2(g) being clear and explicit it does, and 7.1.2.4 equally seeming to unambiguously apply to everything a BR-compliant CA issues)</div><div>- 7.1.5 doesn't actually require these exclusions if they're excluded by EKU, despite such language ("If the Subordinate CA includes the id-kp-serverAuth extended key usage") not appearing in these paragraphs for those requirements.</div><div><br></div><div>Where I think you may be missing is that I am trying to get the BRs into the end state you're describing, with the profiles work. But they aren't there right now, and the concern being discussed is how we get there :)</div></div></div>