Subject: Re: [regext] Human Rights Review of draft-ietf-regext-verificationcode

From: "Gould, James" <[email-masked]>
Date: Wed, 3 Oct 2018 13:14:10 +0000

Thanks for the review, Gurshabad. I'll consider your feedback in the context of technical issues with the draft.  The registration of domain names in some jurisdictions may be subject to various requirements that involve verification by a party other than the registry.  The draft is intended for interoperability and is independent of the verification process. The EPP extension takes no position on specific verification processes which are a "local matter" for the implementation. For these reasons, I disagree with your assertion that implementation of the proposed extension will impact domain registrants' right to freedom of expression, right to freedom of assembly and association, and right to privacy. Rather the EPP extension, as the draft describes, is a proposal for a standard framework for the common industry practice of providing proof of verification to meet legal and/or security requirements within a given top-level domain.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 9/20/18, 5:02 PM, "regext on behalf of Gurshabad Grover" <[email-masked] on behalf of [email-masked]> wrote:

    Hi all,
    
    Firstly, thanks to James Gould and the regext working group for
    developing draft-ietf-regext-verificationcode.
    
    As part of efforts in the Human Rights Protocol Considerations (HRPC)
    group, I have reviewed the human rights considerations (using RFC 8280
    as a framework) in draft-ietf-regext-verificationcode-03. Please find
    the review below. Hope that some of these concerns can be addressed
    moving forward.

    HR Review: Verification Code Extension for the EPP
    ==================================================
    
    An assessment of human rights considerations in
    draft-ietf-regext-verificationcode-03.
    
    Introduction
    ------------
    The ‘Verification Code Extension for the Extensible Provisioning
    Protocol (EPP)’ ([VCEPP], hereinafter also referred to as the “draft”)
    describes an extension in the EPP object mappings which supports adding
    a verification code provided by a third-party known as the Verification
    Service Provider (VSP). If the registrant’s data is not “verified” by
    the VSP, it may be prohibited from requesting the execution of EPP
    transform commands.
    
    This is a review of the human rights considerations in the the draft.
    (See [RFC 8280], ‘Research Into Human Rights Protocol Considerations’).
    We believe that the draft does not make adequate considerations for
    human rights: The implementation of the proposed extension will impact
    domain registrants’ right to freedom of expression, right to freedom of
    assembly and association, and right to privacy.
    
    Human Rights Considerations
    ---------------------------
    
    # Privacy ([RFC8280], section 6.2.2)
    
    From [RFC8280]: “Could your protocol improve data minimization?” and
    “Does your document identify potentially sensitive data logged [...]
    and/or for how long that data needs to be retained for technical reasons?”
    
    The draft leaves the precise data shared with the VSP “up to the
    policies of the locality” and outside the scope of the draft. In the
    'domain-registrant' type of verification, both the registrant contact
    information and domain name are sent to the VSP. The registrant contact
    information is sensitive personal information, including name, address,
    telephone number and email address. [RFC5733]
    
    The draft notes that, “the data verified by the VSP MUST be stored by
    the VSP along with the generated verification code to address any
    compliance issues.” The information is retained and “may be accessed at
    a later time.”
    
    Registrants whose personal information will be shared in this way have
    no control over these aspects, which negatively impacts their privacy.
    
    # Content Agnosticism ([RFC8280], section 6.2.3)
    
    From [RFC8280]: “Does your protocol make decisions based on the payload
    [...]? Does your protocol prioritize certain content or services over
    others [...]?”
    
    Section 1 of the draft states that the “Verification Service Provider
    (VSP) is a certified party to verify that data is in compliance with the
    policies of a locality.” Therefore, the extension facilitates the
    prioritization of certain individuals based on how the VSP judges
    whether the registrants’ data is compliant. Registrants’ data which is
    not in “compliance” with the local regulations will not receive a
    verification code from the VSP, which gives the VSP the power to
    restrict individuals from registering/modifying a domain name, and
    limits their right to freedom of expression.
    
    # Censorship Resistance ([RFC8280], section 6.2.6)
    
    From [RFC8280]: “Can your protocol contribute to filtering in such a way
    that it could be implemented to censor data or services?  [...]”
    
    By design, the extension facilitates filtering: the VSP will receive the
    power to “verify” data on arbitrary grounds when determining whether
    registrant data is in “compliance” with local regulations. The draft
    also identifies examples of these scenarios: the VSP will check whether
    “the domain name is not prohibited”, or whether the “registrant is a
    valid individual, organization, or business in the locality.” On these
    grounds, the VSP can accept or reject attempts to register domain names.
    Thus, the extension explicitly provides filtering and censorship
    abilities to the VSP, which are inimical to the registrants’ freedom of
    expression.
    
    # Open Standards ([RFC8280], section 6.2.7)
    
    From [RFC8280], “Are you aware of any patents that would prevent your
    standard from being fully implemented [RFC6701] [RFC8179]?”
    
    There is an IPR declaration filed by Verisign Inc. for an older version
    of the draft mentioning the relevant [PATENT]. The declaration
    facilitates mostly open development, giving minimal assertion rights
    over the license for Verisign Inc.
    
    From [RFC8280]: “Is your protocol fully documented in such a way that it
    could be easily implemented, improved, built upon, and/or further
    developed?”
    
    Several key details that will form the complete mechanism for the
    verification code are not included in the draft (as it only describes
    the extension), but have been offered in the [PATENT]. This includes a
    description of the grace period within which “the requirement set of
    verification codes may be sent before the object becomes non-compliant”,
    and a clear depiction of the flow of the request detailed in Fig. 1 of
    the [PATENT].
    
    # Decentralisation ([RFC8280], section 6.2.14)
    
    From [RFC8280]: “What is the potential for discrimination against users
    of your protocol?”
    
    There is immense potential for discrimination against registrants whose
    data will be subject to “verification” by the VSP. The proposed
    extension provides the VSP powers to discriminate against registrants
    based on the information it receives, which may include names and
    addresses, and which may be further compared to other “local data
    sources” [VCEEPP] to indicate legal sex, religious affiliation, or
    ethnicity.
    
    From [RFC8280]: “Can your protocol be used to negatively implicate users
    (e.g., incrimination, accusation)?”
    
    There is potential for negative implication: a malicious registrant may
    submit a request for a domain name considered legally “prohibited” by
    the locality, accompanied with someone else's personal information.
    Registrant information is sent to the VSP, an entity that may be
    associated with law enforcement, which creates potential misuse for
    false incrimination/accusation.
    
    # Reliability ([RFC8280], section 6.2.14)
    
    No fallback mechanism is specified within the draft for when the VSP is
    offline or unavailable. In the event that the VSP is not available to
    process the sent object, the registrants’ requests will not be performed.
    
    Similarly, when considering how long the VSP takes to process a
    particular request, Section 0057 of the [PATENT] states that a “pending
    compliance status indicator may indicate that the object is not
    compliant by [...] a time, or grace period, in which the requirement set
    of verification codes may be sent before the object becomes
    non-compliant.” Therefore, if the VSP does not respond within the grace
    period, the object will be considered “non-compliant”. The proposed
    extension thus creates a problematic assumption of  “non-compliance”,
    which is at odds with the presumption of innocence.
    
    # Confidentiality ([RFC8280], section 6.2.15)
    
    From [RFC8280]: “What options exist for [...] implementers to choose to
    limit the information shared with each entity?”
    
    No such mechanisms are present which allow the registrants to limit the
    information that will be accessed by the VSP.
    
    # Integrity ([RFC8280], section 6.2.16)
    
    From [RFC8280]: “Does your protocol maintain, assure, and/or verify the
    accuracy of payload data? Does your protocol in any way allow the data
    to be (intentionally or unintentionally) altered?”
    
    The XML Signature maintains authenticity and integrity of the
    verification code. However, we are not sure whether the object can be
    altered by the VSP before appending the verification code to the shared
    object. If so, it creates the potential for false implication (also see
    section on Decentralisation) by the VSP.
    
    # Outcome transparency ([RFC8280], section 6.2.19)
    
    From [RFC8280]: “Are the effects [...] fully and easily comprehensible
    [...]?”
    
    As highlighted earlier in the review, many details (some out of the
    scope of the draft) may be opaque to registrants with the implementation
    of the proposed extension, including but not limited to, the exact data
    shared with the VSP.
    
    Additionally, as the [PATENT] notes, a “rejection of the verification
    request may be transmitted [...]” by the VSP. Therefore, while the
    proposed extension technologically facilitates a legal mechanism, there
    are no built-in measures that facilitate human rights related to legal
    transparency, remedy, or due process. For example, the VSP has no option
    to append an explanation for sending back a rejection.
    
    Conclusion
    ----------
    In summary, the proposed extension in its implementation allows the VSP
    to have enormous censorship and discriminatory power. The arbitrary and
    opaque mechanism to “verify” compliance with local regulations gives
    disproportionate powers to impede freedom of expression, right to
    privacy, freedom of association, and the right to non-discrimination.
    
    Some of the concerns highlighted in this review have already been
    pointed out in the past in and outside the IETF. [NLLZMSG][ART-19] We
    hope that the WG considers the potential adverse human rights impact
    that the proposed extension creates before recommending its
    standardisation. We understand that some of the concerns in the review
    do not stem purely from the proposed extension, but due to the
    unavoidable consequences of implementing the extension. The WG could
    consider adding the details of those to the draft as well, so as to make
    its impact on human rights clearer.
    
    References
    ----------
    [RFC8280] ten Oever, N., Cath, C., “Research into Human Rights Protocol
    Considerations”, RFC 8280, October 2017,
    <https://www.rfc-editor.org/info/rfc8280>.
    [VCEEPP] Gould, J., “Verification Code Extension for the Extensible
    Provisioning Protocol (EPP)”, draft-ietf-regext-verificationcode-03,
    April 2018,
    <https://datatracker.ietf.org/doc/draft-ietf-regext-verificationcode/>.
    [IP-DECL] Ward, M., “Verisign Inc.'s Statement about IPR related to
    draft-gould-eppext-verificationcode”, October 2015,
    <https://datatracker.ietf.org/ipr/2703/>
    [RFC5730] Hollenbeck, S., “Extensible Provisioning Protocol (EPP)”, RFC
    5730, August 2009,
    <https://www.rfc-editor.org/info/rfc5730>
    [RFC5731] Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain
    Name Mapping”, RFC 5731, August 2009,
    <https://www.rfc-editor.org/info/rfc5731>.
    [RFC5732] Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Host
    Mapping”, RFC 5732, August 2009,
    <https://www.rfc-editor.org/info/rfc5732>.
    [RFC5733] Hollenbeck, S., “Extensible Provisioning Protocol (EPP)
    Contact Mapping”, RFC 5733, August 2009,
    <https://www.rfc-editor.org/info/rfc5733>.
    [PATENT] Waldron, J., et al. “Domain Name Operation Verification Code
    Generation and/or Verification”, United States Patent Serial No.
    14/868,972, September 2015,
    <https://patents.google.com/patent/US20170093793A1/en?oq=United+States+Patent+Serial+No.+14%2f868%2c972>.
    [NLLZMSG] ten Oever, N., “Re: [regext] I-D Action:
    draft-ietf-regext-verificationcode-01.txt”, IETF Mail Archive: regext,
    April 2017, 
    <https://mailarchive.ietf.org/arch/msg/regext/EIK0E7ins874q8DmP37yg7AzAQI>.
    [ART-19] Article 19 Digital, “Corporate actors must not facilitate human
    rights violations through new Chinese rules”, Article 19, December 2016,
    <https://www.article19.org/resources/corporate-actors-must-not-facilitate-human-rights-violations-through-new-chinese-rules/>.
    
    Acknowledgements
    ----------------
    Thanks to Paul Kurian for research inputs. Thanks to Amelia
    Andersdotter, Mallory Knodel, Sunil Abraham and Swaraj Barooah for their
    feedback. Please note that acknowledgement here does not necessarily
    imply endorsement of the contents of the review.
    
    --
    Thank you.
    Gurshabad

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 3 Oct 2018 15:42:17 +0200

