<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>