[cabfpub] givenName and surname revived

Wed Aug 24 16:53:42 UTC 2016

For OV, there are certain restraints that limit the likelihood that two Acme Corporations will exist in Portland, OR.  Oregon will allow only one Acme Corporation to be incorporated in the state (but a second Acme Corporation may exist in California and have an office in Portland, OR, so there could be two companies with the same name in Portland).

Likewise, trademark law can prevent a second company from using the same name as the first company in a locality if the second company is using the same name.  So there are some limits on having multiple organizations with the same name in the same jurisdiction.

There really are no similar limitations on having multiple “Robert Smiths” in Portland, OR.

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Adriano Santoni
Sent: Wednesday, August 24, 2016 7:15 AM
To: Erwann Abalea <Erwann.Abalea at docusign.com>
Cc: public at cabforum.org
Subject: Re: [cabfpub] givenName and surname revived

You are right: the ambiguity is also present in the OV case, and I think it would be better to reduce it, somehow, for both OV and IV certs, while keeping the difference from EV certs.

There can exist two or more John Smiths in the same city, or maybe even a dozen, each one owning a different domain, and it would be bad (to me) if they were to be issued IV certs that look identical in their Subject DNs. I suppose this is already happening. And the same holds for OV certs, I am perfectly aware. We are a small CA and have not been facing this kind of situation so far .... but if it was to occur to us, we would not issue certs with identical Subject DNs, even if allowed by the BRs. That would be "wrong", IMO. We would forcedly introduce some disambiguating attribute in the 2nd Subject DN (in compliance with the BRs), to differentiate them. This should be recommended or even mandated by the BRs.

I would like a requirement of this kind in the BRs: "the CA shall not issue certificates with identical subject DNs to different subscribers"... or something like that. Maybe this is already implied in the BRs, but I am not finding the paragraph corroborating it.

Adriano

Il 24/08/2016 15:47, Erwann Abalea ha scritto:
We’re in the review period, feel free to comment :)

In my point of view, there’s a confusion here between an identity (givenName+surName) and an individual (a physical person).
An identity can be claimed by several individuals, therefore it’s ambiguous. Likewise, an individual can have several identities, and these identities can change over the individual’s life.

BR only requires CAs to assert that an Applicant is right when claiming an identity and address. In the final certificate, you’ll only find the claimed identity and address, not the exact Applicant.

Looking at OV certificates, this ambiguity is already there. O can contain a company name or a brand name; a company name can be used by several distinct companies (even at the same place); a brand name registered under one jurisdiction belongs to a single company, but the same brand name can be registered in different jurisdictions and can also be used by different companies (with agreements). Identity and address verification can be performed using different documents, adding another layer of flexibility/complexity.

Cordialement,
Erwann Abalea

Le 24 août 2016 à 14:10, Adriano Santoni <adriano.santoni at staff.aruba.it<mailto:adriano.santoni at staff.aruba.it>> a écrit :

Pardon me for commenting on this topic when the ballot was already initiated.
However, I was not implying that the BRs currently require extra attributes in the Subject DN, nor am I proposing to modify the BRs at this stage.
I was just arguing that givenName+surname is too vague as an identity, IMO, even if referred to a specific country and locality.
That is, it does not seem to me an effective "equivalent" of the organizationName that is requested for OV certs.
I know that the BRs have been that way for long, so I am aware that my is a bit untimely.

Il 24/08/2016 13:07, Erwann Abalea ha scritto:
Bonjour,

givenName and surName are sufficient to specify an identity. More than one person may share this identity, but to me, BR don’t tend to distinguish them. There’s nothing in BR requiring CAs to generate certificates with canonical and non-ambiguous names. The non-ambiguity goal is achieved by following EVG only.

Given your example IV certificate, you’ll have givenName=John, surName=Doe, and also a country and either a localityName or a stateOrProvinceName. So you’ll know that this website belongs to someone named John Doe living in a specific city or state in this country, but nothing more.

If you want to follow ETSI 319412-1 rules and insert a serialNumber attribute to avoid name collisions, feel free, it’s not forbidden.

