[cabfpub] Naming rules

[Geoff Keating]

Although these are all good points, it’s worth mentioning that the BR rules for what has to go in a subject name are intentionally quite lax, because after all, you can just omit the whole thing and issue a DV certificate.  So I think it’s somewhat intentional that you can have certificates for different entities that look the same.

Perhaps a more interesting question is this: suppose you were issuing an OV certificate and you wanted to do it really well, so you were going to fill in all the information just like it was EV (but presumably without the more extensive EV checks).  In this case, you’d fill in streetAddress for the Delano example below, wouldn’t you?  (After checking that it matches the address on the DBA registration form, presumably—but without the site visit you would need to do for a real EV certificate.)  And maybe also fill in jurisdictionOfRegistration if these were real legal entities.

So maybe this is another case where we want to try to converge the BR and EV standards, and have OV just be an EV certificate with data missing and less validation.

> On 26 Mar 2017, at 9:41 am, Peter Bowen via Public <public at cabforum.org> wrote:
> 
>> 
>> On Mar 25, 2017, at 1:20 PM, Peter Bowen via Public <public at cabforum.org> wrote:
>> 
>> 
>>> On Mar 25, 2017, at 12:53 PM, Ryan Sleevi <sleevi at google.com> wrote:
>>> 
>>> On Sat, Mar 25, 2017 at 3:38 PM, Peter Bowen <pzb at amzn.com> wrote:
>>> Who cares if there are collisions in cert subjects?  We already have that possibility and this doesn’t really change that.
>>> 
>>> Can you provide an example using the current validation requirements? I would think that the need for names to be meaningful and the validation procedures would exist to disambiguate these names by using a unique (for purpose) construction.
>> 
>> We allow individual names in certificates.  There is zero requirement that only one person with an unique name live in the same city.  Growing up we used to routinely get calls for someone who had the same name as my father who lived all of three blocks from us.
>> 
>> Additionally, looking at https://arcc.sdcounty.ca.gov/pages/fbn-info.aspx it explicitly says:
>> 
>> "All prospective registrants are cautioned that REGISTRATION OF A FICTITIOUS NAME DOES NOT GUARANTEE EXCLUSIVE USE OF THAT NAME.”
> 
> In addition to this, it notes that there is no state registration of fictitious names, it is handled at the county level.  However communities (localities) can span county lines.  For example:
> 
> 1998 ROAD 152
> DELANO CA 93215-9437
> is in Tulare County, while
> 
> 728 MAIN ST
> DELANO CA 93215-2936
> is in Kern County.
> 
> Under California law and according to the BRs, two unrelated businesses, if they had these addresses, could each be validated for:
> 
> /C=US/ST=California/L=Delano/O=Turquoise Haberdashery
> 
>>> Would it help if we moved the Subject Identified requirements to an overlay guideline such that the BRs only covered Internet-scope validation (e.g. just dNSName, ipAddress, SRVName, and maybe rfc822Address)?
>>> 
>>> And commonName
>> 
>> OK.  If the BRs only covered GeneralNames in the SubjectAlternativeName extension of types dNSName, ipAddress, rfc822Address and otherName (of type SRVName) and Subject Attributes of type commonName, would that help?
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170326/7b273570/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3321 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170326/7b273570/attachment-0001.bin>