[Servercert-wg] [EXTERNAL] State or Province

[Ryan Sleevi]

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> 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/dcb216f4/attachment.html>