<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 2/9/2021 10:46 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvavSDd5WTTqPfrs4kiAmC=HgKia1RVq-_Q6aKiqe09xMQ@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 3:12
PM Dimitris Zacharopoulos (HARICA) <<a
href="mailto:dzacharo@harica.gr" moz-do-not-send="true">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>
<br>
<blockquote type="cite"
cite="mid:CACvaWvavSDd5WTTqPfrs4kiAmC=HgKia1RVq-_Q6aKiqe09xMQ@mail.gmail.com">
<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>
<br>
<blockquote type="cite"
cite="mid:CACvaWvavSDd5WTTqPfrs4kiAmC=HgKia1RVq-_Q6aKiqe09xMQ@mail.gmail.com">
<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. 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>
<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvavSDd5WTTqPfrs4kiAmC=HgKia1RVq-_Q6aKiqe09xMQ@mail.gmail.com">
<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>
<br>
Noted that RFC-5280-only implementations will probably ignore the
EKU in the CA Certificate, but the BRs are applying rules on top of
RFC 5280 and make certain assumptions like the need for
digitalSignature KU in the CA Certificate to issue an OCSP response,
which is not currently enforced by most RFC 6960 implementations.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvavSDd5WTTqPfrs4kiAmC=HgKia1RVq-_Q6aKiqe09xMQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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>
</div>
</blockquote>
<br>
Again, you probably mean 7.1.2.2(g).<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvavSDd5WTTqPfrs4kiAmC=HgKia1RVq-_Q6aKiqe09xMQ@mail.gmail.com">
<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. <br>
<br>
Once the non-TLS subCA has been issued, whatever actions that
non-TLS subCA does as an Issuer, is out of BRs scope. An
interpretation that docSigning, S/MIME, clientAuth-only subCAs are
subject to the BRs as Issuers, and must be audited according to the
BRs, sounds unreasonable to me.<br>
<br>
During the delegated OCSP responder incidents, we had cases where
non-TLS subCAs had the id-kp-ocspSigning KeyPurposeId in their EKU
extension. This was creating a risk to the Root that issued those
non-TLS subCAs. It was well recognized that even-though these
non-TLS subCAs were out of BRs scope (as Issuers), the fact that
they were issued by Roots that were in-scope of the BRs enabled the
revocation requirements for those non-TLS subCAs.<br>
<br>
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>
<br>
Again, this is my personal interpretation of the BRs as far as scope
is concerned and I would like to welcome other Members (CAs and
Browsers) to share theirs. I will also try to be on the validation
subcommittee call tomorrow.<br>
<br>
<br>
Thanks,<br>
Dimitris.<br>
</body>
</html>