<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">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div>