Re: [cabfpub] [EXT] Re: Naming rules

[Tarah Wheeler via Public]

Are we anticipating no possible conflicts in the future over naming when
it comes to specifically Taiwanese-unique names?


-- 
Tarah M. Wheeler
Principal Security Advocate and Sr Director of Engineering - Website
Security - 
Delivering Confidence for Customers and Consumers by Securing Websites and
Applications
Symantec Corporation
www.symantec.com 

(206) 276-4920
ta...@symantec.com 

 

This message (including any attachments) is intended only for the use of
the individual or entity to which it is addressed and may contain
information that is non-public, proprietary, privileged, confidential, and
exempt from disclosure under applicable law or may constitute as attorney
work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and (i) destroy
this message if a facsimile or (ii) delete this message immediately if
this is an electronic communication.





On 3/21/17, 2:13 PM, "Public on behalf of Gervase Markham via Public"
 wrote:

>On 21/03/17 10:51, Jeremy Rowley via Public wrote:
>> Despite the discussion today, I¹m still not clear on why the cert can¹t
>> include locality information.
>
>The short answer to this question is:
>
>a) they want to use their existing X509 names, which don't include it
>b) it's safe to not include it, because the entities concerned have
>all-Taiwan-unique names
>
>Gerv
>
>___
>Public mailing list
>Public@cabforum.org
>https://clicktime.symantec.com/a/1/bVfQwQfZe607QZE1Dxue3JkXUjxLRckEHObpGn1
>DvNU=?d=AoOo-LrE42tjPdig5Z-AvCfNVIv8lmjWo7ahlc-NsGzNDJcfl1n2EPEepLMQ-5ar2v
>9-msma49fuX5WSspSPxstjuHsnXhqWAJg8vNMyyP_sqXeWBjfyuryz3o9F5Esb_qXUhgm5h7yZ
>qD0q4ObfKkoD1IG9BBjifN-baDIVUIdkwSYdPCtqBp7WNGK18r619G-W-1xwez3u_GdIRr8a53
>U1eqXZsrHTiOx6ddlOqy8qxEzT5id-6X_2gGXGLPAAdZepi1pzIdKZFtlLmFAtgyqX_DpR0-ev
>ZzZkeGFAu-vvkXiXnAkPHccRrcVb-uHTKbV1WJvXVxqKuNmGDcWnC4DTe6NxlcrgD7C_-F15_W
>-QJRlXmxXm9Vk%3D=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fpubli
>c

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Naming rules

[Gervase Markham via Public]

On 21/03/17 10:51, Jeremy Rowley via Public wrote:
> Despite the discussion today, I’m still not clear on why the cert can’t
> include locality information. 

The short answer to this question is:

a) they want to use their existing X509 names, which don't include it
b) it's safe to not include it, because the entities concerned have
all-Taiwan-unique names

Gerv

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Naming rules

[Jeremy Rowley via Public]

Despite the discussion today, I’m still not clear on why the cert can’t
include locality information. Although there is a national registry, what
prohibits a CA from adding the Locality information based on address? Even
if there are multiple localities for an organization, does that matter?
Can’t the entity requesting the cert decide which one they want included? 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of ??? via
Public
Sent: Sunday, March 19, 2017 9:23 AM
To: CA/Browser Forum Public Discussion List 
Cc: 王文正 
Subject: Re: [cabfpub] Naming rules

 

Peter,

 

I have proposed a minimum change to the BRs to accommodate X.500 directory
naming rules of existing PKIs in my reply to Gerv’s mail. In that reply, I
have made the rationales why the BRs should embrace the existing X.500
naming rules. I also explain it is not proper to add an RDN with the
localityName attribute or stateOrProvinceName attribute to the DN of a
national-level entity, because doing so will cause misleading under the
X.500 namespace. Therefore, I would not repeat my rationales here.

 

As for your argument about "there are always localities that can be added
into the subject DN", please see my reply inline.

 

> On March 10, 2017, at 11:33 PM, Peter Bowen < p...@amzn.com
 > wrote:

> [snip]

> Based on everything you have provided so far, there is no 

