[cabf_validation] OU attribute in CA Certificates
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Fri Oct 14 08:21:19 UTC 2022
On 14/10/2022 10:53 π.μ., Martijn Katerbarg wrote:
>
> Dimitris, Doug,
>
> Is there any reason why we wouldn’t want to prohibit it for Root CA
> certificates and non-TLS Sub CA Certificates?
>
> Now maybe this is going in a direct where it becomes part of version 2
> of the profiles, but should we be looking at which fields are being
> included at this moment and make a more clear requirement on what’s
> allowed and what’s not?
>
> With the language as it is proposed, it seems that any subject
> attribute except for OU is allowed.
>
> In my opinion it would be more desirable to add a specific MAY for
> fields that CA’s are using and are deemed acceptable, and find a path
> forward on setting Any Other Attribute to MUST NOT
>
Martijn,
I agree with you that this should be the ultimate goal (add a specific
MAY for more fields, etc) but this would require more work and
discussion. I don't believe it can be added to the profiles ballot as it
would cause more delays.
At the same time, there is already agreement to prohibit OU for
TLS-specific CAs that will cause no impact since it is not included in
CA Certificates since the cutoff date.
Thanks,
Dimitris.
> Martijn
>
> *From:*Validation <validation-bounces at cabforum.org> *On Behalf Of
> *Doug Beattie via Validation
> *Sent:* Thursday, 13 October 2022 22:06
> *To:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; CA/Browser
> Forum Validation SC List <validation at cabforum.org>
> *Subject:* Re: [cabf_validation] OU attribute in CA Certificates
>
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you recognize the sender
> and know the content is safe.
>
> 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
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fpull%2F394&data=05%7C01%7Cjacco.rens%40sectigo.com%7Cebc9d445838648f70d5008daad566518%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638012883815617803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PB9Qq%2F8B5JDESNPMwJV0uNlgNMaNwHRb8YDGX1gCE38%3D&reserved=0>
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fblob%2Fprofiles%2Fdocs%2FBR.md%237122-cross-certified-subordinate-ca-certificate-profile&data=05%7C01%7Cjacco.rens%40sectigo.com%7Cebc9d445838648f70d5008daad566518%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638012883815617803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WeR8L7DOjeA7a7iM9Qrkz1SlxBVSUp%2B0bwx%2F9LozIOI%3D&reserved=0>
> but that doesn't seem to create any issues):
>
> 1. 7.1.2.1 Root CA Certificate Profile
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fblob%2Fprofiles%2Fdocs%2FBR.md%237121-root-ca-certificate-profile&data=05%7C01%7Cjacco.rens%40sectigo.com%7Cebc9d445838648f70d5008daad566518%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638012883815617803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6CzFgTpYWVUG7jdcGcqlETJ2W%2BF97q2mqqamQt3eLUA%3D&reserved=0>
> 2. 7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate
> Profile
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fblob%2Fprofiles%2Fdocs%2FBR.md%237123-technically-constrained-non-tls-subordinate-ca-certificate-profile&data=05%7C01%7Cjacco.rens%40sectigo.com%7Cebc9d445838648f70d5008daad566518%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638012883815617803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fje0irQN3UlqUtvNX9LMwIPGEk%2Fd8BcaB6khnHL5a3o%3D&reserved=0>
> 3. 7.1.2.4 Technically Constrained Precertificate Signing CA
> Certificate Profile
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fblob%2Fprofiles%2Fdocs%2FBR.md%237124-technically-constrained-precertificate-signing-ca-certificate-profile&data=05%7C01%7Cjacco.rens%40sectigo.com%7Cebc9d445838648f70d5008daad566518%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638012883815617803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=in45vH0byYZGNPPc5E%2FlF%2Bv08bQttI%2BRf6ijRphnYbw%3D&reserved=0>
> (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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fblob%2Fprofiles%2Fdocs%2FBR.md%237125-technically-constrained-tls-subordinate-ca-certificate-profile&data=05%7C01%7Cjacco.rens%40sectigo.com%7Cebc9d445838648f70d5008daad566518%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638012883815617803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wSiob5hiGnHqcQ3Zn%2F1pxCiCodv28GliCQPtgMa2FhY%3D&reserved=0>
> 5. 7.1.2.6 TLS Subordinate CA Certificate Profile
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fblob%2Fprofiles%2Fdocs%2FBR.md%237126-tls-subordinate-ca-certificate-profile&data=05%7C01%7Cjacco.rens%40sectigo.com%7Cebc9d445838648f70d5008daad566518%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638012883815617803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FwcOXJnJpds1YwHo8IRYLne7W7jJPqTUpgf2KjhK1tY%3D&reserved=0>
>
> that all point to a common section 7.1.2.10.2
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fblob%2Fprofiles%2Fdocs%2FBR.md%23712102-ca-certificate-naming&data=05%7C01%7Cjacco.rens%40sectigo.com%7Cebc9d445838648f70d5008daad566518%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638012883815617803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=X5qV3KU0biI2gfUhWZ63EWAUIWes2Qo8lTrg%2Br5wuAo%3D&reserved=0>
> 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/2eaefb25/attachment.html>
More information about the Validation
mailing list