[cabf_validation] [cabfcert_policy] Amend BR subsections 7.1.4.2.2 d/e

Fri Jun 3 20:03:25 MST 2016

It seems like there is some confusion about the attributes that can go in a Subject Distinguished Name for a server authentication (“SSL”) certificate.

Country Name (2.5.4.6), State or Province Name (2.5.4.8), Locality Name (2.5.4.7), and Postal Code (2.5.4.17) are used to include a physical location of the entity.  State or Province Name, Locality Name, and Postal Code are best determined by checking with the Designated Operator listed by the Universal Postal Union (UPU) for the country in question.  If the country in not a UPU member, then the CA will need to identify the equivalent operator to determine appropriate content for the two fields.

On the other hand, Jurisdiction of Incorporation Country Name (1.3.6.1.4.1.311.60.2.1.3), Jurisdiction of Incorporation State or Province Name (1.3.6.1.4.1.311.60.2.1.2), and Jurisdiction of Incorporation Locality Name (1.3.6.1.4.1.311.60.2.1.1) are used to indicate where the entity is registered.  If the entity is registered at the country level, then only Jurisdiction of Incorporation Country Name will be in the certificate.  However if it is registered at a subdivision level, the the Jurisdiction of Incorporation State or Province Name and/or Jurisdiction of Incorporation Locality Name will be present.

To address the question asked directly:

Q: If there is a country-level corporation named “Farmer’s Association” of which physical address is located in Taipei City, with current Subject DN rule of BR, its Subject DN will be “C=TW, L=Taipei City, O=Farmer’s Association”. However, if there is also a city/county-level “Farmer’s Association” in Taipei City, its Subject DN will also be “C=TW, L=Taipei City, O=Farmer’s Association”. How do you distinguish them by DN?

A: You do not distinguish them by DN if there is no Postal Code or Jurisdiction of Incorporation information in the DN.  

As for how to handle Singapore, Monaco, and other city-states, one only needs to look to the UPU Postal addressing systems guide.

Singapore: http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/sgpEn.pdf
Monaco: http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/mcoEn.pdf
Vatican City: http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/vatEn.pdf				

All clearly show the name appearing both as the country and as a state/province/locality.  Other small countries such as Malta, San Marino, and Bahrain clearly are listed as having multiple localities.

For Taiwan, you seem to agree there is not an issue with finding an appropriate locality.  "But I have to say that  高雄市 (or Kaohsiung) should be  in the localityName field” makes it clear that there are localities.

Based on this, I do not see any need to change the BRs.

Thanks,
Peter

