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

Ryan Sleevi sleevi at google.com
Tue Mar 21 12:33:45 UTC 2017


On Tue, Mar 21, 2017 at 3:04 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr>
wrote:

>
> As mentioned elsewhere, these documents don't apply from a 9.16.3 or from
> a perspective of law. Further, I think you can agree that even if we accept
> such documents, their scope is to apply to a jurisdictional boundary,
> except you're proposing that these be adopted at an international level (as
> all certificates are inherently worldwide). So, in effect, you're proposing
> that the first country to pass a law gets to bypass any form of
> international agreement or consensus, and instead declare 'squatters'
> rights.
>
> I don't believe you intended to put it like that, but I want to highlight
> that is effectively what this justification is, so that you can understand
> why it's undesirable.
>
>
> Indeed I never intended to put it like that but I think 9.16.3 allows for
> exactly what you just described as undesirable (for better or worse). To
> the minimum, it is unclear what the boundaries are. That is, if a country
> passes a law that conflicts with the BRs and the CA has to abide with it,
> it must abide with it. To better understand this and possibly make it clear
> for others let me give a theoretical example. If there was a Greek law that
> said "you need to be able to issue publicly trusted SSL Certificates with
> C=EL for such and such cases", 9.16.3 would allow a CA (not necessarily a
> CA operated in Greece) to issue and inform the CA/B Forum's public list
> about this conflict.
>
> Do you agree with this interpretation? I think this is a key issue that
> the forum should try to explain and clarify as soon as possible. I also
> welcome other members that wish to offer their perspective on this.
>

No, I actively disagree with this interpretation.

The purpose of 9.16.3 is only to allow such a CA to operate until the Forum
- or, more aptly, its Browser/Root Store members - have made a
determination about the acceptability.

For example, if a jurisdiction were to impose a law that all CAs within
their country must issue a certificate for any domain on the request of Law
Enforcement, then
1) That CA will have to notify the Forum before doing so
2) That CA will do so
3) That CA will promptly be distrusted in at least one browser, if not more

9.16.3 should not be used as a "get out of jail free" card (as in, from the
boardgame Monopoly). That it could have been used by such is precisely why
I raised attention to the matter and the need for notification and reform.

If a Greek law said you must use C=EL, then it will be up to browser
members to determine whether or not that's acceptable. If not, they can and
should remove trust in CAs from that country, because the law in that
country is incompatible with the security needs.


> But now you've introduced an ambiguity and overload whose "source of
> truth" can no longer be discerned.
>
>
> I am not sure I understand this comment or where you see ambiguity. There
> would be a well-defined exception for two countries to be represented with
> two different identifiers each. This makes it clear, at least to me, that
> when I see a certificate with either C=GR or C=EL, the Subject's Country is
> Greece :)
>

The ambiguity of course is that ISO 3166-1 is no longer the authoritative
version. It's whatever the CA/Browser Forum has made up, which looks like
ISO 3166-1. The Forum making up its own rules has already lead to actively
exploited security issues in the past (such as the reserved e-mail
addresses).


> Being unable to see an ambiguity, I fail to see a security threat here.
> The source of information is still ISO3166-1 but we are discussing the "UK"
> and "EL" extra identifiers for two specific jurisdictions. If "EL" was
> listed as exceptionally reserved just as the "UK" label is, would you agree
> with Gerv that this would make things clearer and easier to allow for these
> exceptions?
>

It would be easier to follow the exceptions, but it no less makes them
undesirable.


> IMHO, by questioning these reason, you evidently become political. I
> understand the fact that it is merely impossible to avoid some political
> discussions, sooner or later, when it comes to building policy documents.
> In order to achieve the goal to "stay apolitical to the extent possible",
> IMO the forum should try to resolve policy conflicts with minimal or no
> impact to the ecosystem based on standards and specific processes like the
> one we are following now (allowed thanks to the last paragraph of 9.16.3).
> I fully understand the argument of building on top of International
> standards, agreements, treaties and such ("giants" as you elegantly
> described). My somewhat similar thought was that the European Union's
> decisions look like they are coming from a "giant" as well :)
>

I disagree strongly, and perhaps this is the subject of our disconnect.
You're using one single jurisdiction - the EU - though made up of several
member states - to justify ignoring an international consensus approach.

I think it's useful to have this discussion, but I fail to see any
compelling reason to deviate from the process of ISO 3166-1. At best, it
seems to be a question of Greece wanting to do its own thing. While some
members may be quite happy to let every country do its own thing and set
its own standards, I disagree strongly with that cavalier approach that
ignores consensus.

I think we're in agreement that the absolute minimum necessary is a
reservation that ensures no conflicts for C=UK or C=EL. However, even with
such an exceptional reservation, I fail to see the compelling case for
permitting two jurisdictions to be identified by multiple identifiers.
Everyone who relies on this identity information will need to know that
C=GR and C=EL are the same, despite ISO 3166-1 not actually assigning the
latter to GR (just "exceptionally reserved").
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170321/758a8129/attachment-0003.html>


More information about the Public mailing list