[Servercert-wg] [EXTERNAL] State or Province

Tim Hollebeek tim.hollebeek at digicert.com
Thu Sep 5 15:56:52 MST 2019

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.


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.




From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Thursday, September 5, 2019 11:35 AM
To: Erwann Abalea <Erwann.Abalea at docusign.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [EXTERNAL] State or Province




On Thu, Sep 5, 2019 at 2:21 PM Erwann Abalea <Erwann.Abalea at docusign.com <mailto:Erwann.Abalea at docusign.com> > wrote:

The point here is that ISO3166-x is not purely technical, it’s also politically tainted. How to use 3166-1 is already not clearly defined (the text present in the BR doesn’t cover all cases), I don’t think adding a MUST related to 3166-2 will solve anything.


Sure, but that's true of anything geographic or jurisdictional based, because those are inherently political questions.


I don't think you can say it wouldn't solve anything; very clearly, it would give consistency. I understand your argument may be that consistency is undesirable, because the flexibility afforded CAs today allows them to make up the rules as they go based on the political whims and fashion of the time, but ostensibly, that flexibility is a problem.


To move the discussion forward, more concretely, what would you advocate as a solution to ensure that, for a given organization, it can be reliably and consistently encoded independent of the factors with respect to the validation agent performing the validation, the CA issuing the certificate, and the QIIS/QGIS used? If there are other options, like what Joanna highlighted, we absolutely should be talking about them. But we can't just throw our hands up, embrace nihilism, and say "This is hard!"


If we wanted to embrace that nihilism, we'd stop issuing certs with those fields entirely. Yet that seems like for some CAs and subscribers, it would cause as many or more problems than it solves. So let's try to solve the simple problem of consistency, and suggestions you have to improve that are truly welcome. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190905/338587c1/attachment.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/338587c1/attachment.p7s>

More information about the Servercert-wg mailing list