> On Jun 3, 2016, at 4:18 PM, Tim Hollebeek <THollebeek at trustwave.com> wrote:
> 
> These are generally less of a problem as they have a physical location (Department of Education, Washington, DC, US).
> 
> Just because an entity is registered at the federal level doesn't mean it doesn't have a locality or state.
> From: policyreview-bounces at cabforum.org <policyreview-bounces at cabforum.org> on behalf of Dimitris Zacharopoulos <jimmy at it.auth.gr>
> Sent: Friday, June 3, 2016 1:46:52 PM
> To: Doug Beattie
> Cc: policyreview at cabforum.org; 王文正; validation at cabforum.org; Dean Coclin; Rob Stradling; Kirk Hall; Rick Andrews
> Subject: Re: [cabfcert_policy] [cabf_validation] Amend BR subsections 7.1.4.2.2 d/e
>  
> I think all countries have some kind of central registry for some type of organizations (eg Universities, federal services). How should we handle these cases? 
> 
> DZ. 
> 
> 
> 
> On 3 Ιουν 2016, at 14:12, Doug Beattie <doug.beattie at globalsign.com> wrote:
> 
>> To summarize, you’re saying you must have Country and Organization and that you must have stateOrProvinceName and/or localityName unless < you reason>, in which case both stateOrProvinceName and localityName can be omitted.
>>  
>> Where <your reason> is: 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
>>  
>> You have one small copy/past issue in your recommendation, but I understand what you meant.
>>  
>> During the call yesterday we also discussed listing all of the countries where this is the case.  You listed about 31 countries with no stateOrProvinceName, but it’s not clear which of these also have no localityName, just the 3 in red?   I still think it would be a good idea to enumerate the entire list of Country codes where both stateOrProvinceName and localityName can be omitted so there is no confusion and compliance can be monitored.
>>  
>> Doug
>>  
>> From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of ???
>> Sent: Friday, June 3, 2016 6:56 AM
>> To: 'Rick Andrews' <Rick_Andrews at symantec.com>; 'Jeremy Rowley' <jeremy.rowley at digicert.com>;validation at cabforum.org; Peter Bowen <pzb at amzn.com>; 'Rob Stradling' <rob.stradling at comodo.com>;policyreview at cabforum.org
>> Cc: Dean Coclin <Dean_Coclin at symantec.com>; 王文正 <wcwang at cht.com.tw>; Kirk Hall <Kirk.Hall at entrust.com>
>> Subject: [cabf_validation] Amend BR subsections 7.1.4.2.2 d/e
>>  
>> Dear All,
>>  
>>      As yesterday’s validation working group phone call discussion about DN in small countries such as Singapore and Taiwan. I resend some discussions after Certificate Policy working group mailing list  phone call, Bugzilla and discussion in 33rd F2F meeting (as attached file) as below.  
>> After  discussions, we will write a pre-ballot to fix the issue.
>>  
>>      We suggest to amend BR 7.1.4.2.2 d/e.
>>  
>> Li-Chun CHEN 2016-02-05 01:29:17 MST 
>> After discussion in Chunghwa Telecom, Dr. Wen-Cheng Wang suggests to amend subsections 7.1.4.2.2 d/e as below: 
>>  
>> 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
>> 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.
>>  
>> 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) the subject:organizationName and subject:stateOrProvinceName 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.
>>  
>>       As for Peter, he e-mailed that
>> I think there is a misunderstanding.  The address represented in the certificate by the plain localityName and stateOrProvinceName attributes is the Applicant’s address of existence or operation, not their jurisdiction of incorporation.  The BRs note that a utility bill or bank statement can be used to verify the address.  
>>  
>> For example, https://crt.sh/?id=11206357&opt=cablint shows that the FQDN is www.fenton.com.tw. The contact information provided on the website (http://www.fenton.com.tw/index.php?route=information/contact) is 高雄市新興區民權一路251號24樓之2.  Assuming you verify that this is the address of the applicant, then you could include 高雄市 (or Kaohsiung) in the localityName or stateOrProvinceName field.
>>  
>> I don’t think there is any need to update the BRs for this case.  
>>  
>>  
>>       But I have to say that  高雄市 (or Kaohsiung) should be  in the localityName field. There is no State or Province in Taiwan for高雄市(or Kaohsiung).
>>  
>>      And Dr. Wen-Cheng Wang has replied to Peter as below:
>>  
>>    We know that the current BR tends to interpret the localityName and stateOrProvinceName attributes as identifying the subject’s address of existence or operation. However, to enforce this kind of interpretation and require the Subject DN must at least contain either the localityName and stateOrProvinceName attributes may cause problem in some situations, especially in some small country where organizations are allowed to be registered at country-level. For example, in Taiwan, a corporation can be registered at country-level but can also be register at city/county-level. If there is a country-level corporation named “Farmer’s Association” of which physical address is located in Taipei City, with current Subject DN rule of BR, its Subject DN will be “C=TW, L=Taipei City, O=Farmer’s Association”. However, if there is also a city/county-level “Farmer’s Association” in Taipei City, its Subject DN will also be “C=TW, L=Taipei City, O=Farmer’s Association”. How do you distinguish them by DN?
>>  
>> I do not understand why we need to enforce require the Subject DN must at least contain either the localityName and stateOrProvinceName attributes if the registered organizational name of a country-level corporation/organization is already guaranteed to be unique under the country name?
>>  
>> The following diagram is taken from Annex B of ITU-T X.521 (Suggested name form and Directory information tree structures). Please note path 1 -> 3, it suggests that there is no need to include a Locality attribute in the directory name of a country-level organization.
>> <image001.png>
>>  
>>  
>> Sincerely Yours,
>>  
>>         Li-Chun CHEN
>>         Chunghwa Telecom Co. Ltd.
>>  
>>  
>>  
>> 本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
>> 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.
>>  
>>  
>> _______________________________________________
>> Policyreview mailing list
>> Policyreview at cabforum.org
>> https://cabforum.org/mailman/listinfo/policyreview
> 
> 
> This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
> _______________________________________________
> Policyreview mailing list
> Policyreview at cabforum.org
> https://cabforum.org/mailman/listinfo/policyreview