[cabfpub] Naming rules

Tue Mar 21 14:51:41 UTC 2017

Despite the discussion today, I’m still not clear on why the cert can’t
include locality information. Although there is a national registry, what
prohibits a CA from adding the Locality information based on address? Even
if there are multiple localities for an organization, does that matter?
Can’t the entity requesting the cert decide which one they want included? 

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of ??? via
Public
Sent: Sunday, March 19, 2017 9:23 AM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: 王文正 <wcwang at cht.com.tw>
Subject: Re: [cabfpub] Naming rules

Peter,

I have proposed a minimum change to the BRs to accommodate X.500 directory
naming rules of existing PKIs in my reply to Gerv’s mail. In that reply, I
have made the rationales why the BRs should embrace the existing X.500
naming rules. I also explain it is not proper to add an RDN with the
localityName attribute or stateOrProvinceName attribute to the DN of a
national-level entity, because doing so will cause misleading under the
X.500 namespace. Therefore, I would not repeat my rationales here.

As for your argument about "there are always localities that can be added
into the subject DN", please see my reply inline.

> On March 10, 2017, at 11:33 PM, Peter Bowen < pzb at amzn.com
<mailto:pzb at amzn.com> > wrote:

> [snip]

> Based on everything you have provided so far, there is no 

> evidence that Taiwan does not have localities (cities, 

> towns, villages, or similar) or that they are not used in 

> postal addressing.  Much to the contrary, every postal 

> address example you have provided has included a 

> locality.  Therefore this appears to be a situation where 

> the PKI does not want to change (possibly for quite valid 

> reasons) rather than cannot change.

Yes, there are always different levels of "localities" under a jurisdiction
or country. We never said Taiwan does not have localities. What we argue is
that does it makes sense to force adding an RDN with the localityName
attribute or stateOrProvinceName attribute to the DN of a national-level
entity?

I had not participated in the early stage discussions of CAB Forum,
therefore I just do not understand why CAB though it is so important to
include the applicant's location of existence or operation so that the BRs
mandate at least one of the localityName attribute or stateOrProvinceName
attribute must exist in the subject DN? I guess it is because the only
Subject Identity Information that many commercial CAs can verify is whether
the applicant actually exists and is in operation and they have no way to
guarantee the uniqueness of the subject DN because they have no link to the
official registration database maintained by the government. Therefore, the
CAB BRs simply leveraged the naming attributes to indicate the identity and
location of the applicant but avoid interpreting RDNs as "subordinate"
relationships and do not guarantee the uniqueness of the subject DN.

However, there are existing PKIs where the X.500 directory naming rules are
endorsed by the government and CAs in the PKI have the authority to link to
the official registration database maintained by the government. Those PKIs
actually provide better quality of subject identity information. I think the
purpose of CAB forum is to improve the security of website identities, why
not we embrace the subject identity information provided by these existing
PKIs if they would not cause any compatibility problems?

As I mentioned, in the X.500 naming conventions, the DN of a national-level
entity will not need to have a RDN with the localityName attribute or
stateOrProvinceName attribute. For example, the Executive Yuan (i.e., the
Cabinet of our government) in the X.500 naming rules of Taiwan Government
PKI (GPKI) will be:

C=TW, O=Executive Yuan

This is unambiguous naming for Taiwan people because everybody knows that
there is only one Executive Yuan in Taiwan.

If you want to enforce adding a localityName in the DN of the Executive Yuan
of Taiwan, the DN will looks like:

C=TW, L=Taipei City, O=Executive Yuan

This is not only not suitable for the "subordinate" naming conventions of
the X.500 but also misleading to Taiwan people. Besides, the executive yuan
is a national-level entity, it has many offices all over the country, and
the question is which location should be added into its DN?

I believe this is the same reason why in the Common Certificate Policy of US
FPKI, the naming form of the Device names is defined as follows:

C=US, o=U.S. Government, [ou=department],  [ou=agency],
[ou=structural_container], cn=device name

With the X.500 naming conventions, the name form will not be:

C=US, S="Washington, D.C. ", o=U.S. Government, [ou=department],
[ou=agency], [ou=structural_container], cn=device name

In addition, I have seen some foreign CAs issuing SSL certificates to
customers in Taiwan with strange Subject DNs. Their put improper values in
the localityName attribute or stateOrProvinceName attribute simply because
the want to claim they comply the naming rules of the BRs. However, the
values of the localityName attribute or stateOrProvinceName attribute are
actually not meaningful or even misleading. For example, a subject DN might
looks like this:

C = TW

S = Taichung

L = Taichung

O = COTA Commercial Bank

OU = ITD

This naming form comply the BRs, but ironically there is never a state or
province name named "Taichung" in Taiwan. Is this the naming that CAB forum
wants?

I hope you can support my suggestion for the BRs to embrace the existing
X.500 naming rules. We need just do a little change to the BRs, and then we
do not need to enforce the existing PKIs to break the X.500 naming rules and
result some strange subject DNs.

Besides, please note in the beginning of section 3.2.2 of the BRs, it says:

If the Applicant requests a Certificate that will contain Subject Identity
Information comprised only of the countryName field, then the CA SHALL
verify the country associated with the Subject using a verification process
meeting the requirements of Section 3.2.2.3 and that is described in the
CA's Certificate Policy and/or Certification Practice Statement.

Please not that it says " Subject Identity Information comprised only of the
countryName field " Does not that imply that the subject can be a
national-level entity so that it can comprise only the countryName field and
without the localityName attribute or stateOrProvinceName attribute?
However, the section 7.1.4.2.2 of the BRs mandates at least one of the
localityName attribute or stateOrProvinceName attribute must exist in the
subject DN. Isn't that a conflict between Section 3.2.2.3 and Section 7.1.4.
2.2?

Best Regards,

Wen-Cheng Wang

本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利
用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密
及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共
同善盡資訊安全與個資保護責任. 
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/20170321/5191c322/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170321/5191c322/attachment-0001.p7s>