Cordialement,
Erwann Abalea

Le 24 août 2016 à 12:08, Adriano Santoni <adriano.santoni at staff.aruba.it<mailto:adriano.santoni at staff.aruba.it>> a écrit :

But givenName and surname are not sufficient to specify an identity. How many Robert Smiths exist in UK/US/CA ? (or Mario Rossi in Italy, as to that).
If I would like to know who's behind a web site whose SSL cert contains giveName=John, surname=Doe, I am none the wiser.

Il 23/08/2016 20:02, Bruce Morton ha scritto:
OK, thanks.

Bruce.

From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
Sent: Monday, August 22, 2016 6:16 PM
To: Bruce Morton <Bruce.Morton at entrust.com><mailto:Bruce.Morton at entrust.com>; public at cabforum.org<mailto:public at cabforum.org>
Subject: RE: givenName and surname revived

What do you mean by definition? I consider IV v. OV well defined because of the meaning associated with the OID inserted into the cert. Section 7.1.6.1 states “ {joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) certificate‐policies(1) baseline‐requirements(2) individual‐validated(3)} (2.23.140.1.2.3), if the Certificate complies with these Requirements and includes Subject Identity Information that is verified in accordance with Section 3.2.3.” Section 3.2.3 is verification of an individual whereas Section 3.2.2 is verification of an organization.

Jeremy

From: Bruce Morton [mailto:Bruce.Morton at entrust.com]
Sent: Monday, August 22, 2016 6:11 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>>; public at cabforum.org<mailto:public at cabforum.org>
Subject: RE: givenName and surname revived

Hi Jeremy,

My apologies, but can you clarify the section where IV certs are well defined? I see that “individual-validated” is stated twice in sections 1.2 and 7.1.6.1 (the same for domain-validated and organization-validated), but I can’t find the definition.

Thanks, Bruce.

From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
Sent: Saturday, August 20, 2016 10:41 AM
To: Bruce Morton <Bruce.Morton at entrust.com<mailto:Bruce.Morton at entrust.com>>; public at cabforum.org<mailto:public at cabforum.org>
Subject: RE: givenName and surname revived

Hey Bruce – IV certs are well defined. The goal of the ballot isn’t to further define IV certs but to permit use of the givenName and surname fields for IV certs. giveName and surname in the org field would be allowed. They’d still use the IV OIDs as they were validated under the IV section of the CP.

From: Bruce Morton [mailto:Bruce.Morton at entrust.com]
Sent: Friday, August 19, 2016 6:41 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>>; public at cabforum.org<mailto:public at cabforum.org>
Subject: RE: givenName and surname revived

Hi Jeremy,

Would like some clarification. On the call yesterday, it was said that IV certificates were not defined, so this ballot will help resolve this.

Per 7.1.4.2.2 b, the current BRs allow givenName and surname to be included in the organizationName field. Will this still be allowed? If so, what would the certificate type be? OV or IV? I would prefer that these be OV certificates.

If we do make the changes and the CAs have to meet Microsoft’s requirement to put a DV, OV, or IV certificate policy in the certificate, I think we should clearly define each certificate type.

Also, the stateOrProvinceName field appears to currently have an issue as it does not have any language to address the case where there is no state or province in the address.

Thanks, Bruce.

From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Thursday, August 18, 2016 12:09 PM
To: public at cabforum.org<mailto:public at cabforum.org>
Subject: [cabfpub] givenName and surname revived

Looking for two endorsers for the following revisions the baseline requirements adding support for givenName and surname:

Insert a new (C) under 7.1.4.2.2, renumbering all subsequent bullets.

c. Certificate Field: subject:givenName (2.5.4.42) and subject:surname (2.5.4.4)
Optional.
Contents:  If present, the subject:givenName field and subject:surname field MUST contain an natural person Subject’s name as verified under Section 3.2.3. A Certificate containing a subject:givenName field or subject:surname field MUST contain the (2.23.140.1.2.3) Certificate Policy OID.