Hi James,

On Wed, Oct 03, 2018 at 01:14:10PM +0000, Gould, James wrote:
> Thanks for the review, Gurshabad. I'll consider your feedback in the context of technical issues with the draft.  The registration of domain names in some jurisdictions may be subject to various requirements that involve verification by a party other than the registry.  

Could you please be so kind to link to some of these legal requirements?

> The draft is intended for interoperability and is independent of the verification process. 

I am a bit confused with your reasoning that the verificationcode extension has is independent from the implementation of this extension, because the extension exists to enable implementation, right? Why else would it exist?

> The EPP extension takes no position on specific verification processes which are a "local matter" for the implementation. 

The EPP extension does enable it, so it does have a position on it. 

> For these reasons, I disagree with your assertion that implementation of the proposed extension will impact domain registrants' right to freedom of expression, right to freedom of assembly and association, and right to privacy. Rather the EPP extension, as the draft describes, is a proposal for a standard framework for the common industry practice of providing proof of verification to meet legal and/or security requirements within a given top-level domain.

Again, it would be great if you could give a bit more insight in, and perhaps some examples of, the practice of third-party verification for which this interoperation is needed.

Best,

Niels

> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

-- 

Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488  
                   643A 0ED8 3F3A 468A C8B3

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 3 Oct 2018 17:05:23 +0200 (CEST)

