[Servercert-wg] State or Province

Fri Sep 6 06:44:06 MST 2019

Erwann,

     There are two CA/Browser members established in Taiwan (ROC), they are Chunghwa Telecom Co., Ltd. and TAIWAN-CA Inc.. It is not only a CA/Browser member in Taiwan as your comment.

       The 42nd CA/Browser Forum Face to Face meeting was hold by Chunghwa Telecom Co., Ltd. Ryan did not come to Taiwan for  October 3-5 2017 CABF F2F meeting. But his colleague Devon has been in Taipei.

             Li-Chun Chen

             Chunghwa Telecom

From: Servercert-wg [mailto:servercert-wg-bounces at cabforum.org] On Behalf Of Erwann Abalea via Servercert-wg
Sent: Friday, September 06, 2019 2:22 AM
To: Ryan Sleevi
Cc: CA/B Forum Server Certificate WG Public Discussion List
Subject: [外部郵件] Re: [Servercert-wg] [EXTERNAL] State or Province

It’s not entirely unrelated. If we decide that we MUST follow ISO 3166-2, it doesn’t seem illogical that what is taken from ISO3166-2 is consistent with ISO3166-1.

There’s 2 Taiwan, covering the same territory. One is a province of China (PRC), the other is a country (ROC).

The ISO 3166-1 alpha-2 code TW designates Taiwan as the province of China (PRC).

There is no assigned country code for Taiwan (ROC).

Yet, we have a CA member established in Taiwan (ROC), a lot of countries (including USA) have a long standing unofficial relationship with Taiwan (ROC), and even the .tw ccTLD is linked to Taiwan (ROC).

Is there a normative list of subdivisions of Taiwan (ROC) ?

Same for Kosovo, is there any official list of its subdivisions ? There’s even no assigned country code.

And there’s certainly more examples like these.

The point here is that ISO3166-x is not purely technical, it’s also politically tainted. How to use 3166-1 is already not clearly defined (the text present in the BR doesn’t cover all cases), I don’t think adding a MUST related to 3166-2 will solve anything.

Cordialement,

Erwann Abalea

De : Ryan Sleevi <sleevi at google.com>
Date : jeudi 5 septembre 2019 à 18:50
À : Erwann Abalea <Erwann.Abalea at docusign.com>
Cc : Jeremy Rowley <jeremy.rowley at digicert.com>, CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>, Richard Smith <rich at sectigo.com>, Bruce Morton <Bruce.Morton at entrustdatacard.com>
Objet : Re: [Servercert-wg] [EXTERNAL] State or Province

Hi Erwann,

I must admit, I'm having trouble following your logic. It appears you're making an (unrelated?) point about the country field. However, the country field is already aligned in requiring ISO 3166-1 Alpha-2

Specifically:

Certificate Field: subject:countryName (OID: 2.5.4.6) )
Required if the subject:organizationName field, subject:givenName, or subject:surname field are
present.
Optional if the subject:organizationName field, subject:givenName field, and subject:surname field
are absent.
Forum Guideline
Baseline Requirements, v.1.6.5 48
Contents: If the subject:organizationName field is present, the subject:countryName MUST contain
the two-letter ISO 3166-1 country code associated with the location of the Subject verified under
Section 3.2.2.1. If the subject:organizationName field is absent, the subject:countryName field MAY
contain the two-letter ISO 3166-1 country code associated with the Subject as verified in accordance
with Section 3.2.2.3. If a Country is not represented by an official ISO 3166-1 country code, the CA
MAY specify the ISO 3166-1 user-assigned code of XX indicating that an official ISO 3166-1 alpha-2
code has not been assigned. 

Am I wrong in thinking that the point you're making is entirely unrelated?

Note that ISO 3166-2:TW exists and is a thing: https://en.wikipedia.org/wiki/ISO_3166-2:TW

On Thu, Sep 5, 2019 at 12:17 PM Erwann Abalea <Erwann.Abalea at docusign.com> wrote:

If it’s a MUST, then we’ll require that the ST attribute shall be consistent with the C one.

And then, nobody will be able to issue certificates with C=TW (because TW is not recognized by UN, and ISO is strongly linked to UN, so TW is not considered an independant country for ISO, but a province of CN).

Similar story with Hong Kong (HK) and Macao (MO), but the problem is more pronounced with Taiwan.

Cordialement,

Erwann Abalea

De : Servercert-wg <servercert-wg-bounces at cabforum.org> au nom de Jeremy Rowley via Servercert-wg <servercert-wg at cabforum.org>
Répondre à : Jeremy Rowley <jeremy.rowley at digicert.com>, CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Date : jeudi 5 septembre 2019 à 15:49
À : Richard Smith <rich at sectigo.com>, CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>, Ryan Sleevi <sleevi at google.com>, Bruce Morton <Bruce.Morton at entrustdatacard.com>
Objet : Re: [Servercert-wg] [EXTERNAL] State or Province

