[Servercert-wg] State or Province

陳立群 realsky at cht.com.tw
Fri Sep 6 06:44:06 MST 2019



From the Baseline Requirement, section 1.6.1


Country: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations.


    Although Taiwan (R.O.C.) is not a member of the United Nations after 1970. But Taiwan is still a geographic region recognized as a Sovereign State by at least two UN member nations compliance with above country definition in BR.


        Li-Chun Chen

        Chunghwa Telecom Co., Ltd



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


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.



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:



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


And determine whether abbreviations like this:


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



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.





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.





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:]).  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?



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

Servercert-wg mailing list
Servercert-wg at cabforum.org

本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
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/49700e42/attachment-0001.html>

More information about the Servercert-wg mailing list