[cabfpub] Ballot 199 - Require commonName in Root and Intermediate Certificates
Ben Wilson
ben.wilson at digicert.com
Fri May 5 17:57:15 UTC 2017
Gerv,
I think this still presents problems for vanity CAs. I can agree with the need to validate the entity in the O field (i.e. that the root CA has permission to create a CA with the sub CA's tradename), but I would want to preserve some flexibility. Right now, the language I'm concerned about says, "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." How strict will this be interpreted / applied?
Also, I assume an internally operated CA with a vanity CA name would still be included in the root CA's audits but what BR-related obligations might be unintentionally incurred by the entity listed in the O field.
Ben
-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Friday, May 5, 2017 7:23 AM
To: Ben Wilson <ben.wilson at digicert.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Ballot 199 - Require commonName in Root and Intermediate Certificates
On 04/05/17 16:20, Ben Wilson wrote:
> 1 - Does this ballot rule out “vanity CAs” – CAs with customer names
> in the subject field, even though the key is held by the root CA? (I
> can provide further clarification, and/or examples, if necessary.
I don't think so. It doesn't mandate the contents of the CN field other than a SHOULD-based uniqueness constraint.
> 2- What is the full current wording of Ballot 199?
It is as posted on 25th April, but with a MUST changed to a SHOULD. I will send out a full copy.
Gerv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4974 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170505/230c956f/attachment-0001.p7s>
More information about the Public
mailing list