<!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 5:58 μ.μ., Aaron Gable
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAEmnEreCaxhcDv0u_LJsY+rZYrL=jHBhgfi0_OO3XyFeXRuVfA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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"
              moz-do-not-send="true" class="moz-txt-link-freetext">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">
            <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>
    </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>
  </body>
</html>