<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    [Moving this discussion to the validation subcommittee]<br>
    <br>
    <div class="moz-cite-prefix">On 13/10/2022 5:36 μ.μ., Dimitris
      Zacharopoulos (HARICA) via Servercert-wg wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:01000183d1c65c20-e4a56f23-7d7d-45ae-a45a-09d80aa9bb33-000000@email.amazonses.com">I'd
      like to ask for a few minutes to discuss about the OU attribute in
      CA Certificates as described in <a class="moz-txt-link-freetext"
        href="https://github.com/cabforum/servercert/pull/394"
        moz-do-not-send="true">https://github.com/cabforum/servercert/pull/394</a>
      so we can decide on next steps.<br>
      <br>
      Thanks,<br>
      Dimitris.</blockquote>
    <br>
    Following up on todays SCWG call, I did a quick review at the
    profiles ballot and unfortunately the current draft describes 5
    different CA Certificate profiles (actually there is one more for
    Cross Certificates in <a moz-do-not-send="true"
href="https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#7122-cross-certified-subordinate-ca-certificate-profile">7.1.2.2</a>
    but that doesn't seem to create any issues):<br>
    <ol>
      <li><a moz-do-not-send="true"
href="https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#7121-root-ca-certificate-profile">7.1.2.1
          Root CA Certificate Profile</a></li>
      <li><a moz-do-not-send="true"
href="https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile">7.1.2.3
          Technically Constrained Non-TLS Subordinate CA Certificate
          Profile</a></li>
      <li><a moz-do-not-send="true"
href="https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#7124-technically-constrained-precertificate-signing-ca-certificate-profile">7.1.2.4
          Technically Constrained Precertificate Signing CA Certificate
          Profile</a> (we should fix the internal broken link to this
        pointer in section 7.1.2)</li>
      <li><a moz-do-not-send="true"
href="https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#7125-technically-constrained-tls-subordinate-ca-certificate-profile">7.1.2.5
          Technically Constrained TLS Subordinate CA Certificate Profile</a></li>
      <li><a moz-do-not-send="true"
href="https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#7126-tls-subordinate-ca-certificate-profile">7.1.2.6
          TLS Subordinate CA Certificate Profile</a><br>
      </li>
    </ol>
    that all point to a common section <a moz-do-not-send="true"
href="https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#712102-ca-certificate-naming">7.1.2.10.2</a>
    for the subjectDN CA Certificate Naming. <br>
    <br>
    If we want to disallow OU in CA Certificates (new Roots and
    Intermediates), shouldn't that only affect 7.1.2.5 and 7.1.2.6? I'm
    not sure about 7.1.2.4 as I am not so familiar with Precertificate
    Signing CAs but it looks like it needs to follow the "TLS CA" rules.
    If there is agreement, here are some ways to tackle this problem:<br>
    <ol>
      <li>Rename 7.1.2.10.2 from "CA Certificate Naming" to "TLS CA
        Certificate Naming", use "MUST NOT" for the OU field, create a
        7.1.2.10.3 "Non-TLS CA Certificate Naming" with exactly what's
        in today's 7.1.2.10.2 and shift all sections at the same level
        by one; or</li>
      <li>Update 7.1.2.10.2, add the Attribute Type OU, and in the
        Presence column state "MUST NOT," except for Non-TLS Subordinate
        CA Certificates that meet the Certificate Profile described in
        section 7.1.2.3".</li>
    </ol>
    <p>Thoughts or other ideas?</p>
    <p>Dimitris.<br>
    </p>
    <br>
    <br>
  </body>
</html>