<div dir="ltr">That makes sense. I guess I'm saying that the intent of "Intermediates which are part of the WebPKI must not issue certificates which are not part of the WebPKI" makes sense to me.<div><br></div><div>Imagine that a publicly trusted Subordinate CA issues a "certificate" which is so badly malformed that it does not match any of the profiles allowed by the BRs, and it's even difficult to tell which profile it may have been intended to match before things went wrong. This feels to me like it should be treated as a misissuance: it should not have been possible for a CA to sign such an artifact, and the fact that it is possible merits an investigation and incident report.</div><div><br></div><div>But the difference between such a malformed certificate and a certificate which asserts clientAuth but not serverAuth is only one of degree, not one of kind. They are both certificates which are issued by a publicly-trusted Subordinate CA, but which do not conform to a BRs profile. If issuing a clientAuth-only cert should be okay, but issuing a badly malformed cert should not be, where and how does one draw the line between them?</div><div><br></div><div>Aaron</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 14, 2024 at 8:49 AM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<br>
<br>
<div>On 14/5/2024 5:58 μ.μ., Aaron Gable
wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div class="gmail_quote" dir="auto">
<div dir="ltr" class="gmail_attr">On Tue, May 14, 2024, 02:33
Dimitris Zacharopoulos (HARICA) via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>>
wrote:<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>
<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>
</div>
</blockquote>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Speaking in a personal capacity, it is my
opinion that no, such issuance is not acceptable.</div>
<div dir="auto"><br>
</div>
<div dir="auto">I agree that the resulting end-entity
client-auth-only certificate is out of scope of the BRs, and
is not in and of itself misissued. However, the issuing
intermediate itself is still in scope of the BRs, and its
behavior can be contained by them. By virtue of issuing the
clientAuth cert, the issuing intermediate has violated the BRs
requirement that "all certificates that it issues MUST comply
with one of the following certificate profiles".</div>
<div dir="auto"><br>
</div>
<div dir="auto">One could even argue that, having issued a
certificate which does not comply with a BR profile, the
issuing intermediate must be revoked within 7 days, per BRs
Section 4.9.1.2 (5): "The Issuing CA SHALL revoke a
Subordinate CA Certificate [if...] the Issuing CA is made
aware that the... Subordinate CA has not complied with this
document".</div>
<div dir="auto"><br>
</div>
<div dir="auto">Aaron</div>
<div class="gmail_quote" dir="auto">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>
</div>
</div>
</blockquote>
<br>
Thanks Aaron, I tried to first establish the <i>intent</i> of the
group before digging in the actual BRs. If we agree that the intent
was to place rules only for Server TLS leaf Certificates but not for
Client TLS Certificates, then we need to acknowledge that, and work
within the document to fix any conflicts.<br>
<br>
Dimitris.<br>
</div>
</blockquote></div>