[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