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

[陳立群]

1. In RFC 3739- Internet X.509 Public Key Infrastructure: Qualified Certificates Profile

 

2.4.  Uniqueness of names

 

   Distinguished name is originally defined in X.501 [X.501] as a  representation of a directory name, defined as a construct that

identifies a particular object from among a set of all objects.  The distinguished name MUST be unique for each subject entity certified by the one CA as defined by the issuer name field, for the whole life   time of the CA.

 

     So it need not as you said that the erialNumber attribute in Subject Name should be shared among all CAs. 

 

      But in previous discussion and meeting, we have find Peter’s The UPU guidance may not be useful. 

 

      2. You said why not change to use EV SSL certificate, but maybe some countries setup their government but they only want to issue OV SSL certificates. 

 The White House has mandated that all public-facing Web sites of the federal government must implement HTTPS within the next two years from last year. But you can see https://www.whitehouse.gov/, it is an OV wild card SSL certificate installed. 

 

 

       3. We only reflect a fact that  Taiwan’s government has set up their GPKI’s certificates profile, rule for DN and DIT more than twelve years, and 2.16.886 you said are in Subject Directory Attribute, they are for government entities’ certificates’ applications, not for web SSL certificates. 

 

      If our government changes their representation of Subject DN as current BR, they will confusion and conflict for government entities certificates such as associate private key stored in IC card.

Please see the proposed amend versions of BR Section7.1.4.2.2d/e by Ben or Wen-Cheng, again as below, just release the BR for small countries/jurisdictions, if they do not set up any state or province in their law or government entities. Or if the subject:organizationName and subject:countryName fields are present and the country/jurisdiction specified by the subject:countryName field has a centralized registry for that kind of organizations so that the organization name specified by the subject:organizationName field is "unique" in the entire country/jurisdiction. 

And to prevent that some CAs misplaced absence province or state name in subject name.  

     The amended version will not affect other CAs that use current BR rule to interpret Subject DN.

 

   Or we can use the minimum set of Subject Name concept of ETSI’s legal or web SSL certificates profiles as Moudrick offered those documents.  https://portal.etsi.org//TBSiteMap/ESI/ESIActivities.aspx <https://portal.etsi.org/TBSiteMap/ESI/ESIActivities.aspx>  

–    ETSI EN 319 412-1 "Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common data structures".

–     ETSI EN 319 412-3 "Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 3: Certificate profile for certificates issued to legal persons".

–    C.319 412-4 v1.1.1: Certificate profile for web site certificates issued to organisations

 

 


BR V1.3.4

Dr. Ben Wilson of DigiCert’s version


7.1.4.2.2 Subject Distinguished Name Fields

d. Certificate Field: subject:localityName (OID: 2.5.4.7) 

Required if the subject:organizationName field is present and the subject:stateOrProvinceName field is absent.

Optional if the subject:organizationName and subject:stateOrProvinceName fields are present.

e. Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8)

Required if the subject:organizationName field is present and subject:localityName field is absent.

Optional if subject:organizationName and subject:localityName fields are present.

7.1.4.2.2 Subject Distinguished Name Fields

d.Certificate Field: subject:localityName (OID: 2.5.4.7) 

Required if the subject:organizationName field is present and the subject:stateOrProvinceName field is absent.

Optional if: (a) the subject:organizationName and subject:stateOrProvinceName fields are present, or (b) if the country name provided under subsection g. is Taiwan (TW), Singapore (SG)[Note 2], etc..

 

e.Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8) 

Required if the subject:organizationName field is present and subject:localityName field is absent.

Optional if: (a) subject:organizationName and subject:localityName fields are present, or (b) if the country name provided under subsection g. is Taiwan (TW), Singapore (SG), etc..


V1.3.4

Dr. Wen-Cheng Wang of Chunghwa Telecom’s Version


7.1.4.2.2 Subject Distinguished Name Fields

d. Certificate Field: subject:localityName (OID: 2.5.4.7) 

Required if the subject:organizationName field is present and the subject:stateOrProvinceName field is absent.

Optional if the subject:organizationName and subject:stateOrProvinceName fields are present.

e. Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8)

Required if the subject:organizationName field is present and subject:localityName field is absent.

Optional if subject:organizationName and subject:localityName fields are present.

7.1.4.2.2 Subject Distinguished Name Fields

d.Certificate Field: subject:localityName (OID: 2.5.4.7) 

Required if the subject:organizationName field is present and the subject:stateOrProvinceName field is absent.

Optional if: (a) the subject:organizationName and subject:stateOrProvinceName fields are or (b) if the subject:organizationName and subject:countryName fields are present and the country/jurisdiction specified by the subject:countryName field has a centralized registry for that kind of organizations so that the organization name specified by the subject:organizationName field is "unique" in the entire country/jurisdiction.

Normally, situation (b) may exist in small countries/jurisdictions such as Singapore (SG), Taiwan (TW), etc.

 


V1.3.4

Dr. Wen-Cheng Wang of Chunghwa Telecom’s Version

	
7.1.4.2.2 Subject Distinguished Name Fields

 

e.Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8) 

Required if the subject:organizationName field is present and subject:localityName field is absent.

Optional if: (a) subject:organizationName and subject:localityName fields are present, or (b) if the subject:organizationName and subject:countryName fields are present and the country/jurisdiction specified by the subject:countryName field has a centralized registry for that kind of organizations so that the organization name specified by the subject:organizationName field is "unique" in the entire country/jurisdiction.

Normally, situation (b) may exist in small countries/jurisdictions such as Singapore (SG), Taiwan (TW), etc.

 

 

Li-Chun CHEN

From: Erwann Abalea [mailto:Erwann.Abalea at docusign.com] 
Sent: Thursday, July 21, 2016 12:32 AM
To: 陳立群
Cc: CABFPub; Ben Wilson
Subject: Re: [cabfpub] Suggestion to amend BR Section7.1.4.2.2d/e RE: EV Gudelines section 9.2.5 & X.520

 

Bonjour, 

 

See my answers inline.

 

Cordialement,

Erwann Abalea

 

Le 20 juil. 2016 à 11:48, 陳立群 <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> 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> 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> 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 the <http://johnmalkoti.ch/> 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> 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  <https://en.wikipedia.org/wiki/Traditional_Chinese_characters> Chinese: 直轄市) or called  <https://en.wikipedia.org/wiki/Executive_Yuan> 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  <http://oid.nat.gov.tw/> 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…

 

 



本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160728/107a6afc/attachment-0003.html>