[Servercert-wg] [EXTERNAL] State or Province

[Richard Smith]

I wasn’t thinking of data gathering earlier when I said a SHOULD is not particularly useful in a CA/B Forum document, but I think Wayne’s suggestion is quite sensible from that perspective.  Joanna’s example adds to what we’ve been looking at just in the UK in terms of cases which diverge from the ISO standard, including addresses which appear in Companies House information.

As to, “This gets somewhat to the heart of what "should" the stateOrProvince field be. For fields where the EVGs are more prescriptive here, such as jurisdictionOfIncorporation, it's much easier to establish a static list, if simply by virtue of looking at the list of recognized jurisdictions of incorporation (e.g. as GLEIF has done for their LOUs),” you’re right, to a point.  For type Private Organization I think it will be relatively easy to come to a static list, but it may well become more difficult when looking at Government or Business Entity types.

Regards,
Rich

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Thursday, September 5, 2019 1:01 PM
To: Joanna Fox <jweber at godaddy.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [EXTERNAL] State or Province

Thanks Joanna, this is fantastic and extremely helpful! This is the kind of discussion that really helps the Forum.

This gets somewhat to the heart of what "should" the stateOrProvince field be. For fields where the EVGs are more prescriptive here, such as jurisdictionOfIncorporation, it's much easier to establish a static list, if simply by virtue of looking at the list of recognized jurisdictions of incorporation (e.g. as GLEIF has done for their LOUs)

Your question, "Which is better for the community, that CA’s report what they validate (L: Appleford, S: Abingdon C: GB) or what ISO says is true (L: Abingdon S: Oxfordshire C: GB)?", hits on the heart of the matter. What do "we" (browsers, CAs, relying parties) want that information to be, and how do we express that within requirements. As it currently stands, we can't be sure what it is, both within a CA and more broadly. Today, a Subscriber might get a cert saying either, depending on the validation agent they used, the QIIS/QGIS the CA used, or even which CA they went do. And that seems to be the crux of the challenge.

Do you have thoughts on what it should be? That is, what the values/purposes of this OV information would be in certificates, so that we might shake out how to best enable that and ensure consistency?

On Thu, Sep 5, 2019 at 1:49 PM Joanna Fox via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> wrote:
I agree that we need to work together to standardize a process for state/country including the field contents; however, we are all aware that there are a variety of complications due to countries simply having different address structures.  I would like to discuss what I see as a common issue and discuss an alternative solution/source.  Bear with me this is long, but I think examples help the process.
For the sake of argument, let us focus on Physical Address (EVG 9.5.6) and Physical Existence (EVG 11.4) validation.  I think we can all agree that the point of these sections is to be able to direct a certificate consumer to the physical location of the business.  In my opinion, ISO may not be the right place to do this for certificate consumers, but something like UPU (Universal Postal Union)<http://www.upu.int/en/activities/addressing/postal-addressing-systems-in-member-countries.html> would be knowledgeable about how to get to a specific location.
For example, UPU for GB shows that an address can contain these elements:
Addressee identification
Building
Dependent thoroughfare
Thoroughfare
Double dependent locality
Dependent locality
POST TOWN
County
POSTCODE
UNITED KINGDOM
Commonly, one might see something like this (sourced from UPU):
Leda Engineering Ltd (addressee)
APPLEFORD (dependent locality)
ABINGDON (post town – not listed in ISO)
OX14 4PG (postcode)
UNITED KINGDOM
If we determine mapping ISO 3166-2 subdivisions to stateOrProvince and force a state requirement, this means we would require Oxfordshire in the state field for the company Leda Engineering Ltd.  QGIS and QIIS sources may not be able to validate Oxfordshire as this is not commonly used, I had to do a basic online search to find out that Abingdon was in Oxfordshire.  I believe it is more reliable to report what we can validate in the Subject fields.
Which is better for the community, that CA’s report what they validate (L: Appleford, S: Abingdon C: GB) or what ISO says is true (L: Abingdon S: Oxfordshire C: GB)?
Thank you,
Joanna Fox
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190905/7b401849/attachment-0001.html>