[cabf_validation] OU attribute in CA Certificates

[Doug Beattie]

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/20221013/ac8f5bb4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8404 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20221013/ac8f5bb4/attachment-0001.p7s>