[cabfcert_policy] Discussion about making L/ST Optional in some Countries

Ben Wilson ben.wilson at digicert.com
Tue Feb 9 09:22:00 MST 2016


Thanks.  We’ll take a look at that, too.

 

From: Brown, Wendy (10421) [mailto:wendy.brown at protiviti.com] 
Sent: Tuesday, February 9, 2016 9:20 AM
To: Ben Wilson <ben.wilson at digicert.com>; Dimitris Zacharopoulos <jimmy at it.auth.gr>; policyreview at cabforum.org
Subject: RE: [cabfcert_policy] Discussion about making L/ST Optional in some Countries

 

Can I request that you also look at some of the requirements like bits of entropy in terms of Root CA certificates in terms of when these requirements were added to the BRs vs when the CA certificate was signed? 

Based on the Mozilla discussion of passing various tests it sounds like they may have generalized some requirements all the way to the root without regard to when the Root was generated.  The Entropy was a risk mitigation as far as I understood and the risk was not applicable to a certificate that was already in existence.

 

Thanks,

   wendy

 

From: Ben Wilson [mailto:ben.wilson at digicert.com] 
Sent: Tuesday, February 9, 2016 11:15 AM
To: Dimitris Zacharopoulos <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr> >; Brown, Wendy (10421) <wendy.brown at protiviti.com <mailto:wendy.brown at protiviti.com> >; policyreview at cabforum.org <mailto:policyreview at cabforum.org> 
Subject: RE: [cabfcert_policy] Discussion about making L/ST Optional in some Countries

 

We will discuss this during our upcoming F2F meeting.   

 

From: Dimitris Zacharopoulos [mailto:jimmy at it.auth.gr] 
Sent: Friday, February 5, 2016 4:42 AM
To: Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> >; Brown, Wendy (10421) <wendy.brown at protiviti.com <mailto:wendy.brown at protiviti.com> >; policyreview at cabforum.org <mailto:policyreview at cabforum.org> 
Subject: Re: [cabfcert_policy] Discussion about making L/ST Optional in some Countries

 

On 28/1/2016 7:07 μμ, Ben Wilson wrote:

Good question – it sounds like that  is another exception that  we  should add/consider.


This is indeed a very interesting proposal. In HARICA, most of our "clients" are members of the Academic and Research Community. I suppose that there is no way to establish a business in the entire country that would use the same DBA name of a University. There can only be one such name in the entire country. Adding Locality or State for such entities doesn't provide any additional security.

Best Regards,
Dimitris



 

From: Brown, Wendy (10421) [mailto:wendy.brown at protiviti.com] 
Sent: Thursday, January 28, 2016 9:58 AM
To: Ben Wilson  <mailto:ben.wilson at digicert.com> <ben.wilson at digicert.com>; Dimitris Zacharopoulos  <mailto:jimmy at it.auth.gr> <jimmy at it.auth.gr>; policyreview at cabforum.org <mailto:policyreview at cabforum.org> 
Subject: RE: [cabfcert_policy] Discussion about making L/ST Optional in some Countries

 

Just as a question, if the organizationName is a national entity say a government agency where a specific locality  or state or Province would just be misleading are one of these 2 still required?

 

Thanks – sorry to have missed today’s call.

Wendy

 

Wendy Brown

FPKIMA Technical Liaison

Protiviti Government Services

703-299-4705 (office)    703-965-2990 (cell)

 

wendy.brown at gsa.gov <mailto:wendy.brown at gsa.gov> 

wendy.brown at protiviti.com <mailto:wendy.brown at protiviti.com> 

 

 

 

From: policyreview-bounces at cabforum.org <mailto:policyreview-bounces at cabforum.org>  [mailto:policyreview-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Thursday, January 28, 2016 11:45 AM
To: Dimitris Zacharopoulos <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr> >; policyreview at cabforum.org <mailto:policyreview at cabforum.org> 
Subject: Re: [cabfcert_policy] Discussion about making L/ST Optional in some Countries

 

I’ve added another comment:

 

We could amend subsections 7.1.4.2.2d/e to say:

 

d.      Certificate Field: subject:localityName (OID: 2.5.4.7) 

Required if the subject:organizationName field is present and the subject:stateOrProvinceName field is absent.

Optional if: (a) the subject:organizationName and subject:stateOrProvinceName fields are present, or (b) if the country name provided under subsection g. is Taiwan (TW), Singapore (SG), etc..

 

e.      Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8) 

Required if the subject:organizationName field is present and subject:localityName field is absent.

Optional if: (a) subject:organizationName and subject:localityName fields are present, or (b) if the country name provided under subsection g. is Taiwan (TW), Singapore (SG), etc..

 

 

From: policyreview-bounces at cabforum.org <mailto:policyreview-bounces at cabforum.org>  [mailto:policyreview-bounces at cabforum.org] On Behalf Of Dimitris Zacharopoulos
Sent: Thursday, January 28, 2016 9:34 AM
To: policyreview at cabforum.org <mailto:policyreview at cabforum.org> 
Subject: [cabfcert_policy] Discussion about making L/ST Optional in some Countries

 

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 <mailto: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 ---

NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you. 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20160209/92e404e1/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4954 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20160209/92e404e1/attachment-0001.bin 


More information about the Policyreview mailing list