<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
Dear Members,<br>
<br>
Following-up on an interesting <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1886467#c11">public
incident</a>, I would like to have a discussion about the scope of
the TLS BRs as specified in the SCWG Charter and in the actual TLS
BRs, especially when it comes to single-purpose "client
authentication" certificates (i.e. leaf certificates that include
the <i>id-kp-clientAuth</i> and DO NOT include the<i>
id-kp-serverAuth</i> KeyPurposeId in their extKeyUsage extension).<br>
<p>The TLS BRs describe the profiles of Subordinate CA Certificates
issued from a Root that is in-scope for server TLS authentication,
even for the case of Technically-Constrained non-TLS CA
Certificates. There was a lot of discussion about whether this is
permitted based on the SCWG Charter and there was consensus that
Browsers want to make sure that there are some minimum
expectations about the structure of such non-TLS CA certificates,
especially the adherence to RFC 5280. I recall that there was also
consensus that whatever is issued off of these TC non-TLS CAs is
not in scope of the TLS BRs.</p>
<p><u>Does this seem like a fair statement about intent of the group
on the expectations of TC non-TLS CAs and their leaf
certificates?</u><br>
</p>
<p>Technically Constrained non-TLS Issuing CAs have a defined
profile in the TLS BRs but IMO it cannot, and should not mandate
the profile of non-TLS leaf certificates based on the <a
href="https://cabforum.org/working-groups/server/charter/"
rel="nofollow">CA/Browser Forum Server Certificate Working Group
Charter</a> which states (emphasis mine):</p>
<p>
<blockquote type="cite"><i>(a) To specify Baseline Requirements,
Extended Validation Guidelines, and other acceptable practices
for the issuance and management of <b>TLS server certificates
used for authenticating servers accessible through the
Internet</b></i></blockquote>
</p>
<p>It gets more interesting when an Issuing CA that is technically
capable of issuing server authentication TLS Certificates (by
including the<i> id-kp-serverAuth</i> KeyPurposeId in its
extKeyUsage extension), also includes the <i>id-kp-clientAuth</i>
KeyPurposeId, thus being technically capable of issuing client
authentication TLS Certificates.<br>
</p>
<p>Please recall that a few years back multi-purpose Issuing CAs
existed, where the EKU was not present, and even if it was, it
allowed the inclusion of various KeyPurposeIds.</p>
<p>Is it ok for such an Issuing CA to create a single-purpose client
authentication TLS Certificate, one that is structured according
to RFC 5280 (thus can be successfully parsed by Relying Party RFC
5280-conformant software), contains an extKeyUsage extension which
contains the <i>id-kp-clientAuth</i> and DOES NOT include the <i>id-kp-serverAuth</i>
KeyPurposeId?</p>
<p>My understanding is that these particular leaf certificates are
allowed to be issued by a server TLS capable CA and they are
considered out-of-scope of the BRs, in the sense that <b>they are
not TLS Server Certificates</b>. The SCWG has accepted this
"risk" with the client authentication certificates by allowing the
co-existence of <i>id-kp-clientAuth</i> and<i> id-kp-serverAuth </i>KeyPurposeIds
and the explicit dis-allowance of <i>id-kp-emailProtection,
id-kp-codeSigning, id-kp-timeStamping, anyExtendedKeyUsage</i>
in the CA Certificate profiles.<br>
</p>
<p>The first paragraph of the TLS BRs (section 1.1) states:</p>
<p>
<blockquote type="cite"><i>.....for the issuance and management of
Publicly-Trusted TLS Server Certificates;</i></blockquote>
</p>
Provided these certificates follow RFC 5280 and can be properly
parsed, Browsers should never consider such certificates server TLS
certificates. They are by design "technically constrained".<br>
<br>
Thoughts? Disagreements? I know that Apple has already publicly <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1886467#c13">shared
an opinion</a> on this matter so I'm hoping to get more feedback
from Members here :)<br>
<br>
<br>
Thanks,<br>
Dimitris.<br>
<br>
<br>
</body>
</html>