> evidence that Taiwan does not have localities (cities, 

> towns, villages, or similar) or that they are not used in 

> postal addressing.  Much to the contrary, every postal 

> address example you have provided has included a 

> locality.  Therefore this appears to be a situation where 

> the PKI does not want to change (possibly for quite valid 

> reasons) rather than cannot change.



Yes, there are always different levels of "localities" under a jurisdiction
or country. We never said Taiwan does not have localities. What we argue is
that does it makes sense to force adding an RDN with the localityName
attribute or stateOrProvinceName attribute to the DN of a national-level
entity?

 

I had not participated in the early stage discussions of CAB Forum,
therefore I just do not understand why CAB though it is so important to
include the applicant's location of existence or operation so that the BRs
mandate at least one of the localityName attribute or stateOrProvinceName
attribute must exist in the subject DN? I guess it is because the only
Subject Identity Information that many commercial CAs can verify is whether
the applicant actually exists and is in operation and they have no way to
guarantee the uniqueness of the subject DN because they have no link to the
official registration database maintained by the government. Therefore, the
CAB BRs simply leveraged the naming attributes to indicate the identity and
location of the applicant but avoid interpreting RDNs as "subordinate"
relationships and do not guarantee the uniqueness of the subject DN.

 

However, there are existing PKIs where the X.500 directory naming rules are
endorsed by the government and CAs in the PKI have the authority to link to
the official registration database maintained by the government. Those PKIs
actually provide better quality of subject identity information. I think the
purpose of CAB forum is to improve the security of website identities, why
not we embrace the subject identity information provided by these existing
PKIs if they would not cause any compatibility problems?

 

As I mentioned, in the X.500 naming conventions, the DN of a national-level
entity will not need to have a RDN with the localityName attribute or
stateOrProvinceName attribute. For example, the Executive Yuan (i.e., the
Cabinet of our government) in the X.500 naming rules of Taiwan Government
PKI (GPKI) will be:

 

C=TW, O=Executive Yuan

 

This is unambiguous naming for Taiwan people because everybody knows that
there is only one Executive Yuan in Taiwan.

 

If you want to enforce adding a localityName in the DN of the Executive Yuan
of Taiwan, the DN will looks like:

 

C=TW, L=Taipei City, O=Executive Yuan

This is not only not suitable for the "subordinate" naming conventions of
the X.500 but also misleading to Taiwan people. Besides, the executive yuan
is a national-level entity, it has many offices all over the country, and
the question is which location should be added into its DN?

 

I believe this is the same reason why in the Common Certificate Policy of US
FPKI, the naming form of the Device names is defined as follows:

 

C=US, o=U.S. Government, [ou=department],  [ou=agency],
[ou=structural_container], cn=device name

 

With the X.500 naming conventions, the name form will not be:

 

C=US, S="Washington, D.C. ", o=U.S. Government, [ou=department],
[ou=agency], [ou=structural_container], cn=device name

 

In addition, I have seen some foreign CAs issuing SSL certificates to
customers in Taiwan with strange Subject DNs. 

Re: [cabfpub] Meaning of BR 9.16.3

[Ryan Sleevi via Public]

Kirk,

I'm afraid you've misunderstood my argument. We're actually in agreement on
this point. However, if you recall the ample discussion during the
Scottsdale F2F, the arguments I presented here on the mailing list were
very much the topic of discussion then. The goal is to ensure there is
transparency when local jurisdictional law conflicts with what are intended
to be internationally-applicable guidelines, and to allow the Forum members
to consider whether to normalize this, and Browser members whether to
forbid this.

You will note 9.16.3 very much has security risks. We discussed those
several times. This is why we have a transparency requirement. When such
conflicts emerge - between local laws and the Baseline Requirements - the
Forum, and particularly the root store members, need to sort out whether
those conflicts allow CAs within that jurisdiction to continue to meet the
security standards and goals intended.

On Tue, Mar 21, 2017 at 10:19 AM, Kirk Hall 
wrote:

