[cabf_validation] OU attribute in CA Certificates

Fri Oct 14 13:39:46 UTC 2022

I continue to have issues with whether the server certificate BRs should be able to impose requirements on the contents of non-server ICAs.  It seems like a violation of the charter to me, as I’ve stated several times before over the years.

It makes sense to insist that they are well-formed, compliant with RFC 5280, have an EKU, can be determined to *not* be a TLS ICA, etc.  But going beyond that to state what fields are or are not permitted seems to be stepping on the toes of the other working groups that are responsible for such certificates.  I’d support a uniform standard for what can/can be included in all ICAs, but I think that needs to be done by a WG like the “BR of BRs” working group that has been discussed ever since we started doing governance reform.  I don’t think server cert as it is currently chartered can do it.

-Tim

From: Validation <validation-bounces at cabforum.org> On Behalf Of Martijn Katerbarg via Validation
Sent: Friday, October 14, 2022 3:54 AM
To: Doug Beattie <doug.beattie at globalsign.com>; CABforum3 <validation at cabforum.org>; Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
Subject: Re: [cabf_validation] OU attribute in CA Certificates

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

From: Validation <validation-bounces at cabforum.org<mailto: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<mailto:dzacharo at harica.gr>>; CA/Browser Forum Validation SC List <validation at cabforum.org<mailto: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:

  1.  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:

  1.  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<mailto: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<mailto: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/fb6b9244/attachment-0001.html>