<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Cambria">Hi Peter,<br>
<br>
I agree with your core question but </font><font face="Cambria">if
the Forum decides to require Subject's postal address, </font><font
face="Cambria">the long lasting locality/state question
unfortunately will remain open.<br>
<br>
Maybe this is because of misunderstanding of government managed
registries - in typical implementations a registry would contain
both the entity's name AND registration address. So, if Subject
name has been obtained from this registry why not use also
Subject's postal address as its written officially.<br>
<br>
Obviously it's CA's responsibility to map the postal address into
appropriate certificate fields - if the original postal address
from the registry doesn't contain locality or state, accordingly
they won't appear in the certificate.<br>
<br>
I don't see why the proposed amendment needs any software modification.<br>
<br>
Thanks,<br>
M.D.</font><br>
<br>
<br>
<div class="moz-cite-prefix">On 3/27/2017 4:40 PM, Peter Bowen via
Public wrote:<br>
</div>
<blockquote cite="mid:80F13197-5C50-4654-AA5D-32F132407E07@amzn.com"
type="cite">
<pre wrap="">Li-Chun,
It was good to see you last week. We have discussed this for many months (<a class="moz-txt-link-freetext" href="https://cabforum.org/pipermail/policyreview/2016-January/000207.html">https://cabforum.org/pipermail/policyreview/2016-January/000207.html</a> is the first email I can find on this, which si from January 2016).
I do not think further discussion will help here. The core question is whether the Forum wants to continue require providing postal addressing information in the Subject Name, with the full understanding that multiple independent unrelated entities may have the same Name. Alternatively, the question is whether the Forum believes that accepting existing DITs (and associated CAs) without modification is a desired policy or whether existing DITs (and associated CAs) should be required to modify their operations to come into compliance.
Given this has continued for over a year, I strongly suggest that Chunghwa Telecom propose a ballot. If the ballot either cannot get endorsers or fails a vote, we should consider this issue resolved.
Thanks,
Peter
</pre>
<blockquote type="cite">
<pre wrap="">On Mar 27, 2017, at 6:27 AM, 陳立群 via Public <a class="moz-txt-link-rfc2396E" href="mailto:public@cabforum.org"><public@cabforum.org></a> wrote:
Dimitris,
In Taiwan, according our Company Act, the company name must be unique for the whole country
<a class="moz-txt-link-freetext" href="http://law.moj.gov.tw/Eng/LawClass/LawAll.aspx?PCode=J0080001">http://law.moj.gov.tw/Eng/LawClass/LawAll.aspx?PCode=J0080001</a>
Please see Company Act article 18, such as “No company may use a corporate name which is identical with that of another company. “
There will be no two companies with the same name such as “ABC company” in Taiwan.
But what about in other country? Is it allowed two company with same company name in Greece?
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?
So a better way is to let DN of the corporation that registered at country-level be C=TW, O=Farmer’s Association
And let DN of the corporation that registered at city/county-level be
C=TW, L=Taipei City, O=Farmer’s Association
Please see 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 for a corporation registered at country-level.
We hope you can support Wen-Cheng’s <a class="moz-txt-link-freetext" href="https://cabforum.org/pipermail/public/2017-March/010123.html">https://cabforum.org/pipermail/public/2017-March/010123.html</a>
to add a sub-section k under the section 7.1.4.2.2 Subject Distinguished Nam Fields as follows:
7.1.4.2.2 Subject Distinguished Nam Fields
……
k. Accepting X.500 Directory Naming Conventions of Existing PKIs
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:
i. the naming rules can unambiguously identify the subject; and
ii. only commonly-used naming attributes recommended by RFC 5280, RFC 3739, or ETSI EN 319 412 are used in the naming rules.
or support Ben’s version as <a class="moz-txt-link-freetext" href="https://cabforum.org/pipermail/public/2017-March/010215.html">https://cabforum.org/pipermail/public/2017-March/010215.html</a> that
adding the following sentence(s) to sections on localityName and stateOrProvinceName of SSL BR:
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.
Please discuss. Thanks.
Li-Chun Chen
From: Public [<a class="moz-txt-link-freetext" href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] On Behalf Of Dimitris Zacharopoulos via Public
Sent: Wednesday, March 22, 2017 10:21 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:public@cabforum.org">public@cabforum.org</a>
Cc: Dimitris Zacharopoulos
Subject: [外部郵件] Re: [cabfpub] Naming rules
If both companies "ABC" are located in the same city, then with current rules, there will be a DN collision, right? I don't think you can avoid that with the current BRs.
Dimitris.
On 22/3/2017 3:56 μμ, Jeremy Rowley via Public wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Correct. For #5 to be true, #3 must be true (which is still unclear), and OV must represent jurisdiction of incorporation (which it doesn’t).
From: Ryan Sleevi [<a class="moz-txt-link-freetext" href="mailto:sleevi@google.com">mailto:sleevi@google.com</a>]
Sent: Wednesday, March 22, 2017 7:33 AM
To: CA/Browser Forum Public Discussion List <a class="moz-txt-link-rfc2396E" href="mailto:public@cabforum.org"><public@cabforum.org></a>
Cc: Gervase Markham <a class="moz-txt-link-rfc2396E" href="mailto:gerv@mozilla.org"><gerv@mozilla.org></a>; Jeremy Rowley <a class="moz-txt-link-rfc2396E" href="mailto:jeremy.rowley@digicert.com"><jeremy.rowley@digicert.com></a>
Subject: Re: [cabfpub] Naming rules
On Wed, Mar 22, 2017 at 9:30 AM, Jeremy Rowley via Public <a class="moz-txt-link-rfc2396E" href="mailto:public@cabforum.org"><public@cabforum.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">There's one important item that seems unclear to me. What I took from reading Li Chun's message:
1) Taiwan has a country-level registration
2) Taiwan has a city-level registration
3) The two are not mutually exclusive (ie ABC Company at the country level might be a completely different entity than ABC Company at the city level)
4) You want the BRs to distinguish whether the ABC Company was registered with the country of Taiwan vs. a city registration.
5) If locality is included in a cert, the actions of ABC Company (country) could be falsely attributed to the ABC Company (local)
I can't tell if #3 is true. If it is, then I can see why we'd want to make the change. If #3 is not true, then the change is only for convenience in Taiwan.
</pre>
</blockquote>
<pre wrap="">
#5 is true if and only if we view OV information to indicate jurisdiction of incorporation. If it indicates physical address, then #5 is not true, correct?
_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<pre wrap="">
本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
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
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>