> (Changing the Subject for this discussion)
>
>
>
> Ryan, I don’t think you are reading BR 9.16.3 correctly when you posted
> this:
>
>
>
> “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.”
>
>
>
> Look at the actual text of BR 9.16.3 below.  The process (in abbreviated
> form) is as follows:  If a CA finds a conflict between the BRs and a
> government “Law”, the CA may modify the BR requirement to the minimum
> extent necessary to make the BR requirements legal under the “Law”.  The CA
> must then include notice of that modification of the BRs in Sec. 9.16.3 of
> its CPS, and must also notify the Forum, but the CA can then issue certs
> following the BR procedure as modified by the Law.
>
>
>
> A purpose of the notification requirement is “so that the CA/Browser
> Forum may consider possible revisions to these Requirements accordingly.”
> There is no time limit on how long the CA may continue to issue certs
> following the BRs as modified by the Law (the Forum may or may not make any
> changes to the BRs – that does not affect the CAs decision under BR
> 9.16.3), and BR 9.16.3 says nothing about the Forum being able to make a
> determination about the acceptability of the CA’s determination.
>
>
>
> It’s possible that the Forum or individual Forum members may say “we
> disagree about your decision that there is a conflict between the BRs and
> the Law, and so we don’t think you should make that modification to the
> BRs”, and a CA should carefully consider those arguments and decide if they
> are valid or not, but BR 9.16.3 is silent on that process.
>
>
>
>
>
> *BR 9.16.3. Severability*
>
>
>
> In the event of a conflict between these Requirements and a law,
> regulation or government order (hereinafter
>
> 'Law') of any jurisdiction in which a CA operates or issues certificates,
> a CA MAY modify any conflicting
>
> requirement to the minimum extent necessary to make the requirement valid
> and legal in the jurisdiction.
>
> This applies only to operations or certificate issuances that are subject
> to that Law. In such event, the CA
>
> SHALL immediately (and prior to issuing a certificate under the modified
> requirement) include in Section
>
> 9.16.3 of the CA’s CPS a detailed reference to the Law requiring a
> modification of these Requirements under
>
> this section, and the specific modification to these Requirements
> implemented by the CA.
>
>
>
> The CA MUST also (prior to issuing a certificate under the modified
> requirement) notify the CA/Browser
>
> Forum of the relevant information newly added to its CPS by sending a
> message to questi...@cabforum.org
>
> and receiving confirmation that it has been posted to the Public Mailing
> List and is indexed in the Public Mail
>
> Archives available at https://cabforum.org/pipermail/public/ (or such
> other email addresses and links as the
>
> Forum may designate), so that the CA/Browser Forum may consider possible
> revisions to these
>
> Requirements accordingly.
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Ryan
> Sleevi via Public
> *Sent:* Tuesday, March 21, 2017 8:34 AM
> *To:* Dimitris Zacharopoulos 
> *Cc:* Ryan Sleevi ; CA/Browser Forum Public Discussion
> List 
> *Subject:* Re: [cabfpub] C=GR, C=UK exceptions in BRs
>
>
>
>
>
>
>
> On Tue, Mar 21, 2017 at 3:04 AM, Dimitris Zacharopoulos 
> 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 

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

[Geoff Keating via Public]

> On Mar 20, 2017, at 5:59 AM, Dimitris Zacharopoulos  wrote:
> 
> On 20/3/2017 11:05 πμ, Geoff Keating wrote:
>> 
>> I also do not see where the EU has actually approved, requested, suggested, 
>> or even hinted at the use of this value in certificates.  A specific 
>> reference would be needed.
> 
> Looking the other way won't change the fact that these well-defined 
> exceptions have been properly documented in the 1501/2015 decision. I have 
> not read the minutes of the corresponding EU proceedings but it is strange 
> you suggesting they were not properly requested, suggested and approved 
> through the official EU channels.

I did not say that.  I have no opinion on that.  What I was trying to say is 
that the decision you quoted, which I have read, does not seem to document 
these ‘well-defined exceptions’ in the context of the countryName field in a 
certificate.

