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

Fri Feb 5 04:42:23 MST 2016

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 <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
>
> 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/20160205/2bb4c0d9/attachment-0001.html 