[Servercert-wg] [EXTERNAL] State or Province

[Richard Smith]

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<mailto: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<mailto: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<mailto:Servercert-wg at cabforum.org>
http://cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>
http://cabforum.org/mailman/listinfo/servercert-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190905/4a77ae15/attachment-0001.html>