[cabf_validation] Subject DN attributes in ICA certificates

Wed Jun 10 05:38:05 MST 2020

Ryan, Tim and group,

I was looking at the CA Certificate Profile page yesterday and had a couple of questions.

1.	For ICAs, the BR lists 3 subject DN attributes and remains silent on the remaining.  We see lots of CAs including other attributes (State/Prov, Locality, etc.) and it’s not clear if this is a violation of the BRs or not (default deny discussion…).  Even after a long thread [1], we didn’t come to a consensus.   I don’t want to open that can of worms here, but the question is, as we update this section with the intent of not making material changes, what DN fields do we say are permitted?  Currently the page says Optional in the optional/required column but says prohibited further to the right (along with a reference to the DN tab for validation rules which implies it’s permitted).  Does this update intend to clarify what’s permitted and the associated validation rules?  Do we need a ballot prior to this Profile ballot to define permitted attributes and to specify the validation rules?
2.	Related to this, the definition of Org is currently: “This field MUST be present and the contents MUST contain either the Subject CA’s name or DBA as verified under Section 3.2.2.2”.  I could not find a definition of “Subject CA’s Name” to know what exactly that means.  A number of CAs, GlobalSign included, issue “Vanity” CAs.  Those are CA certificates in the name of a 3rd party and run by the CA identified in the Certificate Policy CPS link.  As we clarify the validation rules for fields in CA certificates, we should be clear on what we mean by “Subject CA’s name” and how these attributes are validated.  This was discussed in 2017 as part of Ballot 199. Gerv said it was permitted [2], and Ben said [3] this was part of the Policy WG discussion about “CA” and “CA Operator”, which I don’t think was ever reflected in the BRs.

We should come to conclusion on both of these as part of clarifying the certificate profiles and attribute validation rules.  Do we need a ballot on these before we can finalize the certificate profiles?

Ryan – I believe you created a list of all subject Attributes you found in CAs at some point.  Is that the starting point we wanted to use as the “whitelist” of attributes as we clarify what is permitted?

[1] https://lists.cabforum.org/pipermail/servercert-wg/2019-October/001154.html

[2] https://lists.cabforum.org/pipermail/public/2017-May/010928.html

[3] https://lists.cabforum.org/pipermail/public/2017-May/010936.html

Doug

From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Validation
Sent: Thursday, June 4, 2020 5:50 PM
To: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Sub-CAs and CP policy OIDs

On Tue, May 12, 2020 at 4:09 PM Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > wrote:

I had an issue flagged by a CA and went and filed https://github.com/cabforum/documents/issues/179 to try to capture the issue

The TL:DR: is how to handle a sub-CA that wishes to use the CABF OIDs within their end-entity certificates, but is not Affiliated with the Root.

Bumping this, and hoping to get some feedback from other root programs as to whether or not they see it as an issue with the BRs, and whether the attempted solution ( https://github.com/sleevi/cabforum-docs/pull/21 ) is aligning in the right direction. As it is, it raises questions about whether some Sub-CAs are in compliance, and creates challenges for issuing new Sub-CAs, so I want to make sure we're moving in the right direction and giving CAs the clarity they need from Root Programs.

Separate from that more immediate issue, I'm also starting to wonder whether, longer-term, we should restructure how we handle these policy OIDs, to make it easier for Relying Party software to use certificatePolicies for verification, rather than the (implemented by Google/Mozilla/Microsoft) EKU chaining behaviour. This would likely help resolve some of the issues around separate trust frameworks, by more clearly asserting the trust framework (or frameworks) a certificate belongs to. That's not something we need to immediately tackle, as we can still smoothly transition later, but the way our current requirements are structured, which this PR tries to preserve, prevents that.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200610/65715b8d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5688 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200610/65715b8d/attachment.p7s>