>> Likewise Greece; but Greece is literally the last country in the world that 
>> I can imagine saying that an international body should be ignored in favor 
>> of a country's preferred nomenclature, because of their dispute over 
>> Macedonia.
> 
> This is clearly a political statement that is out of the Forum's usual line 
> of arguments (at least for the years I participate). I may have a personal 
> opinion on political issues (about "FYROM") but refrain from making political 
> statements in a technically oriented standards group like the CA/B Forum. 
> Having said that, I will not judge right or wrong or question the reasoning 
> behind official EU, Greek, US laws. I think this is also in the spirit of 
> 9.16.3 where "local law" supersedes the BRs in case of a conflict between the 
> two. I suggest we avoid making similar political statements.

I did not intend to make a political statement; and to be very clear, I am not 
expressing any opinion on the dispute other than that it exists.  I seem to 
have hit a sensitive topic, which was not my intention, and I apologise for any 
bad feelings that may have resulted.

I do not think we can decide on the naming or coding of countries without it 
becoming political, and I do not think we can have a political discussion 
without causing bad feelings.  So I think the CABforum should not become 
involved, and leave the topic to the ISO.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Meaning of BR 9.16.3

[Kirk Hall via Public]

(Changing the Subject for this discussion)

Ryan, I don’t think you are reading BR 9.16.3 correctly when you posted this:

“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.”

Look at the actual text of BR 9.16.3 below.  The process (in abbreviated form) 
is as follows:  If a CA finds a conflict between the BRs and a government 
“Law”, the CA may modify the BR requirement to the minimum extent necessary to 
make the BR requirements legal under the “Law”.  The CA must then include 
notice of that modification of the BRs in Sec. 9.16.3 of its CPS, and must also 
notify the Forum, but the CA can then issue certs following the BR procedure as 
modified by the Law.

A purpose of the notification requirement is “so that the CA/Browser Forum may 
consider possible revisions to these Requirements accordingly.”  There is no 
time limit on how long the CA may continue to issue certs following the BRs as 
modified by the Law (the Forum may or may not make any changes to the BRs – 
that does not affect the CAs decision under BR 9.16.3), and BR 9.16.3 says 
nothing about the Forum being able to make a determination about the 
acceptability of the CA’s determination.

It’s possible that the Forum or individual Forum members may say “we disagree 
about your decision that there is a conflict between the BRs and the Law, and 
so we don’t think you should make that modification to the BRs”, and a CA 
should carefully consider those arguments and decide if they are valid or not, 
but BR 9.16.3 is silent on that process.


BR 9.16.3. Severability

In the event of a conflict between these Requirements and a law, regulation or 
government order (hereinafter
'Law') of any jurisdiction in which a CA operates or issues certificates, a CA 
MAY modify any conflicting
requirement to the minimum extent necessary to make the requirement valid and 
legal in the jurisdiction.
This applies only to operations or certificate issuances that are subject to 
that Law. In such event, the CA
SHALL immediately (and prior to issuing a certificate under the modified 
requirement) include in Section
9.16.3 of the CA’s CPS a detailed reference to the Law requiring a modification 
of these Requirements under
this section, and the specific modification to these Requirements implemented 
by the CA.

The CA MUST also (prior to issuing a certificate under the modified 
requirement) notify the CA/Browser
Forum of the relevant information newly added to its CPS by sending a message 
to questi...@cabforum.org
and receiving confirmation that it has been posted to the Public Mailing List 
and is indexed in the Public Mail
Archives available at https://cabforum.org/pipermail/public/ (or such other 
email addresses and links as the
Forum may designate), so that the CA/Browser Forum may consider possible 
revisions to these
Requirements accordingly.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Tuesday, March 21, 2017 8:34 AM
To: Dimitris Zacharopoulos 
Cc: Ryan Sleevi ; CA/Browser Forum Public Discussion List 

Subject: Re: [cabfpub] C=GR, C=UK exceptions in BRs



On Tue, Mar 21, 2017 at 3:04 AM, Dimitris Zacharopoulos 
> 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 

Re: [cabfpub] What is identity anyway? Was: C=GR, C=UK exceptions in BRs

