<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Ryan,</div><div class="">‘</div><div class="">Do you think you could at least try to conduct your discussion here in an approximately professional fashion?</div><div class=""><br class=""></div><div class="">The constant personal attacks are really unhelpful.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Phill</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 20, 2017, at 11:44 PM, Ryan Sleevi via Public <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Dimitris,<div class=""><br class=""></div><div class="">Thanks for providing concrete reasons to support such a change. Replies inline.<br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Mar 20, 2017 at 4:03 AM, Dimitris Zacharopoulos <span dir="ltr" class=""><<a href="mailto:jimmy@it.auth.gr" target="_blank" class="">jimmy@it.auth.gr</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="">
Let me try to provide some reasons in favor of allowing these two
exceptions.<br class="">
<ol class="">
<li class="">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 <a href="http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015D1505" target="_blank" class="">1505/2015</a>
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.</li></ol></div></blockquote><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class=""><ol class="">
<li class="">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.</li></ol></div></blockquote><div class="">But now you've introduced an ambiguity and overload whose "source of truth" can no longer be discerned.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class=""><ol class="">
<li class="">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?</li></ol></div></blockquote><div class="">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.</div><div class=""><br class=""></div><div class="">In this case, as has been mentioned, the appropriate discussion point would minimally be within the realm of ISO, as Gerv has highlighted.</div><div class=""><br class=""></div><div class="">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. </div></div><br class=""></div></div></div>
_______________________________________________<br class="">Public mailing list<br class=""><a href="mailto:Public@cabforum.org" class="">Public@cabforum.org</a><br class="">https://cabforum.org/mailman/listinfo/public<br class=""></div></blockquote></div><br class=""></body></html>