[Servercert-wg] [EXTERNAL] State or Province

[Ryan Sleevi]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190903/c8c331d2/attachment.html>