[cabfpub] Naming rules
Peter Bowen
pzb at amzn.com
Tue Mar 14 12:12:43 UTC 2017
> On Mar 14, 2017, at 3:20 AM, 陳立群 <realsky at cht.com.tw> wrote:
>
> Peter, please see responses inline below.
>
> -----Original Message-----
> From: Peter Bowen [mailto:pzb at amzn.com]
> Sent: Friday, March 10, 2017 11:33 PM
>
>> Is the DIT hierarchy defined in law? I understand that the >designers of the DIT naming rules look at at the various laws, >but do any of them refer to the names in a X.500 directory >and/or in Certificates?
>
>> Thanks,
>> Peter=
>
>
> => No, the DIT hierarchy is not directly defined in law. Those laws have already existed before we start to develop the Government PKI in 1997. As I mentioned, the design of the DIT naming rules of the Government PKI was based on the existing laws, and then the naming rules were incorporated into the CPS and Certificate Profiles. Therefore, government CA needs to follow the naming rules specified in the CPS and Certificate Profiles.
With all due respect to the government CA, it would appear to be in a very similar situation to PKIs operated by governments and private organizations around the world. Many of them have naming rules, validation methods, or other policies that do not meet the CA/Browser Forum requirements. Many members of the Forum have been in similar positions and had to change their naming rules if they wanted to meet the Baseline reqirements.
Respectfully, I do not see this as an appropriate application of 9.16.3. The only paths forward are either to change the BRs to accommodate the naming rules of the Government PKI on Taiwan or for you to negotiate with each browser to accept a qualified audit.
Based on everything you have provided so far, there is no evidence that Taiwan does not have localities (cities, towns, villages, or similar) or that they are not used in postal addressing. Much to the contrary, every postal address example you have provided has included a locality. Therefore this appears to be a situation where the PKI does not want to change (possibly for quite valid reasons) rather than cannot change.
Thanks,
Peter
More information about the Public
mailing list