<html><div>Jeremy,</div><div><br>
</div><div> I suggest to read <a href="https://cabforum.org/pipermail/public/2017-March/010123.html">https://cabforum.org/pipermail/public/2017-March/010123.html</a> first. I q<span class="short_text" id="result_box" lang="en"><span>uote Wen-Cheng's replying in previous URL as follows:</span></span><span class="trans-verified-button goog-toolbar-button" id="t-served-community-button" role="button" aria-hidden="true" style="display: none;" unselectable="on"><span class="jfk-button-img" unselectable="on"></span></span></div><div><br>
</div><div> " 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.<br>
<br>
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.<br>
<br>
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. "</div><div><br>
</div><div><br>
</div><div><br>
</div><div><br>
</div><div> Now I take some example. </div><div> </div><div>The subject DN for a central government entity in Taiwan, for example as below:</div><div>C=TW, O=Executive Yuan, OU=National Development Council</div><div>So the Subject DN of a NDC’s SSL certificate is<br>
C = TW, O = Executive Yuan, OU =National Development Council, CN = <a href="http://www.cp.gov.tw">www.cp.gov.tw</a>, SERIALNUMBER = 0000000010026835</div><div><br>
</div><div>The subject DN for a local government entity, for example as below:</div><div>C = TW, L = Taichung City , O = City Government, OU = Civil Affairs Bureau</div><div>the Subject DN of this local government entity's SSL certificate is </div><div>C = TW, L = Taichung City , O = City Government, OU = Civil Affairs Bureau, CN = eform.taichung.gov.tw, SERIALNUMBER = 0000000010026435 </div><div><br>
</div><div> In Taiwan, according our Company Act, the company name must be unique for the whole country. Please see English version of our Company Act in <br>
<a href="http://law.moj.gov.tw/Eng/LawClass/LawAll.aspx?PCode=J0080001">http://law.moj.gov.tw/Eng/LawClass/LawAll.aspx?PCode=J0080001</a><br>
Company Act article 18 said<br>
"No company may use a corporate name which is identical with that of another company."</div><div><br>
</div><div> In Taiwan, according our Company Law, the company name must be unique for the whole country. Furthermore, our Company Law requires the company to register its business location which will be some city or county. </div><div> This is an example where the legally naming uniqueness scope for an entity is not the same as where the entity is legally located. <br>
In Taiwan, since the company name must be unique for the whole country, the subject DN for a company, such as Chunghwa Telecom, should look like "C=TW, O=Chunghwa Telecom Co., Ltd"</div><div><br>
This subject DN already uniquely identifies the company. <br>
<br>
If we specify the subject DN as "C=TW, L=Taipei City, O=Chunghwa Telecom Co., Ltd.", that will mean it is a company registered in Taipei City in Taiwan's Goverenment DIT. This will not conform to our Company Law because companies in Taiwan are registered in the country level not in the municipal level.</div><div><br>
</div><div> On the other hand, in Taiwan, we have small businesses (such as stores,or "business entitiy" in EVGL) that are established and registered according to our Business Registration Law (<a href="http://law.moj.gov.tw/Eng/LawClass/LawAll.aspx?PCode=J0080004">http://law.moj.gov.tw/Eng/LawClass/LawAll.aspx?PCode=J0080004</a>). <br>
In Taiwan, small businesses are registered in municipal level (that will be a city ,a county or a special municipality ). <br>
The Business Registration Law requires that the name of the small business must be unique with the municipality ( where it is registered). See Article 28.</div><div><br>
</div><div> For example, there might be a small business named "ABC Store" registered in New Taipei City, while there might be another "ABC Store" registered in Pingtung county. <br>
Therefore, the suitable subject DN for these two small businesses will be <br>
“C=TW, L=New Taipei City, O=ABC Store" and <br>
“C=TW, L= Pingtung county, O=ABC Store" respectively.</div><div><br>
</div><div> So the subject DN of these two small business's SSL servers will be<br>
</div><div>“C=TW, L=New Taipei City, O=ABC Store , Common Name=FQDN of ABC Store regitered in New Taipei city" and <br>
“C=TW, L= Pingtung county, O=ABC Store, Common Name=FQDN of ABC Store regitered in Pingtung county" respectively.</div><div><br>
</div><div><br>
</div><div><br>
</div><div> 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”. </div><div><br>
</div><div> 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?</div><div><br>
</div><div> Please see attached image file 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. </div><div> </div><div> </div><div> I hope above information is helpful. Thank you.</div><div><br>
</div><div> Li-Chun Chen</div><div>
<span style="color: rgb(22, 22, 22); font-family: 微軟正黑體; font-size: 26pt; font-weight: bold; language: en-US; mso-ascii-font-family: 微軟正黑體; mso-fareast-font-family: 微軟正黑體; mso-bidi-font-family: +mn-cs;"><br>
</span></div><div><br>
-----Original message-----<br>
<b>From:</b>Jeremy Rowley via Public<public@cabforum.org><br>
<b>To:</b>CA/Browser Forum Public Discussion List<public@cabforum.org><br>
<b>Cc:</b>Jeremy Rowley<jeremy.rowley@digicert.com><br>
<b>Date: </b> Tue, 21 Mar 2017 22:51:41<br>
<b>Subject:</b> [外部郵件] Re: [cabfpub] Naming rules<br>
<meta name="Generator" content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:PMingLiU;
panose-1:2 2 5 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@PMingLiU";
panose-1:2 2 5 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"PMingLiU",serif;
mso-fareast-language:ZH-TW;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"PMingLiU",serif;
mso-fareast-language:ZH-TW;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></div><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--><x-body><div class="WordSection1"><p class="MsoNormal"><span style='font-family: "Calibri",sans-serif; font-size: 11pt; mso-fareast-language: EN-US;'>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? <o:p></o:p></span></p><p class="MsoNormal"><a name="_MailEndCompose"><span style='font-family: "Calibri",sans-serif; font-size: 11pt; mso-fareast-language: EN-US;'><o:p> </o:p></span></a></p><span style="mso-bookmark: _MailEndCompose;"></span><div><div style="border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(225, 225, 225) currentColor currentColor; padding: 3pt 0in 0in; border-image: none;"><p class="MsoNormal"><b><span style='font-family: "Calibri",sans-serif; font-size: 11pt;'>From:</span></b><span style='font-family: "Calibri",sans-serif; font-size: 11pt;'> Public [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>??? via Public<br>
<b>Sent:</b> Sunday, March 19, 2017 9:23 AM<br>
<b>To:</b> CA/Browser Forum Public Discussion List <public@cabforum.org><br>
<b>Cc:</b> </span><span lang="ZH-TW" style="font-size: 11pt;">王文正</span><span style='font-family: "Calibri",sans-serif; font-size: 11pt;'> <wcwang@cht.com.tw><br>
<b>Subject:</b> Re: [cabfpub] Naming rules<o:p></o:p></span></p></div></div><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>Peter,</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>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.</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>As for your argument about "there are always localities that can be added into the subject DN", please see my reply inline.</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"> <o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>> On March 10, 2017, at 11:33 PM, Peter Bowen <</span> <span style='font-family: "Courier New";'><a href="mailto:pzb@amzn.com">pzb@amzn.com</a>> wrote:</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>> [snip]</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>> Based on everything you have provided so far, there is no </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>> evidence that Taiwan does not have localities (cities, </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>> towns, villages, or similar) or that they are not used in </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>> postal addressing. Much to the contrary, every postal </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>> address example you have provided has included a </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>> locality. Therefore this appears to be a situation where </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>> the PKI does not want to change (possibly for quite valid </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>> reasons) rather than cannot change.</span><br>
<br>
<o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>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?</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>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.</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>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?</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>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:</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>C=TW, O=Executive Yuan</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>This is unambiguous naming for Taiwan people because everybody knows that there is only one Executive Yuan in Taiwan.</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>If you want to enforce adding a localityName in the DN of the Executive Yuan of Taiwan, the DN will looks like:</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>C=TW, L=Taipei City, O=Executive Yuan</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>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?</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>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:</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>C=US, o=U.S. Government, [ou=department], [ou=agency], [ou=structural_container], cn=device name</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>With the X.500 naming conventions, the name form will not be:</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>C=US, S="Washington, D.C. ", o=U.S. Government, [ou=department], [ou=agency], [ou=structural_container], cn=device name</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>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:</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>C = TW</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>S = Taichung</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>L = Taichung</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>O = COTA Commercial Bank</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>OU = ITD</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>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?</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>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.</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>Besides, please note in the beginning of section 3.2.2 of the BRs, it says:</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>If the Applicant requests a Certificate that will contain Subject Identity Information comprised <span style="color: red;">only</span> 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.</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"> <o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>Please not that it says "</span> <span style='font-family: "Courier New";'>Subject Identity Information comprised <span style="color: red;">only </span>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?</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'> </span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>Best Regards,</span><o:p></o:p></p><p class="MsoNormal" style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto;"><span style='font-family: "Courier New";'>Wen-Cheng Wang</span><o:p></o:p></p><p class="MsoNormal"><b><br>
<br>
</b><b><span lang="ZH-TW" style="font-size: 10pt;">本信件可能包含中華電信股份有限公司機密資訊</span></b><b><span style="font-size: 10pt;">,<span lang="ZH-TW">非指定之收件者</span>,<span lang="ZH-TW">請勿蒐集、處理或利用本信件內容</span>,<span lang="ZH-TW">並請銷毀此信件</span>. <span lang="ZH-TW">如為指定收件者</span>,<span lang="ZH-TW">應確實保護郵件中本公司之營業機密及個人資料</span>,<span lang="ZH-TW">不得任意傳佈或揭露</span>,<span lang="ZH-TW">並應自行確認本郵件之附檔與超連結之安全性</span>,<span lang="ZH-TW">以共同善盡資訊安全與個資保護責任</span>. <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.</span></b> <o:p></o:p></p></div></x-body><div><x-body></x-body>_______________________________________________<br>
Public mailing list<br>
Public@cabforum.org<br>
<a href="https://cabforum.org/mailman/listinfo/public" target="new_win">https://cabforum.org/mailman/listinfo/public</a><br>
<br>
</div></html><br><html><div><div>本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. </div><div>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.</div></div><div><br></div><div><br></div></html>