<div dir="ltr"><div>Gah, I really do fail :)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 8, 2021 at 1:36 PM Ryan Sleevi via Validation <<a href="mailto:validation@cabforum.org">validation@cabforum.org</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 dir="ltr"><div dir="ltr"><br></div><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>
<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></div></blockquote><div><br></div><div>Yes, 7.1.2.2(g) applies to not-TLS. Therefore, 7.1.2.2(f) also applies to not-TLS.</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 dir="ltr"><div class="gmail_quote"><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><div><br></div><div>s/h/g/</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 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>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></div></blockquote><div><br></div><div>7.1.2.2(g)</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 dir="ltr"><div class="gmail_quote"><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></div></blockquote><div><br></div><div>This was meant to say 7.1.2.2 (<b>f</b>) - that is, to highlight that the requirements on nameConstraints applies to all not-TLS sub-CAs, just like 7.1.2.2 (<b>g</b>) also applies to all not-TLS sub-CAs.</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 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>
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><div><br></div><div>And then make embarrassing mistakes despite having the page right open and double-checking.</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 dir="ltr"><div class="gmail_quote"><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(<b>f</b>), 7.1.2.2(<b>g</b>), and 7.1.2.4 of the BRs today (and 7.1.5, which is referenced by 7.1.2.2(<b>f</b>)). 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.<br></div><div><br></div><div>So far, the concern seems to be:</div><div>- 7.1.2.2(<b>f</b>) 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></blockquote><div><br></div><div>Corrected inline and <b>bolded</b></div></div></div>