[cabfpub] C=GR, C=UK exceptions in BRs

Kirk Hall Kirk.Hall at entrustdatacard.com
Fri Mar 17 22:55:29 UTC 2017


Ryan makes a good point – where there is a conflict between local law or practice (or desired practice) and the BRs, the best first step is to amend the BRs to allow compliance with local law or practice (or desired practice).

As I recall the country codes we are all stuck with were created in the 1960s for a purpose unrelated to SSL and digital certificates.  There must have been a good reason for representing the United Kingdom (England, Wales, Scotland (for now), and Northern Ireland) as “GB” when Northern Island (part of the UK) is not in Great Britain and UK is the more generally known acronym for the United Kingdom – but I can’t imagine what the good reason was.

Instead of a ballot that presents a sweeping new structure for country names, or points to another new document, maybe we just create an Appendix to the BRs that allows different country codes for Greece and the United Kingdom (as an alternative).  We would endorse such a ballot.

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi via Public
Sent: Friday, March 17, 2017 1:12 PM
To: Dimitris Zacharopoulos <jimmy at it.auth.gr>
Cc: Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] C=GR, C=UK exceptions in BRs



On Fri, Mar 17, 2017 at 4:08 PM, Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>> wrote:
On Fri, Mar 17, 2017 at 3:01 PM, Dimitris Zacharopoulos <jimmy at it.auth.gr<mailto:jimmy at it.auth.gr>> wrote:
The "spirit" of 9.16.3 is also to bring conflicting requirements to the CA/B Forum to consider possible revisions accordingly. This is exactly what I am doing, without violating the current BRs, but hoping that the CA/B Forum will read this as a conflicting requirement which could be resolved by adding a simple exception, without creating any risk in current practices.

For what it's worth - I agree with this sentiment, and it's worth considering, separate of 9.16.3, whether to _revise_ the BRs to accomodate this case. Such revisions must account for ambiguity. In many ways, the BRs strive to eliminate the rampant ambiguity that existed due to CAs' various practices, as a whole (since no two CAs really have the same CP/CPS), and so we should strive, as much as possible, to unambiguously represent the information that members see as valuable.

Of course, it might be that identity information in certificates is not valuable, precisely because of ambiguities and conflicts that naturally emerge from CAs. In that case, it might be worthwhile to simply stop trying to represent identity information within certificates, and accept that ambiguity, rather than try to carve it up. However, since the Forum values identity information at present, it makes sense to opt for strictness as much as possible, or to explicitly describe the deviations permitted and assess their risk, as you propose doing and is worth at least discussing :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170317/139329fb/attachment-0003.html>


More information about the Public mailing list