<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<style type="text/css" id="owaParaStyle"></style>
</head>
<body fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Times New Roman;color: #000000;font-size: 12pt;">
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New"">Gerv,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New""> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New"">Thanks for your positive feedback. I am very sorry for our late in reply. We carefully examined and thought about how to propose minimum changes to the BRs to embrace subject naming rules
of existing PKI. We think there might be some existing PKIs like Taiwan Government PKI (GPKI) who have adopted X.500 directory naming conventions for certificate subjects. For example, the US Federal PKI (FPKI) seems to have similar situations because the
naming rules of device certificates in their certificate profiles are also slightly different with the naming rules of the BRs. If the existing naming rules can unambiguously identify certificate subjects under some specific jurisdiction, the BRs should embrace
them rather than asking them to add some BR-required subject name attributes that are not meaningfully or even can cause misleading in their existing naming conventions.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New""> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New"">The intrinsic difference between the existing X.500 directory naming conventions and the subject naming rules of the CAB BRs is that the X.500 namespace is hierarchical and therefore
the upper and lower entries identified with selected relative distinguished names (RDNs) represent "subordinate" relationship, while the current CAB BRs use the distinguished name (DN) to indicate to the identity and address of the organization and therefore
the naming rules require that at least one of the localityName attribute or stateOrProvinceName attribute needs to be included in the subject DN.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New""> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New"">With the X.500 directory naming conventions and the interpretation of "subordinate" relationship between RDNs, the DN of a national-level entity will not contain an RDN with the localityName
attribute or stateOrProvinceName attribute. For example, in the naming rules of Taiwan GPKI, the "Executive Yuan" (i.e, the Cabinet of our government) is a national-level entity and therefore the DN "C=TW, O=Executive Yuan" can unambiguously identify it. If
as required by the naming rules of the current CAB BRs, we add the RDN "L=Taipei City" to the DN of "Executive Yuan", its DN will become "C=TW, L=Taipei City, O=Executive Yuan" and therefore it will be an entity subordinate to the “Taipei City” in the directory
tree and no longer be a national-level entity. This is actually misleading from the perspective of X.500 naming conventions.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New""> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New"">Although there are intrinsic different interpretations between the existing X.500 directory naming conventions and the subject naming rules of the CAB BRs, fortunately the generated naming
forms are only slightly different. For a national-level entity, the DN in X.500 directory naming conventions will not contain an RDN with the localityName attribute or stateOrProvinceName attribute. However, for a local-level entity, the naming forms in X.500
naming conventions and the BRs naming rules are identical.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New""> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New"">We think in the most cases where the qualities (unambiguity and uniqueness) of subject DNs with the X.500 directory naming conventions (especially those endorsed by governments and based
on the officially registered organization information and organizational laws) are better than those of most commercial PKIs. Since our purpose is to improve the security of website identity, we recommend the CAB BRs should embrace those X.500 naming rules
of existing PKIs in addition to the current BRs naming rules.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New""> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New"">However, since there are so many naming attributes defined in X.500 (X.520) standard, we think that only those commonly used attributes should be accepted to prevent compatibility problems.
For commonly used naming attributes, we think it is safe to use naming attributes recommended by RFC 5280 (PKIX Certificate Profile), RFC 3739 (Qualified Certificate Profile), or ETSI EN 319 412 (EU eAIDS Certificate profiles).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New""> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New"">Based on the above-mentioned rationales, we recommend that the minimum change to the BRs is to add a sub-section k under the section 7.1.4.2.2 Subject Distinguished Nam Fields as follows:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New""> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New""><font color="#0000ff">7.1.4.2.2 Subject Distinguished Nam Fields<o:p></o:p></font></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New""><font color="#0000ff">……<o:p></o:p></font></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New""><font color="#0000ff">k. Accepting X.500 Directory Naming Conventions of Existing PKIs<o:p></o:p></font></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New""><font color="#0000ff">For PKIs where the X.500 directory naming conventions are adopted for subject distinguished names, the existing naming rules of those PKIs are acceptable if the
following conditions are satisfied:<o:p></o:p></font></span></p>
<p class="MsoListParagraph" style="margin-left:42.55pt;mso-para-margin-left:0gd;
text-indent:-18.55pt;mso-list:l0 level1 lfo1">
<!--[if !supportLists]--><font color="#0000ff"><span lang="EN-US" style="font-family:"Courier New";mso-fareast-font-family:"Courier New"">i.<span style="font-variant-numeric: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";">
</span></span><!--[endif]--><span lang="EN-US" style="font-family:"Courier New"">the naming rules can unambiguously identify the subject; and<o:p></o:p></span></font></p>
<p class="MsoListParagraph" style="margin-left:42.55pt;mso-para-margin-left:0gd;
text-indent:-18.55pt;mso-list:l0 level1 lfo1">
<!--[if !supportLists]--><font color="#0000ff"><span lang="EN-US" style="font-family:"Courier New";mso-fareast-font-family:"Courier New"">ii.<span style="font-variant-numeric: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";">
</span></span><!--[endif]--></font><span lang="EN-US" style="font-family:"Courier New""><font color="#0000ff">only commonly-used naming attributes recommended by RFC 5280, RFC 3739, or ETSI EN 319 412 are used in the naming rules.</font><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New""> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New"">Best Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Courier New"">Wen-Cheng Wang<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family: "Courier New";">On 10/03/17 10:18,
</span><span style="font-family: 新細明體, serif;">陳立群</span><span lang="EN-US" style="font-family: "Courier New";"> via Public wrote:<br>
> We hope this discussion is about getting an existing established PKI to<br>
> be BR-compliant by changing the BRs instead of changing the PKI.<br>
<br>
That is not unreasonable; can you present (or re-present) the minimum<br>
changes you think are necessary to the BRs in order to allow that to happen?<br>
<br>
Gerv</span></p>
</div>
<br>
________________________________________<br>
從: Public [public-bounces@cabforum.org] 代表 Gervase Markham via Public [public@cabforum.org]<br>
寄件日期: 2017年3月10日 下午 06:41<br>
至: CA/Browser Forum Public Discussion List<br>
副本: Gervase Markham<br>
主旨: Re: [cabfpub] Naming rules<br>
<br>
On 10/03/17 10:18, 陳立群 via Public wrote:<br>
> We hope this discussion is about getting an existing established PKI to<br>
> be BR-compliant by changing the BRs instead of changing the PKI.<br>
<br>
That is not unreasonable; can you present (or re-present) the minimum<br>
changes you think are necessary to the BRs in order to allow that to happen?<br>
<br>
Gerv<br>
<br>
_______________________________________________<br>
Public mailing list<br>
Public@cabforum.org<br>
https://cabforum.org/mailman/listinfo/public<br>
</div>
<B><BR><BR><font size="-1">本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件.
如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
<BR>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.</font></B>
</body>
</html>