>     Il 3 ottobre 2018 alle 15.42 Niels ten Oever < [email-masked] mailto:[email-masked] > ha scritto:
> 
> 
This exchange strikes me because of the discussion that we have been having on content tagging on HRPC (Nalini, Barry and I are still working on it).

So my question is: is any protocol that supports additional points of content control at the national level favouring censorship, and thus inherently bad and contrary to human rights?

Or even, if you prefer: is all censorship inherently bad? More specifically, if the national government or policy verification authority used the proposed EPP extension to block the registration of lets-kill-all-the-jews.cctld or child-pornography-for-everyone.cctld, is it censoring the Internet, or is it just doing its job on behalf of its citizens?

And in that context, shouldn't the right to free expression of the user be balanced with the right to cultural and legal sovereignty of that country's citizens, which may end up establishing laws which legitimately make some content illegal in their country? (not to mention the rights of the people that may be harmed by the circulation of certain content)

All in all, and with no offense for the reviewer's laudable efforts, the assessment in the review that any local point of control is bad because it could be used to harm someone's rights is IMHO too simplistic: it could also be used to defend someone else's rights.

Regards,

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Ulrich Wisser <[email-masked]>
Date: Wed, 3 Oct 2018 17:39:59 +0200

Hi,

I completely agree with Gurshabad assessment. But as others already pointed
out, it is an intended consequence of the extension.
In the context of domain registration, privacy cannot be expected. So my
question is rather, does this extension make the situation worse?

As you were asking for examples. China and Denmark require preregistration
of registrants. Denmark does even require preregistration of hosts. Denmark
has plans to only allow registrations with a Danish electronic id.

In my assessment, a registrant cannot have any expectation of privacy.
And therefore the extension does not worsen the situation for the
registrant.

/Ulrich

Vittorio Bertola <[email-masked]> schrieb am Mi., 3.
Okt. 2018 um 17:05 Uhr:

> Il 3 ottobre 2018 alle 15.42 Niels ten Oever < [email-masked]>
> ha scritto:
>
>
> I am a bit confused with your reasoning that the verificationcode
> extension has is independent from the implementation of this extension,
> because the extension exists to enable implementation, right? Why else
> would it exist?
>
> The EPP extension takes no position on specific verification processes
> which are a "local matter" for the implementation.
>
> This exchange strikes me because of the discussion that we have been
> having on content tagging on HRPC (Nalini, Barry and I are still working on
> it).
>
> So my question is: is any protocol that supports additional points of
> content control at the national level favouring censorship, and thus
> inherently bad and contrary to human rights?
>
> Or even, if you prefer: is all censorship inherently bad? More
> specifically, if the national government or policy verification authority
> used the proposed EPP extension to block the registration of
> lets-kill-all-the-jews.cctld or child-pornography-for-everyone.cctld, is it
> censoring the Internet, or is it just doing its job on behalf of its
> citizens?
>
> And in that context, shouldn't the right to free expression of the user be
> balanced with the right to cultural and legal sovereignty of that country's
> citizens, which may end up establishing laws which legitimately make some
> content illegal in their country? (not to mention the rights of the people
> that may be harmed by the circulation of certain content)
>
> All in all, and with no offense for the reviewer's laudable efforts, the
> assessment in the review that any local point of control is bad because it
> could be used to harm someone's rights is IMHO too simplistic: it could
> also be used to defend someone else's rights.
>
> Regards,
>
> --
>
> [email-masked]
-- 
Ulrich Wisser
[email-masked]

