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

Tue Mar 21 13:01:11 UTC 2017

On 21/3/2017 2:44 μμ, philliph at comodo.com wrote:
>
> Ryan,
> ‘
> Do you think you could at least try to conduct your discussion here in 
> an approximately professional fashion?
>
> The constant personal attacks are really unhelpful.
>
> Phill
>

Philliph, I didn't take Ryan's reply as a personal attack. I understand 
that he often uses strong words and metaphors but the arguments are 
logical from his point of view. We don't have to agree, although it 
would help from time-to-time :)

Dimitris.

>
>> On Mar 20, 2017, at 11:44 PM, Ryan Sleevi via Public 
>> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>>
>> Dimitris,
>>
>> Thanks for providing concrete reasons to support such a change. 
>> Replies inline.
>>
>> On Mon, Mar 20, 2017 at 4:03 AM, Dimitris Zacharopoulos 
>> <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr>> wrote:
>>
>>     Let me try to provide some reasons in favor of allowing these two
>>     exceptions.
>>
>>      1. For reasons unrelated to the CA/B Forum (political or
>>         whatever non-technical reasons), two EU Countries have been
>>         using different two-letter Country Identifiers in addition to
>>         the ones listed in ISO3166-1. These exceptions have been
>>         well-defined in legal EU documents, like the 1505/2015
>>         <http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015D1505>
>>         implementing decision. Since these exceptions are used
>>         Internationally, are well-defined and globally recognized, it
>>         makes sense to allow them to be used in the webPKI as well.
>>
>> So I object to this reasoning because it's unclear what the 
>> justification is for this change. As mentioned, there are clearly 
>> international political issues at play here, and while I think 
>> Phillip's examples are actively unhelpful to making productive 
>> discussion, the fact that he feels they're relevant and on-topic to 
>> this discussion - or the remarks Geoff have made - actively highlight 
>> this.
>>
>> 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.
>>
>>      1. Introducing these well-defined exceptions pose no security
>>         threat because these identifiers are already known for so
>>         long. AFAIU, by adding these two exceptions, no significant
>>         problems have been identified so far in the discussion.
>>         Please note that I am not suggesting "replacing C=GR with
>>         C=EL and C=GB with C=UK" but allowing all of them to be
>>         acceptable.
>>
>> But now you've introduced an ambiguity and overload whose "source of 
>> truth" can no longer be discerned.
>>
>> For example, the conflicting examples Rob and Phillip have given - 
>> only the former of which I'm inclined to trust in this case - do 
>> create ambiguities. If the purpose of the Baseline Requirements is to 
>> agree upon unambiguous representations to the extent possible, by 
>> including full jurisdictional information (as the discussion with 
>> Li-Chun related to the X.500 DIT has shown), then introducing this 
>> change introduces unnecessary ambiguity, and through it, undermines 
>> the goal of including identity information in certificates.
>>
>> Put differently, this poses a thread to the value and usefulness of 
>> the identity information. Since a number of CAs have asserted 
>> identity information is security relevant (hence why they revoke 
>> certificates whose identity information is incorrect or misleading), 
>> we must naturally conclude that this either _does_ represent a 
>> security threat, or that identity information in certificates is not 
>> security relevant, and we should update our documents accordingly.
>>
>>      1. There may be legal reasons for some official government
>>         agencies to be represented by using C=EL or C=UK in the
>>         subject field. Should the Forum prevent that? Should the
>>         Forum question these reasons?
>>
>> Yes. Because the Forum should strive to stay apolitical to the extent 
>> possible, and we achieve that by standing on the shoulder of the 
>> giants who have gone before us, seeking out international consensus 
>> through an assemblage of experts, and when we find reason to deviate, 
>> to do so in a manner that is a consistent application of principles 
>> rather than of en-vogue politics.
>>
>> In this case, as has been mentioned, the appropriate discussion point 
>> would minimally be within the realm of ISO, as Gerv has highlighted.
>>
>> If it helps, you can think of this much like the .onion discussion, 
>> for which Google was opposed to support for such certificates without 
>> an appropriate IANA-reservation of the '.onion' TLD. Without that, 
>> the Forum would have been squatting on a domain without the consensus 
>> process. And while it might have been argued then, much like here, 
>> that .onion wouldn't produce a security risk, we can actually see 
>> that the principle applied (that it's appropriate for the Forum to 
>> squat on TLDs) _did_ create a significant security risk when applied 
>> as a rule ("Internal Server Names"). And if our principles and 
>> justifications are unsafe as general rules, then they are likely 
>> unsafe as exceptions as well, since an exception that is 
>> inconsistently applied is simply exclusionary politics.
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org <mailto:Public at cabforum.org>
>> https://cabforum.org/mailman/listinfo/public
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170321/6213b245/attachment-0003.html>