[cabf_validation] Amending BR 7.1.4.2.2 regarding State field in EV certificates

[Kirk Hall]

All - I think we are very close to finishing this up.  Based on recent discussion, I think we have four (non-conflicting) approaches to a ballot.  This would involve changing BR 7.1.4.2.2 in one of the following four basic ways.

1. Bruce's suggestion -

Required/Optional:
City and country - Required;
State - Required, if verified per Section 11.4.1 as part of the address for the Place of Business;
Street and postal code - Optional

[If there is no state or the state is not used as part of the address, then it is not required.]

That makes sense, but my only problem with this is, it's rather circular - "if verified" - well, are you supposed to verify State in Taiwan, or not?  In the UK, etc.?  Is it up to each CA to decide that?  It would not necessarily lead to clarity on whether or not required, or consistency across CAs.  But I get Bruce's point.

There were some comments that it is good to include State (even if not required or used for postal purposes, etc.) to help with disambiguation - there are two or more Frankfurts in Germany, etc. (full name may be Frankfurt am Main, versus Frankfurt an der Oder, etc.).  There is some potential usefulness in that - would a CA put "Frankfurt" or "Frankfurt am Main" in the L field?

Would it make sense to modify Bruce's suggestion as follows?

Required/Optional:
City and country - Required;
State - Required, if verified per Section 11.4.1 as part of the address for the Place of Business.  State is not required if it is not normally used in mailing addresses, and is not otherwise necessary for disambiguation purposes;
Street and postal code - Optional


2. Kirk's first suggestion - tie BR 7.1.4.2.2 to some international standard on addressing, so we only verify State if it is part of the "official" way to send something to a recipient.

Problem - we have not yet found a good source (I only spent 1 minute on it), and there can be cases such as where a country is not recognized for a political reason (e.g., Taiwan in the ITU standards).

3. Kirk's second suggestion - amend BR 7.1.4.2.2 to leave state or province as required, but then add:

"State or province is not required for the countries listed on Appendix X"

Then we add places (Taiwan, Monaco, Vatican City, Germany, United Kingdom) as people bring them forward.  We could include an initial list with this ballot, but provide that countries can be added or deleted from the list at Appendix X by consensus of the CABF members (no future ballots required).

The benefit of this is simplicity, clarity, and consistent results across CAs - no question for each CA of "can it be validated" or "is it listed in the ITU's book?", etc.  The disadvantage is we will have to make some joint decisions - for example, I am under the impression that State is not really used in the UK or Germany, but I could be wrong.

4. Li-Chun's suggestion, which also deals with countries like Taiwan that have a central registry that designates official location names that are unique.  I have pasted in Li-Chun's suggestion below, and am emailing him to understand business registrations in localities.  Per his text below, see pp 23-24 of his attached pdf.

7.1.4.2.2 Subject Distinguished Name Fields

f.Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8)

Required if the subject:organizationName field, subject:givenName field, or subject:surname field are present and subject:localityName field is absent.

Optional if: (a)  the subject:localityName field and the subject:organizationName field, and subject:givenName field , or subject:surname field are present, or
(b) if the country name provided under subsection h. is Taiwan (TW), Singapore (SG), etc.. or (c) if the subject:organizationName and subject:countryName fields are present and the country/jurisdiction specified by the subject:countryName field has a centralized registry for that kind of organizations so that the organization name specified by the subject:organizationName field is "unique" in the entire country/jurisdiction.

[Normally, situation (c) may exist in small countries/jurisdictions such as Singapore (SG), Taiwan (TW), etc.]

(b) and (c) are exception for original sentences.

We need not to maintain "Appendix X", just let the Licensed WebTrust Practitioners : International to check the suitability for DN rule for each CA.  So there will be no burden for maintain the list in CA/B forum.

And then we amend EVGL section 9.2.5 and 9.2.7, with some reference to SSL BR 7.1.4.2.2.

The reason  is that Taiwan's government already has DN naming (GPKI certificate and CRL profile, DN tree, Government Directory Service) for 13 years.

  it is not suitable to enforce the CA to insert either L or ST into the subject DN as page 23 and 24 of attached file.

We would also need to make some conforming changes to EVGL Sections 9.2.7.  To address Li-Chun's issues about business registration at the locality level, we might also need to modify EVGL 9.2.5 - let's leave that for another discussion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20161220/83e90d05/attachment.html>