[cabf_validation] OU attribute in CA Certificates

[Dimitris Zacharopoulos (HARICA)]

The breakdown makes it clearer, thanks Doug. We just need to see how 
this will appear in the table via markdown.

Dimitris.

On 13/10/2022 11:05 μ.μ., Doug Beattie wrote:
>
> Hi Dimitris,
>
> I’d lean towards you option #2:
>
>  2. 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".
>
> Just a suggestion:
>
>  2. Update 7.1.2.10.2, add the Attribute Type OU, and in the Presence
>     column state:
>       * MUST NOT for TLS Subordinate CA Certificates defined in
>         section 7.1.2.3,
>       * SHOULD NOT for all other CAs"
>
> *From:* Validation <validation-bounces at cabforum.org> *On Behalf Of 
> *Dimitris Zacharopoulos (HARICA) via Validation
> *Sent:* Thursday, October 13, 2022 12:31 PM
> *To:* validation at cabforum.org
> *Subject:* [cabf_validation] OU attribute in CA Certificates
>
> [Moving this discussion to the validation subcommittee]
>
> On 13/10/2022 5:36 μ.μ., Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg wrote:
>
>     I'd like to ask for a few minutes to discuss about the OU
>     attribute in CA Certificates as described in
>     https://github.com/cabforum/servercert/pull/394 so we can decide
>     on next steps.
>
>     Thanks,
>     Dimitris.
>
>
> 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 7.1.2.2 
> <https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#7122-cross-certified-subordinate-ca-certificate-profile> 
> but that doesn't seem to create any issues):
>
>  1. 7.1.2.1 Root CA Certificate Profile
>     <https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#7121-root-ca-certificate-profile>
>  2. 7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate
>     Profile
>     <https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile>
>  3. 7.1.2.4 Technically Constrained Precertificate Signing CA
>     Certificate Profile
>     <https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#7124-technically-constrained-precertificate-signing-ca-certificate-profile>
>     (we should fix the internal broken link to this pointer in section
>     7.1.2)
>  4. 7.1.2.5 Technically Constrained TLS Subordinate CA Certificate
>     Profile
>     <https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#7125-technically-constrained-tls-subordinate-ca-certificate-profile>
>  5. 7.1.2.6 TLS Subordinate CA Certificate Profile
>     <https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#7126-tls-subordinate-ca-certificate-profile>
>
> that all point to a common section 7.1.2.10.2 
> <https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#712102-ca-certificate-naming> 
> for the subjectDN CA Certificate Naming.
>
> 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:
>
>  1. 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
>  2. 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".
>
> Thoughts or other ideas?
>
> Dimitris.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20221014/03dca3a9/attachment-0001.html>