[cabf_validation] OU attribute in CA Certificates

Tue Oct 18 08:26:31 UTC 2022

I like the idea of having a common framework for all WGs base documents
(basic BRs common to all BRs), and from there, work on the specificities of
every certificate type.

We´ve been having some discussions in the S/MIME WG because of this
“alignment” with the SC WG, and also happened initially with the CS.

De: Validation <validation-bounces at cabforum.org> En nombre de Tim Hollebeek
via Validation
Enviado el: viernes, 14 de octubre de 2022 15:40
Para: Martijn Katerbarg <martijn.katerbarg at sectigo.com>; CABforum3
<validation at cabforum.org>; Doug Beattie <doug.beattie at globalsign.com>;
Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
Asunto: 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.

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
<mailto: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
<mailto:doug.beattie at globalsign.com> >; CABforum3 <validation at cabforum.org
<mailto:validation at cabforum.org> >; Dimitris Zacharopoulos (HARICA)
<dzacharo at harica.gr <mailto: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:

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
<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.co
m%2Fcabforum%2Fservercert%2Fpull%2F394&data=05%7C01%7Cinigo.barreira%40secti
go.com%7Ce371835b16c745daacdb08daade996fe%7C0e9c48946caa465d96604b6968b49fb7
%7C0%7C0%7C638013517302302284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=edm4%2Bx%
2BFMb%2BNs3co8xxjxgb4DuWehQluULLVYduKOTU%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 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.co
m%2Fcabforum%2Fservercert%2Fblob%2Fprofiles%2Fdocs%2FBR.md%237121-root-ca-ce
rtificate-profile&data=05%7C01%7Cinigo.barreira%40sectigo.com%7Ce371835b16c7
45daacdb08daade996fe%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C6380135173
02302284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=UkesSsNS7BPiKWkrI1mesJ%2BBjtpV
pn6GipI5fKwSPow%3D&reserved=0>
2.	7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate
Profile
3.	7.1.2.4 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
5.	7.1.2.6 TLS Subordinate CA Certificate Profile
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2Fcabforum%2Fservercert%2Fblob%2Fprofiles%2Fdocs%2FBR.md%237126-tls-subord
inate-ca-certificate-profile&data=05%7C01%7Cinigo.barreira%40sectigo.com%7Ce
371835b16c745daacdb08daade996fe%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7
C638013517302302284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=eua5zHKSrdKdqhvZmsv
E9VL3FtmDk1iRWphcBKa6FYE%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.co
m%2Fcabforum%2Fservercert%2Fblob%2Fprofiles%2Fdocs%2FBR.md%23712102-ca-certi
ficate-naming&data=05%7C01%7Cinigo.barreira%40sectigo.com%7Ce371835b16c745da
acdb08daade996fe%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C63801351730245
8498%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=vDN8KC5j09nikKGj3EO7aTrEv%2BWQIeCp
4zw%2BZ%2Bn2IJo%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/20221018/95601c82/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6853 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20221018/95601c82/attachment-0001.p7s>