[Ryan Sleevi via Public]

Phillip,

That does sound like a rather personal attack, questioning the person
rather than the facts. I would be happy to provide source and citations
that conflict with your representation of the history.

That said, perhaps we can focus on the substance of my request, which is:
What is your goal with this thread? It sounds like you're suggesting DV has
too much identity bound to it - despite the only identity being a binding
of domain and key. Is that a correct understanding?

On Tue, Mar 21, 2017 at 9:53 AM, phill...@comodo.com 
wrote:

> Since I was there and you were not, I don’t see how you think you can tell
> me what really happened.
>
>
>
>
> On Mar 21, 2017, at 9:48 AM, Ryan Sleevi  wrote:
>
> Phillip,
>
> I must confess, it's hard to see what point you're attempting to make, so
> I'm hoping you might take time to summarize into what you believe is an
> actionable next step, rather than a discussion of the history, particularly
> one which I would be happy to demonstrate as historically inaccurate.
>
> On Tue, Mar 21, 2017 at 9:28 AM, phill...@comodo.com 
> wrote:
>
>> There are very few things that are as intrinsically political than the
>> names of states. So complaining about the naming of states being political
>> is to miss the point entirely.
>>
>> From a technical point of view, there are two concerns when considering
>> an identifier.
>>
>> 1) Is the identifier unambiguous? Could the identifier correspond to more
>> than one distinct entity?
>> 2) Is the identifier resolvable? Can a party attempting to resolve the
>> identifier determine what it means?
>>
>> For the purposes of the WebPKI, we are also interested in two particular
>> aspects of identity:
>>
>> 1) To establish accountability through legal consequences should a
>> subject make a material misrepresentation in a transaction.
>> 2) To enable binding of a physical world identity to an online identity.
>>
>> When I first started doing PKI, I thought that the use of the X.500 names
>> in addition to the DNS names was a mistake. Since then, I have come to
>> understand that it is actually very important. Because there are offline
>> identities that pre-existed the cyber world and there are reputations bound
>> to them that people wish to make use of online.
>>
>> If we wish to engage the services of nation state law enforcement and
>> nation state courts, then we have to be willing to meet whatever criteria
>> the nation states apply to provide them.
>>
>> The topic of ‘identity’ is something that I really try to avoid. The
>> objective of the WebPKI is not to establish identity, it is designed to
>> establish an expectation of consequences and to enable the use of an
>> offline reputation. Both of which are bound to an identity.
>>
>>
>> When the WebPKI was first developed, the only objective was to establish
>> consequences and provide access to offline reputation. Today we use it for
>> much more. In particular we use it for entities whose only existence is
>> online. For these organizations, offline reputation is irrelevant and
>> consequences may not be relevant. Hence the need for EV and DV as distinct
>> quanta of trust.
>>
>> The proposals to move the Web to encrypted by default and beyond that to
>> mandate encryption create a third category of WebPKI use. Or maybe they
>> should be outside the WebPKI entirely.
>>
>> The big fight in the early development of the WebPKI was whether it would
>> be ‘open’ or ‘closed’. In particular, would anybody be able to get a
>> certificate to engage in Internet commerce from a range of competing
>> providers on flat rate terms or would the infrastructure be closed like a
>> game console platform with the platform provider taking a cut of every
>> sale. One of the reasons we have the model we do is because of a man called
>> Michael Baum who showed how an open PKI was in fact practical at a time
>> when most people thought it wasn’t.
>>
>> If we are going to go to mandate use of encryption, the access issue is
>> raised again unless we create a third category of certificate that is below
>> DV and provides no degree of assurance whatsoever and does not result in an
>> an affirmative security signal in the browser. (And why would you need a
>> signal if everything is always encrypted).
>>
>> In retrospect, I think I probably made a mistake in not recognizing that
>> DV and EV were in fact meeting two different but legitimate needs earlier.
>> I think we might be making the same mistake again with DV and whatever it
>> is that meets the ubiquitous encryption need.
>>
>>
>>
>> On Mar 21, 2017, at 3:04 AM, Dimitris Zacharopoulos via Public <
>> public@cabforum.org> wrote:
>>
>>
>>
>> On 21/3/2017 5:44 πμ, Ryan Sleevi 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 > > wrote:
>>>
>>> Let 

