[Servercert-wg] [EXTERNAL] State or Province

[Tim Hollebeek]

I agree that a discussion of the goals for this certificate field might help us select a list (I’d throw out that it also might not).  I personally don’t have any strong opinions on the goals, other than a desire for clear requirements and uniformity.

 

Regarding requirements around disclosure of reasons for violating the SHOULD, I’m curious how that would actually work at the scale required.  Especially since we have had no previous successes with that sort of requirement.  I’m worried that trying to solve that problem might unfortunately prevent progress on this important issue.

 

-Tim

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Thursday, September 5, 2019 12:11 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Erwann Abalea <Erwann.Abalea at docusign.com>
Subject: Re: [Servercert-wg] [EXTERNAL] State or Province

 

 

 

On Thu, Sep 5, 2019 at 3:03 PM Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

So, there have been a bunch of extremely useful suggestions.  Thanks to everyone for engaging constructively.

 

I think Jeremy is right that we need to get to a MUST eventually, but I find Wayne’s argument about the value of a SHOULD compelling.  We can revisit the issue once everyone has a chance to provide feedback about the compliance challenges in corner cases.

 

Some people are rather skeptical of SHOULD requirements, but I’ve always found them useful for expressing best practices, and more importantly, for expressing goals for future requirements.

 

While I don't disagree with that, I think the Forum has shown repeatedly that when the objective of the SHOULD is getting feedback from CAs about the operational challenges, so that we can avoid a MUST that breaks things, we never actually succeed at that.

 

That is, we only make progress when discussing a MUST, as we're doing now. If we added a SHOULD, I have zero faith that CAs, consistently and as a collective whole, maintain accurate logs about when and why they violated the SHOULD. Some do, some treat the SHOULD as a MUST, but without that uniformity, we don't make any progress or advance any understanding.

 

An idea that I continue to raise, for every violation of a SHOULD, that actually helps ensure we make continued and timely forward progress, is to require disclosure, to the Forum, for every situation where the CA deems it appropriate to violate the SHOULD. This is objectively auditable, does not require membership in the Forum itself, aligns with how we handle legal/jurisdictional conflicts, and quantifiably and objectively measures any complexity or challenges in ways that help develop better criteria.

 

I think Doug is also correct that there are a number of large and important countries where the situation is less complicated where we could probably go directly to a MUST.  I’m sure some people will be less than satisfied with non-uniformity of requirements around the world, but I think that just reflects the reality of the situation …

 

The UPU is also an interesting suggestion.  Apparently it has been discussed internally here as well.  I’d have to look more closely at the advantages / disadvantages of each list.  If there’s a better data source or standard available, it should be considered.  ISO 3166-2 is simply one of the best known, and has the advantage that we already rely on ISO 3166-1, so hopefully that would reduce the risk of divergences or conflicts.

 

Perhaps, rather than focusing on the list, we should focus on the question Joanna highlighted? Namely, what do we 'intend' for these fields? This seems essential to any further discussion about the merits of which list (which, I agree, are important for reasons you've mentioned) 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190905/2cfdb88c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190905/2cfdb88c/attachment-0001.p7s>