[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. 

 

 <mailto:lcchen.cissp at gmail.com> 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
<https://crt.sh/?id=11206357&opt=cablint> &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.

cid:image001.png at 01D169D3.5ED33150

 

 

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20160603/85952950/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 30620 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20160603/85952950/attachment-0001.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Suggestions-to-Correct-Documents.pdf
Type: application/pdf
Size: 1689045 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20160603/85952950/attachment-0001.pdf