It needs to be a must.  One of the weakness of EV is that you can’t easily evaluate a certificate via machine. Using a standard like ISO 3166-2 provides an international standard for states/provinces and standardizes the field in a way that is useful.  

What other sources would you like considered for determining whether something qualifies as a state?  

The idea is to answer questions about whether England is a state in the UK:

https://censys.io/certificates/fbb3010c9d3f9ce6ec16ad7062f6c5b6d502c1e2ca35b2a594afbcb3dee5af28

(aside – what is the answer on this one. Is England allowed in the state field?)

And determine whether abbreviations like this:

https://censys.io/certificates/cdfb32d539a4204641e22e2a8b80441f8a9194c4fb759059ec76cc1dca49c232

are allowed

The current contents are too chaotic.  Neither state or locality is defined in the BRs or EV guidelines. That’s leading to a lot of confusion by people using EV certs and by CAs. We should remove this clarification.

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Richard Smith via Servercert-wg
Sent: Thursday, September 5, 2019 7:25 AM
To: Ryan Sleevi <sleevi at google.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Bruce Morton <Bruce.Morton at entrustdatacard.com>
Subject: Re: [Servercert-wg] [EXTERNAL] State or Province

Ryan,

I agree with your reasoning, but would not support making ISO 3166-2 a MUST because I don’t have 100% confidence in it’s accuracy across all jurisdictions, and I’m concerned by the inherent political nature of the specification (see Kosovo and the reasoning behind the CA/B Forum allowing user defined country code XX).  I would support wording along the lines of, “CAs SHOULD check the ST field against ISO 3166-2 prior to issuance and flag deviations for additional scrutiny,” but I’m not sure how useful any ‘SHOULD do thus and such’ directive is in a CA/B Forum standard which SHOULD be auditable.

Regards,

Rich

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Tuesday, September 3, 2019 9:54 PM
To: Bruce Morton <Bruce.Morton at entrustdatacard.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [EXTERNAL] State or Province

I think one of the really important questions, which we've seen multiple CAs have issues with, is what objectively should the ST field contain, and can we ensure that's consistent among CAs?

Right now, we can have three validation agents at the same CA, or three different CAs, issue three different certificates: one with C=US, ST=GA, the other with C=US, ST=Georgia, a third with C=US, ST=Ga.

It does not seem like relying parties benefit from that flexibility, much like Relying Parties have trouble when CAs don't use the CA/B Forum Policy OIDs to distinguish DV/EV/OV. Can we find a system that consistently works, regardless of CA, and regardless of the validation agent performing the validation, so that Relying Parties can benefit?

I don't think the suggestion would be to replace the QIIS or QGIS, but rather, post-validation, to ensure it's consistently normalized for all certificates containing those fields and compliant with the Baseline Requirements. That seems like a notable and welcome improvement?

On Tue, Sep 3, 2019 at 8:31 PM Bruce Morton via Servercert-wg <servercert-wg at cabforum.org> wrote:

Hi Tim,

I would be concerned if an applicant provides an address and the CA validates the address with a QIIS or QGIS. Then the CA would check ISO 3166-2 and find the state/province/whatever is not listed.

As ST is optional, the CA could still issue the certificate if the ST data is removed. I’m not sure that issuing a certificate with only some of the information that was validated would be a good idea. 

There may also be the case where ISO 3166-2 provides data which is not used in addresses and cannot be validated with a third party.

It might be better to do some testing before implementing ISO 3166-2 as the limit.

Perhaps a starting position is that items in ISO 3166-2 may be used in the ST field.

Bruce.

On Sep 3, 2019, at 7:48 PM, Tim Hollebeek via Servercert-wg <servercert-wg at cabforum.org> wrote:

It has come to my attention that the current baseline requirements are rather unclear about what is a valid state or province (subject:stateOrProvinceName [OID: 2.5.4.8]).  Lots of countries have what are effectively states or provinces, they just call them something else.

In order to provide bright, clear lines that everyone can comply with, it would be useful to point to an existing standard, and ISO 3166-2 seems like just the thing to point to.  Hopefully the ISO folks have already figured out all the crazy, weird corner cases for us.

Does anyone have a good reason why stateOrProvinceName should NOT be required to comply with ISO 3166-2?  Other comments or concerns?

-Tim

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org
http://cabforum.org/mailman/listinfo/servercert-wg

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org
http://cabforum.org/mailman/listinfo/servercert-wg

本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190906/e5f0c6a0/attachment-0001.html>