Re: [cabfpub] What is identity anyway? Was: C=GR, C=UK exceptions in BRs

[philliph--- via Public]

Since I was there and you were not, I don’t see how you think you can tell me 
what really happened.




> On Mar 21, 2017, at 9:48 AM, Ryan Sleevi  wrote:
> 
> Phillip,
> 
> I must confess, it's hard to see what point you're attempting to make, so I'm 
> hoping you might take time to summarize into what you believe is an 
> actionable next step, rather than a discussion of the history, particularly 
> one which I would be happy to demonstrate as historically inaccurate.
> 
> On Tue, Mar 21, 2017 at 9:28 AM, phill...@comodo.com 
>   > wrote:
> There are very few things that are as intrinsically political than the names 
> of states. So complaining about the naming of states being political is to 
> miss the point entirely.
> 
> From a technical point of view, there are two concerns when considering an 
> identifier.
> 
> 1) Is the identifier unambiguous? Could the identifier correspond to more 
> than one distinct entity?
> 2) Is the identifier resolvable? Can a party attempting to resolve the 
> identifier determine what it means?
> 
> For the purposes of the WebPKI, we are also interested in two particular 
> aspects of identity:
> 
> 1) To establish accountability through legal consequences should a subject 
> make a material misrepresentation in a transaction.
> 2) To enable binding of a physical world identity to an online identity. 
> 
> When I first started doing PKI, I thought that the use of the X.500 names in 
> addition to the DNS names was a mistake. Since then, I have come to 
> understand that it is actually very important. Because there are offline 
> identities that pre-existed the cyber world and there are reputations bound 
> to them that people wish to make use of online.
> 
> If we wish to engage the services of nation state law enforcement and nation 
> state courts, then we have to be willing to meet whatever criteria the nation 
> states apply to provide them.
> 
> The topic of ‘identity’ is something that I really try to avoid. The 
> objective of the WebPKI is not to establish identity, it is designed to 
> establish an expectation of consequences and to enable the use of an offline 
> reputation. Both of which are bound to an identity. 
> 
> 
> When the WebPKI was first developed, the only objective was to establish 
> consequences and provide access to offline reputation. Today we use it for 
> much more. In particular we use it for entities whose only existence is 
> online. For these organizations, offline reputation is irrelevant and 
> consequences may not be relevant. Hence the need for EV and DV as distinct 
> quanta of trust.
> 
> The proposals to move the Web to encrypted by default and beyond that to 
> mandate encryption create a third category of WebPKI use. Or maybe they 
> should be outside the WebPKI entirely.
> 
> The big fight in the early development of the WebPKI was whether it would be 
> ‘open’ or ‘closed’. In particular, would anybody be able to get a certificate 
> to engage in Internet commerce from a range of competing providers on flat 
> rate terms or would the infrastructure be closed like a game console platform 
> with the platform provider taking a cut of every sale. One of the reasons we 
> have the model we do is because of a man called Michael Baum who showed how 
> an open PKI was in fact practical at a time when most people thought it 
> wasn’t.
> 
> If we are going to go to mandate use of encryption, the access issue is 
> raised again unless we create a third category of certificate that is below 
> DV and provides no degree of assurance whatsoever and does not result in an 
> an affirmative security signal in the browser. (And why would you need a 
> signal if everything is always encrypted).
> 
> In retrospect, I think I probably made a mistake in not recognizing that DV 
> and EV were in fact meeting two different but legitimate needs earlier. I 
> think we might be making the same mistake again with DV and whatever it is 
> that meets the ubiquitous encryption need.
> 
> 
> 
>> On Mar 21, 2017, at 3:04 AM, Dimitris Zacharopoulos via Public 
>> > wrote:
>> 
>> 
>> 
>> On 21/3/2017 5:44 πμ, Ryan Sleevi 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 >> > wrote:
>>> Let me try to provide some reasons in favor of allowing these two 
>>> exceptions.
>>> 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 
>>> 

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

