[cabfpub] Naming rules
Dimitris Zacharopoulos
jimmy at it.auth.gr
Tue Mar 28 06:30:49 UTC 2017
Hi Li-Chun,
On 27/3/2017 4:27 μμ, 陳立群 wrote:
>
> Dimitris,
>
> In Taiwan, according our Company Act, the company name must be
> unique for the whole country
>
> http://law.moj.gov.tw/Eng/LawClass/LawAll.aspx?PCode=J0080001
>
> 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?
>
If we are talking about "Subject Identity", as in most countries, it
depends. At this point, we need to distinguish the "Company" with the
"Subject" entity. BRs 3.2.2.1 describe validation of the identify of an
"Organization". You realize that a "Company" is just one form of an
"Organization". That said, and as you have clearly stated in your
previous e-mails, some Organizations MUST be registered at the country
level (for example Universities, Central Government Agencies/Units,
maybe Medical Institutions) and cannot be registered at any other level
(State, County, City or other). If you remember, I brought up this issue
along with Wendy Brown from the FPKI because some Government Agencies
and Public organizations are registered at a National Level so the
Locality or State seems unnecessary. Depending on the size of the
country, this rule could be expanded to Companies, as it appears to
exist in Taiwan (unfortunately I did not have time to verify this but
others may have done that already for Taiwan).
We should clearly distinguish the "streetAddress" with the "Subject
Information". The mailing address must be any physical address related
to the Organization identified in the "Subject Information" field as
verified under 3.2.2.1. Since there is a clear attribute for physical
address, why should we mix this information into the State or Locality
Information?
The current BRs don't mandate that the Subject Information must uniquely
Identify the Subject at a global or even a national scale. Normally,
this information would be included in 3.1.5 (Uniqueness of names) and in
several CP/CPS documents from various CAs you will see that the
uniqueness of the Subject DN is usually at the Issuing CA level. Now,
I've heard from CA/B Forum members that the "rationale/intent" of the
"State OR Locality" rule was in order to have some information that
uniquely identifies the Subject at a certain level (State or City). From
the 14-month discussion of this topic, it is clear -at least to me- that
this rationale/intent has failed... It would make more sense to force
inclusion of the streetAddress field in OV Certificates rather than the
"State or Locality".
I would not support Wen-Cheng’s proposal because it is overly specific
to X.500 directory. I think this exception should be broader and allow
for Organizations registered at a "National-Government" level (which
means unique at a National level and no other Organizations can use the
same Name at lower-levels) to be exempt from State and Locality field.
Best Regards,
Dimitris.
> 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
> https://cabforum.org/pipermail/public/2017-March/010123.html
>
> 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
> https://cabforum.org/pipermail/public/2017-March/010215.html 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 [mailto:public-bounces at cabforum.org] *On Behalf Of
> *Dimitris Zacharopoulos via Public
> *Sent:* Wednesday, March 22, 2017 10:21 PM
> *To:* public at cabforum.org
> *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:
>
> 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 [mailto:sleevi at google.com]
> *Sent:* Wednesday, March 22, 2017 7:33 AM
> *To:* CA/Browser Forum Public Discussion List
> <public at cabforum.org> <mailto:public at cabforum.org>
> *Cc:* Gervase Markham <gerv at mozilla.org>
> <mailto:gerv at mozilla.org>; Jeremy Rowley
> <jeremy.rowley at digicert.com> <mailto:jeremy.rowley at digicert.com>
> *Subject:* Re: [cabfpub] Naming rules
>
> On Wed, Mar 22, 2017 at 9:30 AM, Jeremy Rowley via Public
> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>
> 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.
>
> #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
>
> Public at cabforum.org <mailto:Public at cabforum.org>
>
> https://cabforum.org/mailman/listinfo/public
>
>
> 本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件.
> 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
>
> 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/20170328/94ee075b/attachment-0003.html>
More information about the Public
mailing list