[cabfcert_policy] Notes from Today's Call - 2016-July-14

Fri Jul 15 07:18:20 MST 2016

A similar issue came up in the US Federal PKI but more around acceptance of common three letter country codes (can't remember exactly, it was a couple years ago). NIST published a country code guide in FIPS 10 but it has been retired in place of a National Geospatial Intelligence Agency publication based on ISO 3166. There is a public law in the US that the Federal Government can only use country names approved by a US Board on Geographic Names.

Standard
https://nsgreg.nga.mil/NSGDOC/files/doc/Document/GENC%20Standard%20Ed3.0.1.docx

Online Registry
https://nsgreg.nga.mil/genc/discovery

Example of Taiwan Subdivisions
https://nsgreg.nga.mil/genc/view?v=252348&month=7&day=15&year=2016

On Jul 15, 2016, at 02:47, Dimitris Zacharopoulos <jimmy at it.auth.gr<mailto:jimmy at it.auth.gr>> wrote:

Following up on yesterday's discussion regarding the "small countries" issue, I noticed that ISO 3166-2 (https://en.wikipedia.org/wiki/ISO_3166-2<https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_ISO-5F3166-2D2&d=CwMDaQ&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=kbLSHVY2yApTe8hRb835cCbEggwFf58hE7zqi51_4RU&s=zKQohh4a83acvTUTi5ydwIg0Q22SvhmS_GqL5-KcfEw&e=>) enumerates the countries and respective Subdivisions (states/provinces/cities). Countries with no subdivisions have an empty cell in the respective column. If we consider this information "authoritative" enough, we could enumerate the countries without a Subdivision (in alpha-2 code) as exceptions on 7.1.4.2.2.

Best regards,
Dimitris.

On 14/7/2016 9:23 μμ, Ben Wilson wrote:
Here are my notes of today’s Policy Review Working Group call.

Present:  Tim H., Dean, Ben, Robin, Dimitris, Li-Chun, Peter

The working group discussed the city-state issue with small countries raised by Li-Chun.  The issue is, what is the exact language we want to use if we want to amend section 7.1.4.2.2, subject distinguished name fields … if the organization name and state or province fields are present, or if the country name provided under this subsection, is TW (Taiwan) is present, then it's optional.   The main argument here is that the namespace is defined with a registry in the country.   The issue is what is the specific language that would be in the Baseline Requirements?  Would we make an assessment and determine which country names to  add, and if there are additional names after we do an initial list how would that be managed?  It might be better if we can enumerate those countries like TW and SG.  Another proposal was to ask whether the country had a registry, but that  would apply to every country and be difficult to interpret and apply.  Under that second proposal, if a name is unique in the entire country, e.g. in Greece, then the subject name could be said to be unique.  This might be similar for big organizations in the US that are known nationwide or that are chartered at the national level.  But we’re not dealing with EV jurisdictions of formation, so we need to address this primarily from a Baseline Requirements perspective.  (For EV Certs there are two parts of the certificate that you can identify- the jurisdiction of incorporation and the physical  location.)

For OV certificates, is the basis the location or is it in order to provide a unique namespace?  It was generally agreed that  it wasn’t for a unique namespace but for geographic locations.  The geographic location is very simple and easier to address.  Then, do we enumerate the countries instead of you opening it up for some kind of definition -  if you do, you get back to the namespace thing.  Do we put a list of countries in a table in an appendix?

But, if it is based on the location of the organization, then is it like sending a postal letter?  Addressing something to  15 Main St., Singapore, might be ambiguous.  If you take the  Vatican example, in true city-states, for the Vatican and Singapore under the UPU - Universal Postal Union they are duplicated -  there is nothing under the  country level.  This isn’t true for larger countries that have political subdivisions.  Taiwan has political subdivisions.  Then, if you look at some islands, you may have no political subdivisions, or they may be protectorates of larger countries.  If you take the island of Nevis in the Caribbean, for example, you could probably send something to Mrs. Jane Smith and it would get there.  There aren’t enough people for name collisions.

Can we point to some possible authority rather than create and maintain an enumerated list?  The UPU guidance may not be useful.  Maybe we develop a model that is as close to  the postal model as possible?  Could we point to somewhere online even if it is not 100% accurate? We could take a minimalist approach and just ask whether it sufficiently provides the physical location.  It would be good to have a uniform approach across all CAs.  There is a list attached to Li-Chun’s email that lists small countries with their 3166 abbreviations.

We need to pick a middle ground with our approach here, which means we’ll likely have to maintain a list using the requests of parties wanting jurisdictions added to the  list.  We should add to the  list those that  are  very certain and then leave others to add exceptions based on evidence as needed.  Li-Chun has already provided his justification for Taiwan.  Because we can’t come up with a rule, we’ll just have to do this on an ad-hoc basis.

Ben and Robin volunteered to work on a draft and to put something down on paper.  The results of the call will be sent to the Policy Working Group email list, and that should help us move forward, too.

Changing the subject of discussion back to the Baseline Requirements review and section 5.1 (Ben will circulate another proposed revision to Section 5.1.), the group discussed the reasons for the failure of Ballot 170.  Was it because there were too many “SHOULDs”?  Do we remove “shoulds” and focus on “musts”?  The reason given was that the language was “unauditable”. What did that mean?  We need to attempt to address this, maybe by presenting another ballot on Section 5.1 or discussing the rationale for rejecting Ballot 170 more on the public list.  It may be that no one will put attention to this issue until another ballot is  presented.  Eventually we’ll get it right and a ballot will pass.   The “no” votes were not because the ballot used “should” versus “must”,  they were most likely because of the phrasing used.  The browsers who voted “no” were just saying that they couldn’t be taken in as auditable standards and implemented by an auditor.  The language just needs to be more clear.  It was a quality issue.  They left too much open to auditor interpretation.  Do we take this discussion to the public list so that we can get direction/guidance that this is the way that the majority wants to go forward?

On the next call we’ll have some sections to discuss with the Baseline Requirements, but are there any other topics we’d like to address?  There are two new topics that we’d like to address at the next face-to-face meeting.  One is an action item to address  the use of the  terms “CA,” “subordinate CA,” “intermediate CA”, etc. and the other is somewhat related and that  is CA annual audits and whether subordinate/intermediate CAs generated by CAs during the audit period (after the audit letter)  require point-in-time audits.  CAs have yearly audit cycles, and it seems onerous to require a point-in-time readiness assessment for every new issuing CA.  Some CAs create many issuing CAs during the year as a means for distributing risk, and requiring additional audits would discourage that.  We need to gather input from auditors and browsers on this issue.  For example, Microsoft and Mozilla are expecting to be able to correlate an audit report with each CA, but what  about new ones under the same  root?

Meeting adjourned.

_______________________________________________
Policyreview mailing list
Policyreview at cabforum.org<mailto:Policyreview at cabforum.org>
https://cabforum.org/mailman/listinfo/policyreview<https://urldefense.proofpoint.com/v2/url?u=https-3A__cabforum.org_mailman_listinfo_policyreview&d=CwMDaQ&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=kbLSHVY2yApTe8hRb835cCbEggwFf58hE7zqi51_4RU&s=WqBHd6ghWYC8emt5ElhmMl5fv5Ohz4heVkOf51y2R1E&e=>

_______________________________________________
Policyreview mailing list
Policyreview at cabforum.org<mailto:Policyreview at cabforum.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__cabforum.org_mailman_listinfo_policyreview&d=CwICAg&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=kbLSHVY2yApTe8hRb835cCbEggwFf58hE7zqi51_4RU&s=WqBHd6ghWYC8emt5ElhmMl5fv5Ohz4heVkOf51y2R1E&e=
NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20160715/fc380969/attachment-0001.html 