[cabfpub] Suggestion to amend BR Section7.1.4.2.2d/e RE: EV Gudelines section 9.2.5 & X.520

Wed Jul 20 16:31:50 UTC 2016

Bonjour,

See my answers inline.

Cordialement,
Erwann Abalea

Le 20 juil. 2016 à 11:48, 陳立群 <realsky at cht.com.tw<mailto:realsky at cht.com.tw>> a écrit :

    I reply as below, for readers easily to see what Erwann wrote were (https://cabforum.org/pipermail/public/2016-July/007996.html) , what I reply now are, I suggest to read attached pdf file, what I reply are in red or blue color.

Bonsoir,

About small countries that haven’t set up any state or province.

X.520 definition for the stateOrProvinceName attribute is (from 201210 edition):
The State or Province Name attribute type specifies a state or province. When used as a component of a directory name, it identifies a geographical subdivision in which the named object is physically located or with which it is associated in some other important way.

«Geographical subdivision » can mean anything. Maybe some would disagree, but I think that a CA can stretch it pretty easily while respecting the BRs.
If you want to follow the intent of the « province », since this latin-based word designates an administrative subdivision, it can even be a city or a village, and doesn’t necessarily mean a State in the US way. All the countries listed in Note 2 have cities.

=====> I think X.520 clearly specifies that 'The State or Province Name attribute type specifies a state or province.' (This is the first sentence of the stateOrProvinceName definition in X.520.) Should CAB Forum encourage the ambiguity that CAs may put the name of administrative subdivision at any level (such as a city, a county, a town, or a village) into stateOrProvinceName attribute? No, I don't think so.

But X.520 doesn’t define what a state or a province is or isn’t. Nor does X.520 define what is or isn’t a valid country, or what is or isn’t a valid organization.

X.520 defines a set of attributes, organizes them into types (labelling, geographical, organizational, etc), and gives some guidance on the intent of these attributes.

Looking at different sources to get the definition of « province », they all agree on the fact that a province is at least an administrative division of a country. The Oxford Dictionary of English defines province as « a principal administrative division of a country or empire » (here, principal is still subjective). A county, town, city, or even a village is an administrative division. In small countries, city may be the highest level of administrative division.

X.520 hasn’t defined an attribute intended to hold a brand name (DBA), and the CABForum has decided that the organizationName attribute can hold either the legal name (complete or with abbreviations) or the brand name, and even a natural person’s name (for IV certs).

About the uniqueness of an organizationName at a country level.

OV/IV certificates are not meant to unambiguously identify the subject named in the certificate. That role is left for EV certificates.

====> I am really surprised to see the interpretation that 'OV/IV certificates are not meant to unambiguously identify the subject named in the certificate' in the CAB Forum. Is this a common cognition of the CAB Forum? The fundamental function of a public-key certificate is to assert the binding between the subject identity and its public key, isn't it?

Yes. Assert a binding between a public key and an identity, and verify that the applicant has the right to claim this identity. Not assert that this identity is not shared with someone else. Not assert that the bound name is the only possible representation of the entity’s name.
If you need these guarantees, then you need to define a set of name canonicalization rules.

The value of a CA in the internet community is to act as a Trusted Third Party (TTP) which is responsible to verify the identity of the subject and then guarantee the binding between the subject identity and its public key.

Again, that’s right. The CA verifies the claimed identity, and binds it with the public key. Nothing more for DV/OV/IV.

I think that OV/IV certificates still need to unambiguously identify the subject named in the certificate. The difference between OV/IV certificates and EV certificates is that they provide different level of assurance regarding the identity information verified. I understand that there does not exist a global X.500 directory. However, A CA should still make its best to unambiguously identify the subject named in the OV/IV certificate. At least, the CA should guarantee that two different entities never share the same subject DN, otherwise how the relying parties can distinguish which organization/individual is actually behind the OV/IV certificate?

This is the purpose of EV. Attributes have been defined to hold the incorporation/registration informations, the business category is included in the name, and a non ambiguous naming scheme has been defined.

I have replied in previous email to Peter in https://cabforum.org/pipermail/public/2016-June/007897.html as below

For IV SSL certificate or citizen certificates, we can add unique serial number in Subject Distinguished Names to two different entities have the same names. (You said EV SSL certificates solve the problem, but don’t forget that EV SSL Certificates will not be issued to individuals, only be issued to Private Organization, Government Entities, Business entities and non-profit international organizations

Let’s suppose it's something we want to do for DV/OV/IV.
We can add such a unique serialNumber attribute. This serialNumber needs to be shared among all CAs, either by constituting a common database, or by combining some sort of identification document type (ID card, passport, whatever) and the number. If we don’t have this globally unique number, then CA1 could assign serialNumber 1 for user A, CA2 could assign serialNumber 1 to user B, user A and user B could be homonyms, and the desired goal isn’t achieved (relying party is unable to distinguish the identities).
Is that something we want for natural persons, worldwide?

Note that in https://cabforum.org/pipermail/public/2016-July/007912.html, I have replied to Peter in RFC 3739 there are Qualified Certificates Profiles.

I suggest you to read

I know about Qualified Certificates. CABF OV/IV are not Qualified Certificates. Even EV are not Qualified Certificates. I don’t want to impose Qualified Certificates to every CA.

3.1.2. Subject

The serialNumber attribute type SHALL, when present, be used to differentiate between names where the subject field would otherwise be identical. This attribute has no defined semantics beyond ensuring uniqueness of subject names. It MAY contain a number or code assigned by the CA or an identifier assigned by a government or civil authority. It is the CA's responsibility to ensure that the serialNumber is sufficient to resolve any subject name collisions.

Now, the relying party will be able to distinguish identity A and identity B even when names are shared (homonyms, company name, brands), but within a given CA only. In a sense, what will be unique is the combination issuerName+subjectName, not subjectName alone.

So for Taiwan’s GPKI, we can resolve any subject name collisions for government entities’ SSL certificates or citizen certificates more than 13 years.

For example, in an IV certificate, there can be more than one individuals named John Malkovich, living in the same country, same province, same city. Only one of them will obviously be able to have thejohnmalkoti.ch<http://johnmalkoti.ch/> domain, if it exists (it doesn’t).

Talking about OV certificates, even if it’s not possible to have 2 companies with the same name in the same jurisdiction, it’s possible to have 2 certificates having the same name representing 2 different entities. For example «C=UT, ST=MyVillage, O=XXXX», if XXXX is both a company and a brand (DBA).

Combine OV and IV, and «C=UT, ST=MyVillage, O=XXXX» can represent 3 different things, if XXXX is also the full name of an individual and the CA chooses to place this full name in the O field instead of GN/SN. (for a country named Utopia)

The rule for an OV/IV is something like « if you can provide evidence of the claimed identity, it’s good».

Again, if you want to disambiguate claimed identities, you’re free to add other attributes, or provide an EV certificate.

I don’t support the proposed BR changes, they only add complexity without any real benefit.

Looking at the example certificates:

  *   certificate 1 is not problematic; if you want a less cluttered certificate, go for a DV; wether VA is really a country or not is left as an exercise (it’s a territory for me, but I’m not so difficult)

===>VA is really a country, they don’t set up a government entity whose legal name is called Vatican City State or Vatican City Province, but https://crt.sh/?q=98+ef+2b+4c+43+39+ae+04+3b+bd+55+08+59+b2+b7+b4+ee+76+cb+af

A country without a government?
The government is the Holy See, maintains diplomatic relations with other states, has an observer status at UN (non-member), and its sovereign territory is the Vatican.
The Vatican is only a territory.
I’m sure attorneys and jurists following the list may find interest reading about the situation of Holy See and Vatican.

The Subject DN is
commonName=*.catholica.va
organizationName=Department of Telecommunications
localityName=Vatican City
stateOrProvinceName=Vatican City State
countryName =VA

The subject DN should be
commonName=*.catholica.va
organizationName=Department of Telecommunications
countryName =VA

It is enough to identify the domain name owner in Vatican.

What is your goal? Asserting the smallest unambiguous possible name, or assert a correct name? OV/EV/IV goal is the second.

  *   certificate 2 is not wrong per se; Taichung City being a geographical subdivision of Taiwan, an administrative division, and a city, it’s not wrong to have Taichung in both the ST and L attributes — second example is « ST=Taiwan, L=Kaohsiung»; Taiwan being a province of the Taiwan country, and Kaohsiung being a city, it’s not wrong

===>Taichung City and Kaohsiung City are 6 special municipalities (Traditional Chinese<https://en.wikipedia.org/wiki/Traditional_Chinese_characters>: 直轄市) or called Yuan<https://en.wikipedia.org/wiki/Executive_Yuan>-controlled municipalities (院轄市),theYuan is referred to the Executive Yuan. Special municipalities have the rank of province.

[…]
isions of this Act, or to matters that are to be handled by such bodies in accordance with law and where such bodies are responsible for policy formulation and implementation.
For government entity's DN and OID, our government set up a site at oid.nat.gov.tw<http://oid.nat.gov.tw/>, it is UTF 8 code in Traditional Chinese. It is no need to put S=Taiwan in DN for entities under Taichung City and Kaohsiung City.

And this government failed to follow normalized practice.
The OID arc 2.16 is governed by rules listed in X.660, and those rules were not followed. 2.16.886 is NOT an OID that the government of Taiwan can use.
Yet you want to write rules that cover the 200+ countries and their particularities, and ask all CAs to follow them…

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160720/9c46b0b2/attachment-0003.html>