[Ryan Sleevi via Public]

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, phill...@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 
> 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 
> 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
>>
>>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 

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

[Dimitris Zacharopoulos via Public]

On 21/3/2017 2:44 μμ, phill...@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 
> 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 
> 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

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 

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

[philliph--- via Public]

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  
> 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  > wrote:
> Let me try to provide some reasons in favor of allowing these two exceptions.
> 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 
>  
> 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.
>  
> 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.
> 
> 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 

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

[Ryan Sleevi via Public]

On Tue, Mar 21, 2017 at 3:04 AM, Dimitris Zacharopoulos 
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 

Re: [cabfpub] Naming rules

[realsky(CHT) via Public]

Dear Kirk,Ben,Dimitris and Jeremy,

 Good morning. Although most of the time of CP reviewing WG today will 
focus on the ballot Dimitris proposed. Would you mind giving me thirty minutes 
to present "Amendment of  SSL BR 7.1.4.2.2 :Add Section K for existing PKI" 
propsed by Wen-Cheng Wang ? If time is not enough, it may take up the 
Validation WG discussion session. I also hope Peter have time to see and 
support our ballot.

Sincerely Yours,

  Li-Chun Chen



-Original message-
From:Gervase Markham 
To:王文正 ,CA/Browser Forum Public Discussion List 

Cc:陳立群 
Date:Tue, 21 Mar 2017 06:24:18
Subject:[外部郵件] Re: [cabfpub] Naming rules

On 19/03/17 11:18, 王文正 wrote:
> Thanks for your positive feedback. I am very sorry for our late in
> reply. We carefully examined and thought about how to propose minimum
> changes to the BRs to embrace subject naming rules of existing PKI. 

Thank you for your proposal. Having helped guide the conversation to
this point, I'm not the right person to assess the wisdom of what you
propose; I will leave that to others. :-)

Gerv


本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 
如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
Please be advised that this email message (including any attachments) contains 
confidential information and may be legally privileged. If you are not the 
intended recipient, please destroy this message and all attachments from your 
system and do not further collect, process, or use them. Chunghwa Telecom and 
all its subsidiaries and associated companies shall not be liable for the 
improper or incomplete transmission of the information contained in this email 
nor for any delay in its receipt or damage to your system. If you are the 
intended recipient, please protect the confidential and/or personal information 
contained in this email with due care. Any unauthorized use, disclosure or 
distribution of this message in whole or in part is strictly prohibited. Also, 
please self-inspect attachments and hyperlinks contained in this email to 
ensure the information security and to protect personal information.


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Results on Ballot 187 - Make CAA Checking Mandatory

[Gervase Markham via Public]

Hi,

On 20/03/17 22:02, y-iida--- via Public wrote:
> New text reads:
>CAA checking is optional for certificates for which a
>Certificate Transparency pre-certificate was created and
>logged in at least two public logs, and for which CAA was
>checked.
> 
> This ends with ``for which CAA was checked.''  Does it mean
> that CA MUST look up DNS CAA resource records, regardless of CT
> logging?

I don't quite understand the question. The entire point of the ballot is
to make it mandatory (i.e. MUST) in almost all circumstances for CAs to
look up DNS CAA resource records. The text you quote is one of the small
number of exceptions, which basically says you don't have to do it twice
for CT (although you can if you like and it's easier).

Gerv



signature.asc
Description: OpenPGP digital signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Dimitris Zacharopoulos via Public]

On 21/3/2017 5:44 πμ, Ryan Sleevi 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 
> 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

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.


I guess we disagree on the fact that you need justification for a 
political decision made by the European Union, while I take it for 
granted. The fact that "off-topic" (at least some people would 
characterize them as such) comments were made, with political tone, 
isn't something that should be used to dismiss the rest of the 
"on-topic" and valuable feedback and shouldn't be a reason, alone, to 
dismiss a subject being discussed (or any issue for that matter). 
Off-topic comments have been posted in the past and will certainly be 
posted in the future :)




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.




 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.


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 :)




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