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

[Ryan Sleevi]

Phill,

I'd be happy to correct or apologize on-list if you would happy to discuss
off-list what you believe is a personal attack. I'm sure if you re-read my
statement, you will see it questions the quality and validity of your
arguments, and not you as a person, and so I do not believe it is fair or
appropriate to question the professionalism or to suggest it's a personal
attack to highlight these flaws.

On Tue, Mar 21, 2017 at 8:44 AM, philliph at comodo.com <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
>
>
> On Mar 20, 2017, at 11:44 PM, Ryan Sleevi via Public <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>
> 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
> https://cabforum.org/mailman/listinfo/public
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170321/f4a4baa9/attachment.html>