[cabfcert_policy] Discussion about making L/ST Optional in some Countries
Dimitris Zacharopoulos
jimmy at it.auth.gr
Thu Jan 28 09:33:36 MST 2016
Dear members of the policyreview WG,
At today's call, among other issues, we discussed bug 2
<https://bugzilla.cabforum.org/show_bug.cgi?id=2> which talks about
making the "Locality/ST" field optional in some very special cases. We
discussed about creating an exception list which should be displayed
in-line in section 7.1.4.2.2 d and e.
The idea is to draft a language for this exception similar to this:
(original text from BR version 1.3.1, section 7.1.4.2.2d)
"*Optional* if the subject:organizationName and
subject:stateOrProvinceName fields are present. "
(Proposed new language)
"*Optional* if thesubject:organizationName and
subject:stateOrProvinceName fields are present or if the Country is
Taiwan, Singapore, .... "
This type of exception has been accepted in the past (for example in the
EV guidelines) by the CA/B Forum.
Some questions came up about how are we going to add a country to the
exception list and under what procedure. Perhaps a ballot would be
efficient.
For those that don't have access to the bugzilla system, you are able to
create your own account and access is granted automatically.
I have attached the bug's comments below for your convenience.
Best Regards,
Dimitris Zacharopoulos.
--- BEGIN Comments from Bug 2 ---
Gervase Markham 2014-09-17 19:46:43 MST
Some jurisdictions don't have a meaningful value to put here. We should
make this field optional.
Erwann Abalea 2014-09-23 04:59:08 MST
Could someone provide a list of countries (as defined by BR) for which
there's no state/province AND no locality?
Gervase Markham 2014-09-23 05:08:56 MST
There was a discussion of this issue, led by TWCA (I think) in Beijing.
We should probably get the minutes of that before going any further. I
think it came down to defining exactly what the address in the cert
_means_ - is it "where the entity is incorporated", or "where the entity
can be found". For the former, the issue covered by this bug is a
problem because inserting a Locality can be misleading. For the latter,
it's not a problem.
Gerv
ben.wilson at digicert.com 2014-10-29 15:41:49 MST
Presentation of Li-Chun Chen on Locality in Subject DNs
When I review Li-Chun's presentation, I am confused because I was
thinking that it was best to have one or the other "S" or "L" or both
State and Locality and omit one only if the other is provided. His
proposal wants "L" optional if State/Province is absent, etc. As I
recall when we were discussing this in Beijing, we focused on the
ability to identify the physical location for the subject with the DN
and not so much the X.500 name uniqueness (for company registration).
But the presentation does have a point on eliminating the requirement
for very small countries like Singapore, etc. I'm not sure whether
inserting country-specific exceptions into section 9.2.4 is a solution,
but maybe it's a possibility.
Dimitris Zacharopoulos 2016-01-14 07:49:20 MST
I suppose the original idea behind the Locality/State was that a
Company/Organization could use the same Name within a specific region of
the Country. This means that there could be a Company named "Example Co"
in one city and a different "Example Co" in another city, and so on.
There are some countries that have a centralized registry for commercial
companies which means that company names are "unique" in the entire
country. Perhaps this is the case in Singapore.
The BR could address this issue in Section 7.1.4.2.2d/e and provide an
exception for these cases. However, the CA's qualified auditors should
verify that there is a single company naming registry in the entire
country which forces uniqueness of company names. The Root programs
could request a letter from the CA's auditors to verify this situation
that would enable the exception.
--- END Comments from Bug 2 ---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20160128/063857b9/attachment.html
More information about the Policyreview
mailing list