[cabfpub] Naming rules

Fri Mar 24 22:19:55 UTC 2017

Ben,

On a technical level: How do you quantify, audit, and ensure uniquely
identifiable? Given that we do not have an X.500 Directory Information
Tree, it is easily possible for two such directories to exist, which within
their DIT are uniquely identifiable, but in their totality are not.

On Fri, Mar 24, 2017 at 5:46 PM, Ben Wilson via Public <public at cabforum.org>
wrote:

> Attached is a redlined snippet from the Baseline Requirements.  It
> proposes adding the following sentence(s) to sections on localityName and
> stateOrProvinceName:
>
>
>
> This field is also optional if the organization is uniquely identifiable
> by registration in a national-government-adopted X.500 directory that does
> not contain the [localityName/stateOrProvinceName] attribute.
>
>
>
> Feel free to modify and debate as necessary.
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Moudrick
> M. Dadashov via Public
> *Sent:* Wednesday, March 22, 2017 1:51 PM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Cc:* Moudrick M. Dadashov <md at ssc.lt>
>
> *Subject:* Re: [cabfpub] Naming rules
>
>
>
> Good question, the problem is that the entity requesting the cert has no
> idea what locality/state means.
>
>
>
> Thanks,
>
> M.D.
>
>
>
>
>
>
>
> Sent from Samsung tablet.
>
>
>
> -------- Original message --------
>
> From: Jeremy Rowley via Public <public at cabforum.org>
>
> Date: 3/21/17 15:51 (GMT+01:00)
>
> To: CA/Browser Forum Public Discussion List <public at cabforum.org>
>
> Cc: Jeremy Rowley <jeremy.rowley at digicert.com>
>
> Subject: Re: [cabfpub] Naming rules
>
>
>
> 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
> <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> 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.*
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170324/9f60e020/attachment-0003.html>