[Servercert-wg] [EXTERNAL] State or Province

Ryan Sleevi sleevi at google.com
Thu Sep 5 09:50:09 MST 2019


Hi Erwann,

I must admit, I'm having trouble following your logic. It appears you're
making an (unrelated?) point about the country field. However, the country
field is already aligned in requiring ISO 3166-1 Alpha-2

Specifically:
Certificate Field: subject:countryName (OID: 2.5.4.6) )
Required if the subject:organizationName field, subject:givenName, or
subject:surname field are
present.
Optional if the subject:organizationName field, subject:givenName field,
and subject:surname field
are absent.
Forum Guideline
Baseline Requirements, v.1.6.5 48
Contents: If the subject:organizationName field is present, the
subject:countryName MUST contain
the two-letter ISO 3166-1 country code associated with the location of the
Subject verified under
Section 3.2.2.1. If the subject:organizationName field is absent, the
subject:countryName field MAY
contain the two-letter ISO 3166-1 country code associated with the Subject
as verified in accordance
with Section 3.2.2.3. If a Country is not represented by an official ISO
3166-1 country code, the CA
MAY specify the ISO 3166-1 user-assigned code of XX indicating that an
official ISO 3166-1 alpha-2
code has not been assigned.


Am I wrong in thinking that the point you're making is entirely unrelated?

Note that ISO 3166-2:TW exists and is a thing:
https://en.wikipedia.org/wiki/ISO_3166-2:TW


On Thu, Sep 5, 2019 at 12:17 PM Erwann Abalea <Erwann.Abalea at docusign.com>
wrote:

> 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.
>
>
>
> Cordialement,
>
> 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:
>
>
> https://censys.io/certificates/fbb3010c9d3f9ce6ec16ad7062f6c5b6d502c1e2ca35b2a594afbcb3dee5af28
>
>
>
> (aside – what is the answer on this one. Is England allowed in the state
> field?)
>
>
>
> And determine whether abbreviations like this:
>
>
> https://censys.io/certificates/cdfb32d539a4204641e22e2a8b80441f8a9194c4fb759059ec76cc1dca49c232
>
> 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
>
>
>
> 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> 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/20190905/66e117de/attachment.html>


More information about the Servercert-wg mailing list