<!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 14/5/2024 1:27 μ.μ., Adriano Santoni
via Servercert-wg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0100018f76a4914f-0012fd42-ea41-4217-be6e-3b7065fb5050-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><font face="Calibri">I would agree to consider out-of-scope (of
the BRs) a leaf certificate with EKU=clientAuth issued by a
SubCA that has EKU={server,client}, provided of course the
leaf certificate does not assert a BR TLS policy OID because
this would be contradictory. </font></p>
<p><font face="Calibri">Besides, at least one widely used linter
considers a certificate in-scope if it contains EKU=serverAuth
and/or it contains a BR policy OID, which seems quite logical
to me.</font></p>
<p><font face="Calibri">Adriano</font></p>
<p><font face="Calibri"><br>
</font></p>
</blockquote>
<br>
I think the policy OID is effectively completely ignored (along with
anything in the subject of the certificate or other extensions)
because the certificate is by design "incompatible for server TLS",
so it is discarded by server TLS consumers which are conformant with
RFC 5280.<br>
<br>
It is misleading, but it is very difficult to add requirements
around what a Certificate MUST NOT include (e.g. an existing TLS BR
policy OID). I'd prefer to clarify that these are out-of-scope of
the BRs as long as they are structured according to RFC 5280, and do
not contain EKU=serverAuth, just like we did for the TC non-TLS
subCA Profile.<br>
<br>
Dimitris.<br>
<br>
<blockquote type="cite"
cite="mid:0100018f76a4914f-0012fd42-ea41-4217-be6e-3b7065fb5050-000000@email.amazonses.com">
<p><font face="Calibri"> </font></p>
<div class="moz-cite-prefix">Il 14/05/2024 11:33, Dimitris
Zacharopoulos (HARICA) via Servercert-wg ha scritto:<br>
</div>
<blockquote type="cite"
cite="mid:0100018f76738e97-739d5cad-6797-4977-b997-150e338d5740-000000@email.amazonses.com">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<title></title>
<div align="center">
<table width="30%" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="top" bgcolor="#ffff00"> <span
style="color: red;">NOTICE:</span> Pay attention -
external email - Sender is
<a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:0100018f76738e97-739d5cad-6797-4977-b997-150e338d5740-000000@amazonses.com"
moz-do-not-send="true">0100018f76738e97-739d5cad-6797-4977-b997-150e338d5740-000000@amazonses.com</a>
</td>
</tr>
</tbody>
</table>
<br>
</div>
<br>
Dear Members, <br>
<br>
Following-up on an interesting <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1886467#c11"
moz-do-not-send="true">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" moz-do-not-send="true">CA/Browser Forum
Server Certificate Working Group Charter</a> which states
(emphasis mine):</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>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>
<blockquote type="cite"><i>.....for the issuance and management
of Publicly-Trusted TLS Server Certificates;</i></blockquote>
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"
moz-do-not-send="true">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>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Servercert-wg mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:Servercert-wg@cabforum.org" moz-do-not-send="true">Servercert-wg@cabforum.org</a>
<a class="moz-txt-link-freetext"
href="https://lists.cabforum.org/mailman/listinfo/servercert-wg"
moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a>
</pre>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Servercert-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Servercert-wg@cabforum.org">Servercert-wg@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/servercert-wg">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a>
</pre>
</blockquote>
<br>
</body>
</html>