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

[Ben Wilson]

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.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20160714/39ac25d0/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4954 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20160714/39ac25d0/attachment.bin