d. Certificate Field: Number and street: subject:streetAddress (OID: 2.5.4.9)
    Optional if the subject:organizationName field, subject: givenName field, or subject:surname field are ispresent. Prohibited if the subject:organizationName field, subject:givenName, and subject:surname field are is absent.
   Contents: If present, the subject:streetAddress field MUST contain the Subject’s street address information as verified under Section 3.2.2.1.

e. Certificate Field: subject:localityName (OID: 2.5.4.7)
Required if the subject:organizationName field, subject:givenName field, or subject:surname field are ispresent and the subject:stateOrProvinceName field is absent. Optional if thesubject:stateOrProvinceName field and the subject:organizationName field, subject:givenName field, or subject:surname  field are present. Prohibited if the subject:organizationName field, subject:givenName, and subject:surname field are is absent.
Contents: If present, the subject:localityName field MUST contain the Subject’s locality information as verified under Section 3.2.2.1. If the subject:countryName field specifies the ISO 3166‐1 user‐assigned code of XX in accordance with Section 7.1.4.2.2(g), the localityName field MAY contain the Subject’s locality and/or state or province information as verified under Section 3.2.2.1.

f. Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8)
Required if the subject:organizationName field field, subject:givenName field, or subject:surname field areis present and the subject:localityName field is absent. Optional if the subject:localityName field and the subject:organizationName field, the subject:givenName field, or subject:surname field are present. Prohibited if the subject:organizationName field, subject:givenName field , or subject:surname field are isabsent. Contents: If present, the subject:stateOrProvinceName field MUST contain the Subject’s state or province information as verified under Section 3.2.2.1. If the subject:countryName field specifies the ISO 3166‐1 user‐assigned code of XX in accordance with Section 7.1.4.2.2(g), the subject:stateOrProvinceName field MAY contain the full name of the Subject’s country information as verified under Section 3.2.2.1.

g. Certificate Field: subject:postalCode (OID: 2.5.4.17)
Optional if the subject:organizationName, subject:givenName field, or subject:surname fields are ispresent. Prohibited if the subject:organizationName field, subject:givenName field, or subject:surname field are is absent.
Contents: If present, the subject:postalCode field MUST contain the Subject’s zip or postal information as verified under Section 3.2.2.1.

h. Certificate Field: subject:countryName (OID: 2.5.4.6)
Required if the subject:organizationName field, subject:givenName , or subject:surname field is present. Optional if the subject:organizationName field, subject:givenName field, and  subject:surname field are isabsent.
Contents: If the subject:organizationName field is present, the subject:countryName MUST contain the two‐letter ISO 3166‐1 country code associated with the location of the Subject verified under Section 3.2.2.1. If the subject:organizationName, subject:givenName field, and subject:surname  field are  is absent, the subject:countryName field MAY contain the two‐letter ISO 3166‐1 country code associated with the Subject as verified in accordance with Section 3.2.2.3. If a Country is not represented by an official ISO 3166‐1 country code, the CA MAY specify the ISO 3166‐1 user‐assigned code of XX indicating that an official ISO 3166‐1 alpha‐2 code has not been assigned.

i. Certificate Field: subject:organizationalUnitName
Optional.
Contents: The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 3.2 and the Certificate also contains subject:organizationName, subject:givenName, subject:surname, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 3.2.2.1.

7.1.6.1
…
If the Certificate asserts the policy identifier of 2.23.140.1.2.1, then it MUST NOT include organizationName, givenName, surname, streetAddress, localityName, stateOrProvinceName, or postalCode in the Subject field.
…

_______________________________________________

Public mailing list

Public at cabforum.org<mailto:Public at cabforum.org>

https://cabforum.org/mailman/listinfo/public

--
Cordiali saluti,

Adriano Santoni
ACTALIS S.p.A.
(Aruba Group)
_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

--
Cordiali saluti,

Adriano Santoni
ACTALIS S.p.A.
(Aruba Group)

--

Cordiali saluti,

Adriano Santoni
ACTALIS S.p.A.
(Aruba Group)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160824/5c677b62/attachment-0003.html>