<!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 7:27 μ.μ., Clint Wilson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:8E5E2F68-BA1B-42F6-AF99-1070E301AD90@apple.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Apologies if I’m replying to the wrong thread, but I wanted to
comment on one point here.<br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On May 14, 2024, at 8:54 AM, Dimitris Zacharopoulos
(HARICA) via Servercert-wg
<a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<div> <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>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I don’t think it’s entirely germane whether or not the
policy OID is discarded by an application; the inclusion of
the policy OID itself is a violation of RFC 5280 by the CA (if
it’s included in a certificate or certificate chain where the
leaf certificate being validated doesn’t comply with the
policy referenced by the OID).</div>
</div>
</blockquote>
<br>
According to <a
href="https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12">section
4.2.1.12 </a>of RFC 5280, a conforming implementation must use
the certificate if one of the indicated purposes of the EKU is used.
In my understanding, a Browser implementation that expects the <i>id-kp-serverAuth</i>
EKU MUST NOT trust a certificate that does not include that EKU or
the <i>anyExtendedKeyUsage</i>.<br>
<br>
AFAIK there no similar strong requirement for the policy tree. For
many years, CAs used custom Policy OIDs to indicate conformance with
a certain standard and it was very difficult for Certificate
Consumers to work with that information to make restrictions.<br>
<br>
I guess my point is that the EKU is checked first, and the policy
OID check comes later. Both must be ok for the certificate to be
trusted.<br>
<br>
Does that make sense?<br>
<br>
<blockquote type="cite"
cite="mid:8E5E2F68-BA1B-42F6-AF99-1070E301AD90@apple.com">
<div>
<div><br>
</div>
<div>Thanks!</div>
<div>-Clint</div>
<br>
<blockquote type="cite">
<div>
<div> <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">
<div><font face="Calibri"> </font><br
class="webkit-block-placeholder">
</div>
<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 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>
</div>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Servercert-wg@cabforum.org">Servercert-wg@cabforum.org</a><br>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/servercert-wg">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>