<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 15/5/2024 11:07 μ.μ., Clint Wilson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>Hi Dimitris,</div>
<div><br>
</div>
I guess I’m confused about how this is relevant to the scope of
the CA/BF as it seems quite orthogonal to the questions you posed
initially. Regardless of how clients check certificates, the
question is about the issuance of a certificate.
<div>As a side-note, the question that comes to mind for me is
what would be the reason to allow issuance of clientAuth-only
certificates by a subCA that also issues TBR-compliant TLS
certificates? Why is such a thing necessary or valuable? </div>
</blockquote>
<br>
This is easy to answer. Some use cases need single-purpose client
authentication certificates. There are numerous use cases where
client authentication certificates are used for strong
authentication, I'm sure you are aware of such use cases. While
client authentication use cases can ALL be supported by non-public
CAs, there are some regulatory requirements that demand such
certificates be issued from an audited and publicly-trusted CA. In
fact, HARICA has participated in public tenders where client
authentication certificates need to be issued from a CA that chains
to Apple, Microsoft and Mozilla Root Stores. Client authentication
certificates are asked in addition to server TLS certificates.<br>
<br>
The good practice here is for the CA to create a TC non-TLS SubCA
that includes the <i>id-kp-clientAuth</i> EKU and issue
single-purpose client authentication certificates off of that TC
SubCA. However, some CAs might have used a TLS SubCA, that also
includes the <i>id-kp-clientAuth </i>EKU, to issue those
single-purpose client authentication certificates. This was allowed
before SC-62.<br>
<br>
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com">
<div>Regardless of the conclusion to the questions you posed, I’m
failing to see why we would want any other outcome than to have
subCAs which issue TBR-compliant TLS certificate always and only
issue TBR-compliant TLS certificates. Perhaps if you could help
me understand the motivations behind seeking clarity on this, I
would be better able to understand how/why these questions have
been posed (even if those motivations are simple idle curiosity,
that would still help).</div>
</blockquote>
<br>
I don't object to the change of the goal from "we don't really care
so much about non-TLS server leaf certificates" to "we only want
server TLS-capable CAs to issue server TLS leaf certificates".
There's a difference. I'm trying to establish if the prohibition of
single-purpose clientAuth certs was intended in SC-62 or not. To the
best of my recollection, we didn't intend to enforce that, "only
server TLS leaf certificates are to be issued from server
TLS-capable Issuing CAs".<br>
<br>
This is why I insisted in establishing the past motivation before
the group decides where to go. Based on this outcome , we can add
more clarity in the BRs. To put this very clearly, if we didn't
intend to enforce that only server TLS leaf certs should be issued
from server TLS-capable CAs, then the current language that
prohibits issuance of single-purpose client authentication
certificates from server TLS-capable CAs, is an unintended
prohibition that we should fix it. If no CA is interested to lift
this prohibition, then we should just add clarification language
that every certificate issued from a server TLS-capable Issuing CA
is in scope of the TLS BRs and it MUST be a leaf server-TLS
Certificate which MAY have additional EKUs (as described in the
corresponding table in the BRs). If the group decides to lift this
unintended prohibition, we could add rules around the policy OIDs
(e.g. that the TLS BR OIDs must not be used in no-TLS server
certificates).<br>
<br>
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com">
<div>
<div><br>
<div>However, leaving aside that there’s likely some level of
ignorance on my part, to the extent I understand it, the
question at hand is essentially: </div>
</div>
<blockquote
style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div>
<div>Is it compliant for a CA, that wants to be considered
compliant with the TBRs, to issue a certificate which
asserts compliance with the TBRs — by way of including an
OID under the CA/BF OID arc defined to represent a
certificate’s compliance with the Policy document
associated with that OID — where the issued certificate
does not match one of the profiles defined in Section 7.1
of the TBRs?</div>
</div>
</blockquote>
<div>
<div><br>
<div>Breaking this apart, there are several aspects to
consider.</div>
<div><br>
</div>
<div>First, does the CA want to be considered compliant with
the TBRs? If not, then it doesn’t matter which TBR OIDs
they assert because they’re not intending to be considered
compliant. If the CA doesn’t have a relying party they’re
expecting to rely on their assertions in general, then the
rest of the question is relatively moot; on the other
hand, if the CA’s assertions are intended to be accurate
and treated as such, then it’s a pretty important
foundational point I think. For the purposes of this
discussion, I’m assuming the CA does want to be considered
compliant with the TBRs because if that’s not the case
then the conclusions to the rest of this don’t really
matter.</div>
</div>
</div>
</div>
</blockquote>
<br>
Correct. Single-purpose Client Authentication Certificates (and
similarly in the past, single-purpose S/MIME, Code Signing
Certificates), were considered out-of-scope of the TLS BRs due to
the EKU restriction which is the #1 factor for scoping the usage of
a certificate.<br>
<br>
I can't fully analyze why a CA would assert the CA/B Forum server
TLS OID in a non-server TLS OID. Maybe the CA has applied <i>some </i>of
the TLS BRs but not the profiles section? I don't know but that's
besides the point. Based on the SCWG Charter, this group should only
focus on use cases<i> "of TLS server certificates used for
authenticating servers accessible through the Internet"</i>, i.e.
certificates that include the <i>id-kp-serverAuth</i> EKU. This has
been discussed in the past during the <a
href="https://github.com/cabforum/forum/blob/main/SMCWG-charter.md">chartering
process for the S/MIME WG</a> and similarly for the <a
href="https://github.com/cabforum/forum/blob/main/CSCWG-charter.md">CSCWG</a>
which made it unambiguously clear that the separation of policy
scope is based on the EKU, not the policy OIDs. I was hoping to
align the charters of all WGs taking good elements from all and
apply them to the rest but I haven't had the time to look into it
yet.<br>
<br>
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com">
<div>
<div>
<div>
<div><br>
</div>
<div><font color="#000000"><span
style="caret-color: rgb(0, 0, 0);">Second, are TBR
OIDs defined by their node owner as representing
compliance with the TLS Baseline Requirements? Based
on what’s documented in </span></font><a
href="https://cabforum.org/resources/object-registry/"
moz-do-not-send="true" class="moz-txt-link-freetext">https://cabforum.org/resources/object-registry/</a>,
I believe this is clearly the case. For example, issuing a
certificate with the 2.23.140.1.2.2 OID is a
representation that the “Certificate [was] issued in
compliance with the TLS Baseline Requirements –
Organization identity asserted”. Maybe this should be
brought into 7.1.6.1 of the TBRs, but I don’t think that’s
necessary to come to a conclusion here.</div>
</div>
</div>
</div>
</blockquote>
<br>
By extension, if a CA creates a separate hierarchy that is not
trusted in the public Internet, what happens if it issues
certificates that include a TLS BR policy OID? Such a hierarchy
should be totally out-of-scope of the TLS BRs even if it asserted
policy OIDs of the TLS BRs because the BRs are scoped to <i>"the
issuance and management of Publicly-Trusted TLS Server
Certificates; Certificates that are trusted by virtue of the fact
that their corresponding Root Certificate is distributed in
widely-available application software"</i> and these would not fit
that description.<br>
<br>
Similarly, single-purpose client authentication, code signing,
time-stamping, document signing, and other non-TLS server
certificates, are out of scope of the TLS BRs because they are not <i>"TLS
Server Certificates",</i> regardless if they chain to a
corresponding Root Certificate distributed in widely-available
application software. Please let me know if you agree or disagree
with this interpretation.<br>
<br>
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com">
<div>
<div>
<div>
<div><br>
</div>
<div>Third, does inclusion of a TBR OID in a certificate
issued by such a CA constitute that CA asserting that
certificate’s compliance with the TBRs? Combined with the
fact that the OID itself defines this to be the case, my
reading of <a
href="https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4"
moz-do-not-send="true">Section 4.2.1.4</a> of RFC
5280[1] is that if a Policy OID is present in a
certificate — or any certificate subordinate to a
certificate in which it’s present — then the certificate
has been issued under the Policy document represented by
that OID.</div>
</div>
</div>
</div>
</blockquote>
<br>
As explained earlier, this implies that test hierarchies would be in
violation of the TLS BRs but.... they are implicitly excluded from
scope because they are not publicly-trusted, just as the non-TLS
server Certificates are excluded for not being server TLS
Certificates.<br>
<br>
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com">
<div>
<div>
<div>
<div><br>
</div>
<div>Fourth, does a certificate which meets the above
conditions (i.e. wants to be considered compliant,
includes a TBR OID), need to match one of the profiles in
the TBRs? Section 7.1 announces quite clearly that "the CA
SHALL issue Certificates in accordance with the profile
specified in these Requirements” and further reinforces in
Section 7.1.2 that (emphasis mine) "If the CA asserts
compliance with these Baseline Requirements, <b>all
certificates that it issues</b> MUST comply with one of
the following certificate profiles”. There are possible
problematic interpretations of this, but I find it
difficult to grasp a truly good-faith reading of this as
meaning anything other than “Yes, a certificate which
includes a TBR OID is asserting compliance with the TBRs
and thus, the certificate itself must comply with one of
the certificate profiles defined in the TBRs.” That
doesn’t mean there’s not room to improve the language,
especially in 7.1.2 (which I’ve highlighted before in
Issue 495 (<a
href="https://github.com/cabforum/servercert/issues/495"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/cabforum/servercert/issues/495</a>)). </div>
<div>I personally also think the statements in 7.1 and 7.1.2
go quite a bit further than just this constrained example
of a certificate which <i>explicitly</i> indicates its
own compliance with the TBRs, but to keep the discussion
focused I’m only opining on that specific scenario.</div>
</div>
</div>
</div>
</blockquote>
<br>
That's exactly where original intent needs to be established. We can
decide on the improved language in either direction very easily. <br>
<br>
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com">
<div>
<div>
<div>
<div><br>
</div>
<div>Fifth, <font color="#000000"><span
style="caret-color: rgb(0, 0, 0);">does the
certificate match one of the profiles defined in
Section 7.1 of the TBRs? Here we have to look at the
certificate in question, with a couple components
quickly narrowing our search within Section 7.1. In
your first email, you indicated the question is about
a leaf certificate, so all the profiles where
basicConstraints:cA=TRUE can be discarded (7.1.2.1 -
7.1.2.6). Next you indicated that the certificate in
question does not include the serverAuth EKU, so we
can discard all profiles where the extendedKeyUsage
extension requires inclusion of the serverAuth value
(7.1.2.7 and 7.1.2.9). Finally, you indicated that the
certificate in question does include the clientAuth
EKU, so we can discard any remaining profile that
doesn’t allow the clientAuth EKU (7.1.2.8). This
brings us to the end of the list of 9 certificate
profiles defined in the TBRs today without finding any
that match the certificate described.</span></font></div>
</div>
</div>
</div>
</blockquote>
<br>
This argument assumes that single-purpose non-TLS Server
Certificates ARE in scope of the TLS BRs, therefore one of the leaf
certificate profiles must be followed. My point is that these are
out of scope of the BRs and restricting their issuance from a server
TLS-capable CA was unintended in SC-62.<br>
<br>
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com">
<div>
<div>
<div>
<div><font color="#000000"><span
style="caret-color: rgb(0, 0, 0);"><br>
</span></font></div>
<div><font color="#000000">Based on this sequence of
assessment, I’m personally led to the conclusion that
such a certificate is indeed not compliant. Please let
me know where I’ve misunderstood your question or
arrived at incorrect conclusions so I can better
understand the model you’re describing. <br>
</font></div>
</div>
</div>
</div>
</blockquote>
<br>
I hope I provided more clarity of my view and some additional
context. Let me repeat that I'm not against restricting server
TLS-capable CAs issuing only TLS server certificates but this needs
to be confirmed and clarified in the BRs because, to the best of my
knowledge, that was not intended nor discussed explicitly during
SC-62.<br>
<br>
Thanks to all for reading these long emails :-)<br>
<br>
<br>
Dimitris.<br>
</body>
</html>