<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">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><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><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>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><br></div><div>The reason is because the sub-CA can issue more sub-CAs. So let's imagine we slap a pathLenConstraint=0 on the certificate, as an attempt to prevent further sub-CAs. Unfortunately, as discussed in <a href="https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9">RFC 5280, Section 4.2.1.9</a>, this doesn't actually prevent issuing subCA certificates - it just prevents non-self-issued Sub-CAs. That is, it exists to permit situations such as a key rollover. A key rollover certificate (that is, same subject, different SPKI) is still a new CA certificate, and still subject to the requirements here.</div><div><br></div><div>So even if your understanding of "Subscriber Certificate" is correct, it doesn't seem to change the conclusion here that id-kp-emailProtection as an EKU alone is not sufficient to meet the definition of Technically Constrained Subordinate CA Certificate in 1.6.1, even if we assume that #10 - #13 in <a href="https://archive.cabforum.org/pipermail/validation/2021-September/001689.html">https://archive.cabforum.org/pipermail/validation/2021-September/001689.html</a> (that is, the last two paragraphs) should only be read for certificates that have an id-kp-emailProtection.</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>
Regarding 7.1.2.4, I'm not sure which part you assume I am ignoring.
Is it the part about RFC 5280 requirements for well-formed fields?<br>
<br>
I read your email in
<a href="https://archive.cabforum.org/pipermail/validation/2021-September/001689.html" target="_blank">https://archive.cabforum.org/pipermail/validation/2021-September/001689.html</a><br>
<br>
but the discussion about 7.1.2.4 is probably not so clear to me. I
will try to re-read it and hopefully see your points clearer.<br></div></blockquote><div><br></div><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>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>