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

[Dimitris Zacharopoulos]

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) 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
> https://cabforum.org/mailman/listinfo/policyreview

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20160715/c0aa70de/attachment.html