[cabfpub] Naming rules

[王文正]

Gerv,

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.

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.

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.

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.

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.

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).

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:

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.

Best Regards,
Wen-Cheng Wang

On 10/03/17 10:18, 陳立群 via Public wrote:
> We hope this discussion is about getting an existing established PKI to
> be BR-compliant by changing the BRs instead of changing the PKI.

That is not unreasonable; can you present (or re-present) the minimum
changes you think are necessary to the BRs in order to allow that to happen?

Gerv

________________________________________
從: Public [public-bounces at cabforum.org] 代表 Gervase Markham via Public [public at cabforum.org]
寄件日期: 2017年3月10日 下午 06:41
至: CA/Browser Forum Public Discussion List
副本: Gervase Markham
主旨: Re: [cabfpub] Naming rules

On 10/03/17 10:18, 陳立群 via Public wrote:
> We hope this discussion is about getting an existing established PKI to
> be BR-compliant by changing the BRs instead of changing the PKI.

That is not unreasonable; can you present (or re-present) the minimum
changes you think are necessary to the BRs in order to allow that to happen?

Gerv

_______________________________________________
Public mailing list
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/20170319/9c7fe263/attachment-0003.html>