---

From: Erwin Lansing <[email-masked]>
Date: Wed, 3 Oct 2018 18:01:00 +0200

> On 3 Oct 2018, at 17.39, Ulrich Wisser <[email-masked]> wrote:
> 
> Denmark has plans to only allow registrations with a Danish electronic id.

I’m sorry to barge in and distract from the real discussion here, but I cannot let such a blatant inaccuracy stand. There are no such plans, neither have there ever been such plans. I’d be happy to expand on how registrant identity verification works off-list, but let me suffice to say, that anyone in the world can register a .dk domain name, now and in the future.

Erwin

---

From: "John Levine" <[email-masked]>
Date: 3 Oct 2018 12:20:29 -0400

In article <20181003134215.GA23633@mir> you write:
>-=-=-=-=-=-
>> Thanks for the review, Gurshabad. I'll consider your feedback in the context of technical issues with the
>draft.  The registration of domain names in some jurisdictions may be subject to various requirements that
>involve verification by a party other than the registry.  
>

I take strong exception to this message.

Regext is a working group that works on standardizing interfaces among
registries and registrars.  Its members include people with expertise in
those topics, many of whom work for registries and registrars.

It is not our job to justify our work to occasional visitors.  If you
actually want to know how registries and registrars work, there are
plenty of resources.  I'd suggest starting with the contracts on
public file at ICANN.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 3 Oct 2018 18:55:47 +0200 (CEST)

> Il 3 ottobre 2018 alle 18.01 Erwin Lansing <[email-masked]> ha scritto: 
> 
> 
> > On 3 Oct 2018, at 17.39, Ulrich Wisser < [email-masked]> wrote:
> > 
> > 
> I’m sorry to barge in and distract from the real discussion here,
> but I cannot let such a blatant inaccuracy stand. There are no 
> such plans, neither have there ever been such plans. I’d be happy 
> to expand on how registrant identity verification works off-list,
> but let me suffice to say, that anyone in the world can register 
> a .dk domain name, now and in the future.

As far as I know, Danish .dk registrants have to identify themselves with a national digital ID, but there are alternative procedures for foreign registrants.
 
For the HRPC folks, you may want to have a look here:
 
https://www.dk-hostmaster.dk/sites/default/files/2018-06/DIFOs%20kriminalitetsbekaempelse_EN.pdf
 
to understand why this kind of "registrant vetting" has been introduced. It's not about censorship :-)
 
Regards, 
--

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 4 Oct 2018 09:28:37 +0200

> plenty of resources.  I'd suggest starting with the contracts on
I have worked extensively in ICANN and as you can see from the archives
I am not a stranger to this WG. Also I think IETF generally does
appreciate participation, reviews and mailinglist participation, so I
don't think it is appropriate to tell me whether I should or should not
be commenting here.

James is citing that there are a many legal request for external
verification of identity by nation states. I have done research in this
area and was not able to verify this claim, so it would be great if he
could point me to that. All examples I could find were registries that
do verification in-house, and not use a third party providers for this.

Best,

Niels

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 4 Oct 2018 12:26:25 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Niels ten Oever
> Sent: Wednesday, October 03, 2018 9:42 AM
> To: Gould, James <jgould=[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; gurshabad@cis-
> india.org
> Subject: [EXTERNAL] Re: [regext] Human Rights Review of draft-ietf-regext-
> verificationcode
>
> Hi James,
>
> > Thanks for the review, Gurshabad. I'll consider your feedback in the
> context of technical issues with the draft.  The registration of domain
> names in some jurisdictions may be subject to various requirements that

There are several examples of registry operators that require verification as part of their domain registration process. Here are a few ccTLD examples:

https://www.denic.de/en/faqs/faqs-for-domain-applicants/#faq-19

https://www.nic.fr/en/resources/faq/general-faq/
(Look for the "I am a private individual; am I entitled to file a domain name under the .fr or .re TLD?" and "I represent a French or foreign company / association / national or international institution; what are my rights with regard to filing a domain name under the TLDs operated by AFNIC ?" questions under "Choosing a domain name".)

https://www.about.us/policies/ustld-nexus-requirements

Any one of these registries could use the verification code approach if it were available.

In addition, Section 3.7.2 of the 2013 ICANN Registrar Accreditation Agreement (RAA) says, "Registrar shall abide by applicable laws and governmental regulations".

Scott

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 4 Oct 2018 14:35:32 +0200

Hi Scott,

> Any one of these registries could use the verification code approach if it were available.

Thanks for your reply. I interviewed the people from Denic and Nic.fr
and they explicitly told me they would not use external verification,
but rather do this is in house. So I am not sure how they would use this
extension.

> In addition, Section 3.7.2 of the 2013 ICANN Registrar Accreditation Agreement (RAA) says, "Registrar shall abide by applicable laws and governmental regulations".

I have reviewed several legal framework but did not find laws or
regulation that made this obligatory. It would be great if you could
link to national laws or regulations that would demand a third party
identity verification.

Best,

Niels

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 4 Oct 2018 18:34:42 +0000

> From: Niels ten Oever <[email-masked]>
> Sent: Thursday, October 04, 2018 8:36 AM
> To: Hollenbeck, Scott <[email-masked]>;
> 'jgould=[email-masked]'
> <jgould=[email-masked]>
> Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>;
> [email-masked]' <[email-masked]>; [email-masked]'
> <[email-masked]>
> >> Subject: [EXTERNAL] Re: [regext] Human Rights Review of
> >> draft-ietf-regext- verificationcode
> >>
> >> Hi James,
> >>
> >> context of technical issues with the draft.  The registration of
> >> domain names in some jurisdictions may be subject to various
> >> requirements that involve verification by a party other than the
> registry.
> >>
> > There are several examples of registry operators that require
> verification as part of their domain registration process. Here are a few
> ccTLD examples:
> >
> > (Look for the "I am a private individual; am I entitled to file a
> > domain name under the .fr or .re TLD?" and "I represent a French or
> > foreign company / association / national or international institution;
> > what are my rights with regard to filing a domain name under the TLDs
> > operated by AFNIC ?" questions under "Choosing a domain name".)
> >
> Thanks for your reply. I interviewed the people from Denic and Nic.fr and
> they explicitly told me they would not use external verification, but
> rather do this is in house. So I am not sure how they would use this
> extension.

They are examples of requirements for verification. With the use of
verification codes as described in the draft, clients (registrars or
registrants) have a choice of verification providers (VSPs) to perform
verification in a way that protects the privacy of the data. Choosing between
in-house verification or external verification is an architectural decision,
and this helps make the latter option possible.

> > In addition, Section 3.7.2 of the 2013 ICANN Registrar Accreditation
> Agreement (RAA) says, "Registrar shall abide by applicable laws and
> governmental regulations".
> >
>
> regulation that made this obligatory. It would be great if you could link
> to national laws or regulations that would demand a third party identity
> verification.

Here's one example of a regulation that could be met using the approach
described in the draft:

https://www.ecfr.gov/cgi-bin/text-idx?SID=d611d7d4bd8f3155d3262ea4857c011e&mc=true&node=pt41.3.102_6173&rgn=div5

The draft does not use terms like "obligatory" or "demand". As it says in the
Introduction, "A locality MAY ...".

Scott

---

From: [email-masked]
Date: Thu, 4 Oct 2018 21:47:07 -0400

Re: tagging discussion

I don't see content tagging as only negative. I could imagine such a
facility being used positively such as tagging some content as "child
friendly".

Which is why my interest in the topic is more in mechanism than
policy.

One would still have to trust the source of the tag, reputational
issues, which remain a largely unsolved problem on the net.

For example attempts at attaching reputation to DKIM (et al) which I
know was a hope for DKIM.

Merely knowing it came from who it claims to have come from is really
only half the battle, it might be bona-fide mail from an evil party.

It's a potentially huge topic, perhaps it needs a tag!

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 5 Oct 2018 09:39:01 +0200

Hi Scott,

sorry to say that, but for DENIC, this is not correct. Of course, the registrar 
is obliged to provide a valid registrant address, but there is no mandatory, 
automated pre- nor post-validation of it in the DENIC registration process. Only 
in case of a complaint of a third party (for an obvious "Mickey Mouse" or 
incomplete address), DENIC requests the registrar to provide a correct address.

The link you provided refers to the case that the domain is involved in a 
lawsuit. It is a requirement that has been changed in the context of the EU GDPR 
and has actually been relaxed compared to the previous requirements.

Regards,

Klaus

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 5 Oct 2018 10:20:08 +0200

> Introduction, "A locality MAY ...".

If there is only one instance in which this MAY be useful, perhaps there
is no need for standardization of this extension?

Best,

Niels

---

From: Peter Koch <[email-masked]>
Date: Fri, 5 Oct 2018 12:48:57 +0200

Scott, all,

> https://www.denic.de/en/faqs/faqs-for-domain-applicants/#faq-19

while in fact we do have some requirements - as laid out in this FAQ snippet,
none of those involve third party validation, let alone at registration time.

[...]

> Any one of these registries could use the verification code approach if it were available.

Technically speaking, we do not use EPP, so we cannot serve as an example.
Conceptually, since no ex-ante validation is involved, this extension would
not be of interest for us.

> In addition, Section 3.7.2 of the 2013 ICANN Registrar Accreditation Agreement (RAA) says, "Registrar shall abide by applicable laws and governmental regulations".

I'm not sure how this would help make the case. It doesn't need ICANN nor
the RAA to bind registrars to applicable law and regulation. In the opposite
direction, I don't think that each and every "local" requirement
(automatically) has to result in a standardized extension.

I do think, though, that this WG - and the IESG - might want to be extra
careful regarding the boundaries between protocol and policy.

-Peter

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 5 Oct 2018 11:14:55 +0000

> Sent: Friday, October 05, 2018 4:20 AM

[snip]

> > Here's one example of a regulation that could be met using the
> > approach described in the draft:
> >
> > https://www.ecfr.gov/cgi-bin/text-idx?SID=d611d7d4bd8f3155d3262ea4857c
> > 011e&mc=true&node=pt41.3.102_6173&rgn=div5
> >
> > The draft does not use terms like "obligatory" or "demand". As it says
> > in the Introduction, "A locality MAY ...".
> >
>

If there is at least one example, there is a demonstration of existence of utility.

Scott

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 Oct 2018 13:55:27 +0200

> is no need for standardization of this extension?

Not the way we do business.  We ask this question on the front end of
the process, not the back end.  That is a simple matter of fairness. 
Also, the form of rhetoric here is a bit disturbing.  When someone comes
up with one example, it should not be assumed that there is in fact but
one use (conversely one need not assume that there is more than one use,
but as per above it is irrelevant).

Eliot

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 5 Oct 2018 11:56:32 +0000

> From: Klaus Malorny <[email-masked]>
> Sent: Friday, October 05, 2018 3:39 AM
> [email-masked]' <[email-masked]>; Gould, James
> <[email-masked]>
> sorry to say that, but for DENIC, this is not correct. Of course, the
> registrar is obliged to provide a valid registrant address, but there is
> no mandatory, automated pre- nor post-validation of it in the DENIC
> registration process. Only in case of a complaint of a third party (for an
> obvious "Mickey Mouse" or incomplete address), DENIC requests the
> registrar to provide a correct address.
>
> lawsuit. It is a requirement that has been changed in the context of the
> EU GDPR and has actually been relaxed compared to the previous
> requirements.

Thanks for the correction. The point I was trying to make is that there are multiple registry operators who require some form of verification and/or validation as part of their domain registration process.

Scott

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 5 Oct 2018 14:05:35 +0200

On 10/05/2018 01:55 PM, Eliot Lear wrote:
> the process, not the back end.  

Where is this question baked in the process? And where is it said it
cannot be asked at a later stage? I did not find this in RFC 2418. All
pointers are welcome of course.

> That is a simple matter of fairness. 
> Also, the form of rhetoric here is a bit disturbing.  

Please elaborate? The 'MAY' was brought up by Scott in his previous email.

> When someone comes

Also see the previous emails, there has been research into different
registrars and registries and their practices, that is what we are
discussing about. No assumptions are being made.

Niels

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 5 Oct 2018 14:08:38 +0200

> If there is at least one example, there is a demonstration of existence of utility.

We might disagree here. If there is one place in which this extension
might be useful, I am not sure whether standardization is appropriate
because there is only one (potential) implementation. That leads me to
the question: has this actually been implemented in the case of .gov?

Best,

Niels

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 5 Oct 2018 12:24:59 +0000

> Sent: Friday, October 05, 2018 8:09 AM
> >> Cc: [email-masked]' <[email-masked]>; [email-masked]'
> >> <[email-masked]>; [email-masked]' <[email-masked]>; 'gurshabad@cis-
> india.org'
> >>> The draft does not use terms like "obligatory" or "demand". As it
> >>> says in the Introduction, "A locality MAY ...".
> >>>
> >>
> >> If there is only one instance in which this MAY be useful, perhaps
> >> there is no need for standardization of this extension?
> >
> because there is only one (potential) implementation. That leads me to the
> question: has this actually been implemented in the case of .gov?

It has not. This extension can, however, be used by any EPP-using entities that have verification requirements - and there are more than one of those.

Scott

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Oct 2018 08:48:29 -0400

> the question: has this actually been implemented in the case of .gov?

On the other hand, if people want to standardize some mechanism for a
policy you find regrettable, I find it hard to believe that the right
answer is "prevent that standard" rather than "don't subject yourself
to that policy".  The latter is easily achieved by refusing to do
business with registries that implement a policy you don't like.  The
approach that seems to be being pursued here is to try to prevent
standardization of the mechanism because of a disagreement about the
policy.  I think that is generally bad for interoperability.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 5 Oct 2018 15:01:35 +0200

> policy.  I think that is generally bad for interoperability.

If this would be a standard in response to a demand, that would be fine.
But I am rather afraid this is a standard that will create policy and
practice. Namely the practice of 3rd party identity verification
providers. Since there is legislation that demand this afaik, I think we
should be hesitant to standardize such a thing because of the
potentially severe implications as pointed out by the review.

Best,

Niels

---

From: Thomas Corte <[email-masked]>
Date: Fri, 5 Oct 2018 15:17:15 +0200

Hello,

> potentially severe implications as pointed out by the review.

Not having a standard for this process will not prevent bad actors from
establishing it anyway (they'll simply use proprietary extensions).
However, it will force good actors requiring similar processes to also
implement their own solutions, which hurts interoperability and makes
life harder for everybody. In this respect, this is somewhat similar to
an argument brought forward by opponents of weapon control in the US: "If
weapons become illegal, only illegal people will have weapons".

Generally, technical standards are IMHO not the appropriate place for
fighting political or societal issues. This battle needs to be fought
elsewhere, i.e. in the voting booth or by people walking away from a bad
product.

Best regards,

Thomas

-- 
____________________________________________________________________
     |       |
     | knipp |            Knipp  Medien und Kommunikation GmbH
      -------                    Technologiepark
                                 Martin-Schmeißer-Weg 9
                                 44227 Dortmund
                                 Deutschland

     Dipl.-Informatiker          Tel:    +49 231 9703-0
     Thomas Corte                Fax:    +49 231 9703-200
     Stellvertretender Leiter    SIP:    [email-masked]
     Software-Entwicklung        E-Mail: [email-masked]

                                 Registereintrag:
                                 Amtsgericht Dortmund, HRB 13728

                                 Geschäftsführer:
                                 Dietmar Knipp, Elmar Knipp

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 5 Oct 2018 15:24:08 +0200

On 10/05/2018 03:17 PM, Thomas Corte wrote:
> life harder for everybody.

We could simply standardize good solutions and not standardize the bad
ones. Interoperability is not the only value at play here, right?

> In this respect, this is somewhat similar to

But what if people cannot walk away from a bad product and are forced to
use 3rd party verification? There is not always a choice, and we do have
a role here by saying 'we will do this' or 'we will not do this'.

We cannot simply wish political implications of our work away.

Best,

Niels

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Oct 2018 09:59:43 -0400

> We cannot simply wish political implications of our work away.

Right, but I don't believe the HRPC work has suggested that things
that have HR implications should _not be done_.  They should be noted,
and I'm all in favour of that.  What you are arguing, however, is in
line with the way the IETF ended up doing the BEHAVE WG: we wouldn't
agree to consider NAT when it was first being worked on, so everyone
did it their own way.  Then we had 30 million different ways to
achieve the same result, none of which worked with anything else, so
we had to come up with a bunch of well-defined work arounds to get
things to function together.  It's not obvious that is an improvement.

I think it would be quite good for the document to note that it has
the implications you are pointing to, which might be a reason for
people not to embrace it.  The downsides should be noted.  But to me,
if I have to weigh "undesirable political implications in an
interoperable way, which might draw attention and increase the
possibility of implementation" against "undesirable political
implications in proprietary ways", I'm going to pick the former every
time.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 5 Oct 2018 16:16:04 +0200

> things to function together.  It's not obvious that is an improvement.

The difference between NAT and 3rd party verification is that there was
a significant demand for the former, and not for the latter.

> implications in proprietary ways", I'm going to pick the former every

Does this mean that the only possible impact of a human rights review
could be recognition in an RFC ?

You seem to be arguing a technological deterministic standpoint here
along the lines of 'everything that is technically possible will happen
anyway, so its better to do it in an interoperable way'. Aside from it
being quite nihilist, I also think this is simply not true. By
standardizing certain solutions, and not standardizing others, we change
the development and uptake of technologies, especially if there is not a
large demand or an established practice.

Best,

Niels

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 Oct 2018 16:18:20 +0200

On 05.10.18 14:05, Niels ten Oever wrote:
> Where is this question baked in the process

As a matter of practice (e.g., running code), it is asked at the time of
working group adoption, and it *sh**ould* be a gating factor for
technical specifications.  That is- no working group is likely to adopt
work they think is not going to get implemented or deployed, as that is
a waste of the IETF's resources. And in general it comes along with
questions like, “Do people think this is a good idea?  Has anyone read
the draft?  Are people willing to review the work?  etc.”

> Please elaborate? The 'MAY' was brought up by Scott in his previous email.

He gave *an* example.  You implied then that it was the only use case. 
That's not reasonable.  And there's reason to assume that this is not
the case, (a) because of the above and (b)  because someone is being
paid to do work in this space in this direction, and that person works
at a domain registration company.

Eliot

**

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 Oct 2018 16:21:26 +0200

On 05.10.18 14:08, Niels ten Oever wrote:

> because there is only one (potential) implementation. 

Again, not required (albeit desirable).  RFC 2026 states this:

>    Usually, neither implementation nor operational experience is
>    required for the designation of a specification as a Proposed
>    Standard.  However, such experience is highly desirable, and will
>    usually represent a strong argument in favor of a Proposed Standard
>    designation.

Eliot

---

From: Peter Koch <[email-masked]>
Date: Fri, 5 Oct 2018 18:10:22 +0200

> line with the way the IETF ended up doing the BEHAVE WG: we wouldn't

this case is probably more related to the discussion around RFC 2804.

> people not to embrace it.  The downsides should be noted.  But to me,

There is of course the danger of misinterpretation, even though
the draft at hand is not necessarily the best example: policy
might be encouraged by the presence of a technical standard.
Just don't run a laundry.

   A locality MAY require the client to have data verified in accordance
   with local regulations or laws utilizing data sources not available
   to the server.

                                         The data verified by the VSP
   MUST be stored by the VSP along with the generated verification code
   to address any compliance issues.  The signer certificate and the
   digital signature of the verification code MUST be verified by the
   server.

The MAY in the first quote might be accidental, but the first MUST in
the second definitely is policy rather than protocol.

-Peter

---

From: "John Levine" <[email-masked]>
Date: 5 Oct 2018 12:11:26 -0400

>> things to function together.  It's not obvious that is an improvement.

It's even worse than that.  Some of the workarounds like VoIP ALG just
don't work, but others like UPnP invented outside the IETF are
security disasters.  If we'd been willing to engage with the problem,
NATs would still be ugly but we could at least have kept it from being
trivially easy to run botnets through a NAT.

>a significant demand for the former, and not for the latter.

Repeating this assertion really isn't helpful.

Anyone familiar with ICANN's gTLDs would be aware that there are a
bunch of TLDs that limit registrations to members of specific
communitities, such as .AERO, .TRAVEL, .BANK, .COOP, and .NGO/.ORG.  I
can tell you from experience that no two use the same method to
validate registrants and pass the validation info to the registrar,
and it's a bunch of painful and inconsistent kludges.  This offers at
least the possibility of a consistent way to do it so, e.g., your
national co-op association can assert that you're really a co-op.  I
realize they don't do it this way now, but they can't use a feature
that doesn't exist yet.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Oct 2018 12:29:02 -0400

> a significant demand for the former, and not for the latter.

It seems to me that the WG is a place where a bunch of people who work
on registries and registrars get together to talk about things that
are useful to them, and you are asserting the non-existence of demand
by the non-use of this not yet existing standard.  As John points out,
there are other possible interpretations open.

> could be recognition in an RFC ?

No, but when there are reasonable trade offs among different rights it
would be quite inappropriate to attempt to suppress standardization
because the review comes down entirely in favour of certain rights.
This is _especially_ true in the current case, since the human rights
review is not actually part of IETF process but is instead an
experiment to see how useful they are.  I think the jury is out on
that, so far, and efforts like this to suppress standarization efforts
on the basis of a preference for certain rights is not that
encouraging for the process.  

This is, after all, a registry protocol.  For the land registry in
Ontario, I need not only to show up, but actually to show
government-issued ID.  This is because of fraud that happened in land
titles in Ontario some years ago.

I trust there is little disagreement with the proposition that fraud
involving some domain names has happened.  Some registries might
attempt to solve that through stronger identification of owner
requirements.  Whether it would work, I don't know, but that's
supposed to be what a competitive market in domain names (and the
resulting reputational effects) is supposed to get us.
 
> anyway, so its better to do it in an interoperable way'.

I am not.  But we know that there are _current_ things that do some
kind of verification in _non_-interoperable ways, and so I fail to see
the value in putting fingers in our ears and shouting, "I can't hear
you," in response.  The IETF is not a human rights advocacy
organization, and I do not think it should become one.

> By standardizing certain solutions, and not standardizing others, we
> change the development and uptake of technologies, especially if
> there is not a large demand or an established practice.

If there is a demand for a thing that is satisfied by multiple,
different established practices, that _too_ is an outcome -- one I
think is less desirable for the interoperation of the global Internet.

Best regards,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Adam Roach <[email-masked]>
Date: Fri, 5 Oct 2018 12:30:51 -0500

[as an individual]

On 10/5/18 8:17 AM, Thomas Corte wrote:
> fighting political or societal issues.

At the IETF 98 plenary in Chicago, David Clark said something on the 
topic of human rights that's really resonated with me ever since: "You 
are designing the playing field, not the outcome of the game. But if you 
are clever enough, you can tilt the playing field."

I think that that we're well past the point where we have the luxury of 
pretending that technology has no ethical implications. I believe that 
the IETF does, in the general case, have an obligation to consider the 
human rights implications of its work. In the specific case of 
-verificationcode, I think Andrew Sullivan's arguments are persuasive, 
and that this obligation is best served by publishing this mechanism 
with proper framing and considerations. There's a parallel to be drawn 
between what he advocates and the conclusions drawn by RFC 2804:

    - On the other hand, the IETF believes that mechanisms designed to
      facilitate or enable wiretapping, or methods of using other
      facilities for such purposes, should be openly described, so as to
      ensure the maximum review of the mechanisms and ensure that they
      adhere as closely as possible to their design constraints. The IETF
      believes that the publication of such mechanisms, and the
      publication of known weaknesses in such mechanisms, is a Good
      Thing.

I strongly support enumerating the concerns raised in the HRPC review as 
part of this document. I'm also certain that those entities that are 
causing the most worry in this context [1] will implement their policies 
with or without a standard. By performing this work in the IETF, we at 
least have a chance to ensure that the mechanism is narrowly scoped to 
its intended purpose, and that it comes with appropriate caveats about 
the implications of deploying it.

/a

____
[1] Although it hasn't been brought up recently, Nils pointed to 
<https://www.article19.org/resources/corporate-actors-must-not-facilitate-human-rights-violations-through-new-chinese-rules/> 
in relation to this document a couple of years ago.

---

From: "Gould, James" <[email-masked]>
Date: Fri, 5 Oct 2018 17:52:20 +0000

Peter,

I agree that the sentence "The data verified by the VSP MUST be stored by the VSP along with the generated verification code to address any compliance issues." should be changed.  The proposal that I posted (https://mailarchive.ietf.org/arch/msg/regext/UWdcY2q-9JkSlASV0UJcUGPJJyQ) to the list is to revise the sentence to "The VSP MUST store the proof of verification and the generated verification code; and MAY store the verified data." and to add text to the Security Considerations section associated with the storage of the verification data.  A sentence such as "The Verification Service Provider (VSP) MUST store the verification data in compliance with the applicable privacy laws and regulations.".
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 10/5/18, 12:10 PM, "regext on behalf of Peter Koch" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    
    -Peter

---

From: Niels ten Oever <[email-masked]>
Date: Sat, 6 Oct 2018 00:15:38 +0200

On 10/05/2018 04:18 PM, Eliot Lear wrote:
<<snip>>
> He gave *an* example. 

There were several examples mentioned earlier, all of which turned out
not be planning to implement 3rd party verification.

> You implied then that it was the only use case. 

No other has been mentioned to date. So am curious whether there rly is
a big appetite from others for interoperating with this.

I am a bit surprised that asking for use cases is a contentious question
to some.

---

From: Gurshabad Grover <[email-masked]>
Date: Mon, 8 Oct 2018 23:26:45 +0530

> If there is at least one example, there is a demonstration of existence of utility.

Thank you, Niels, Scott, Eliot, Adam, Andrew and Peter for bringing this
up and discussing this issue.

In this particular case, in addition to RFC 2026, we should also look at
RFC 3735, 'Guidelines for Extending the Extensible Provisioning Protocol
(EPP)', authored by Scott. It briefly discusses some criteria for which
track to choose for different EPP extensions. Most pertinently, it notes
that:

"the intended maturity level (informational, proposed standard, etc.)
largely depends on what is being extended and the amount of general
interest in the extension." [1]

Additionally, it says:

“Extensions need not be published as Internet-Draft or RFC documents if
they are intended for operation in a closed environment or are otherwise
intended for a limited audience. In such cases extensions MAY be
documented in a file and structural format that is appropriate for the
intended audience.”[1]

So, demonstration of utility and interest is an important aspect here
(first for whether it should be an I-D/RFC; and if yes, with what
status: informational/standard).

Thank you.
Gurshabad

[1] https://tools.ietf.org/html/rfc3735#section-2.1