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

[Niels ten Oever]

On 10/05/2018 04:18 PM, Eliot Lear wrote:
<>
> 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.

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

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Gould, James]

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
jgo...@verisign.com

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

Verisign.com  

On 10/5/18, 12:10 PM, "regext on behalf of Peter Koch" 
 wrote:

On Fri, Oct 05, 2018 at 09:59:43AM -0400, Andrew Sullivan wrote:

> 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

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

> 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,

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Adam Roach]

[as an individual]

On 10/5/18 8:17 AM, Thomas Corte wrote:

Generally, technical standards are IMHO not the appropriate place for
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 
 
in relation to this document a couple of years ago.


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Andrew Sullivan]

On Fri, Oct 05, 2018 at 04:16:04PM +0200, Niels ten Oever wrote:
> The difference between NAT and 3rd party verification is that there was
> 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.

> Does this mean that the only possible impact of a human rights review
> 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.
 
> 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'.

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
a...@anvilwalrusden.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [hrpc] bad design through Human Rights Review of draft-ietf-regext-verificationcode

[John Levine]

In article <9ab8441b-8f37-8edb-17ae-0a102447b...@digitaldissidents.org> you 
write:
>> 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.

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.

>The difference between NAT and 3rd party verification is that there was
>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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Peter Koch]

On Fri, Oct 05, 2018 at 09:59:43AM -0400, Andrew Sullivan wrote:

> 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

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

> 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,

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Registration Protocols Extensions (regext) WG Virtual Meeting: 2018-10-16

[IESG Secretary]

The Registration Protocols Extensions (regext) Working Group will hold
a virtual interim meeting on 2018-10-16 from 12:00 to 13:00 America/New_York.

Agenda:
1. Validate draft (comments, concerns, implementations) – New version to be 
posted this week.
2. Registry Mapping
a. Continue the lively discussion that were started in London and continued 
in Montreal
b. Policy Extension Review: how a server implements an extension, the 
SHOULD(s), MAY(s), etc.


Information about remote participation:
https://godaddy.zoom.us/j/639566706

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Eliot Lear]

On 05.10.18 14:08, Niels ten Oever wrote:

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

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Eliot Lear]

On 05.10.18 14:05, Niels ten Oever wrote:
> On 10/05/2018 01:55 PM, Eliot Lear wrote:
>> I take no position on the HR issues of this draft.  However:
>>
>>
>>> If there is only one instance in which this MAY be useful, perhaps there
>>> 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.  
> 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

**
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Niels ten Oever]

On 10/05/2018 03:59 PM, Andrew Sullivan wrote:
> On Fri, Oct 05, 2018 at 03:24:08PM +0200, Niels ten Oever wrote:
>> 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.
> 

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

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

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

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

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Andrew Sullivan]

On Fri, Oct 05, 2018 at 03:24:08PM +0200, Niels ten Oever wrote:
> 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
a...@anvilwalrusden.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Niels ten Oever]

On 10/05/2018 03:17 PM, Thomas Corte wrote:
> Hello,
> 
> On 10/5/18 15:01, Niels ten Oever wrote:
> 
>> 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.
> 
> 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.

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

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


> Best regards,
> 
> Thomas
> 

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

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Thomas Corte]

Hello,

On 10/5/18 15:01, Niels ten Oever wrote:

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

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 CorteFax:+49 231 9703-200
 Stellvertretender LeiterSIP:thomas.co...@knipp.de
 Software-EntwicklungE-Mail: thomas.co...@knipp.de

 Registereintrag:
 Amtsgericht Dortmund, HRB 13728

 Geschäftsführer:
 Dietmar Knipp, Elmar Knipp

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Niels ten Oever]

On 10/05/2018 02:48 PM, Andrew Sullivan wrote:
> On Fri, Oct 05, 2018 at 02:08:38PM +0200, Niels ten Oever wrote:
> 
>> 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?
> 
> 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.
> 

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

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

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Andrew Sullivan]

On Fri, Oct 05, 2018 at 02:08:38PM +0200, Niels ten Oever wrote:

> 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?

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
a...@anvilwalrusden.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Hollenbeck, Scott]

> -Original Message-
> From: Niels ten Oever 
> Sent: Friday, October 05, 2018 8:09 AM
> To: Hollenbeck, Scott ;
> 'jgould=40verisign@dmarc.ietf.org'
> 
> Cc: 'hr...@irtf.org' ; 'h...@irtf.org' ;
> 'regext@ietf.org' ; 'gursha...@cis-india.org'
> 
> Subject: [EXTERNAL] Re: [regext] Human Rights Review of draft-ietf-regext-
> verificationcode
>
> On 10/05/2018 01:14 PM, Hollenbeck, Scott wrote:
> >> -Original Message-
> >> From: Niels ten Oever 
> >> Sent: Friday, October 05, 2018 4:20 AM
> >> To: Hollenbeck, Scott ;
> >> 'jgould=40verisign@dmarc.ietf.org'
> >> 
> >> Cc: 'hr...@irtf.org' ; 'h...@irtf.org'
> >> ; 'regext@ietf.org' ; 'gurshabad@cis-
> india.org'
> >> 
> >> Subject: [EXTERNAL] Re: [regext] Human Rights Review of
> >> draft-ietf-regext- verificationcode
> >>
> >> On 10/04/2018 08:34 PM, Hollenbeck, Scott wrote:
> >
> > [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=d611d7d4bd8f3155d3262ea485
> >>> 7c
> >>> 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 only one instance in which this MAY be useful, perhaps
> >> there is no need for standardization of this extension?
> >
> > 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?

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
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] REGEXT Interim Meeting (2018OCT16)

[James Galvin]

I will attend this meeting.  Thanks Roger.

Jim



On 1 Oct 2018, at 12:57, Roger D Carney wrote:


Good Morning,



I would like to invite everyone to an interim meeting Tuesday October 
16th at 16:00 UTC for 60 minutes.




We plan to focus the discussion around two topics:



Agenda

  1.  Validate draft (comments, concerns, implementations) - New 
version to be posted this week.

  2.  Registry Mapping
 *   Continue the lively discussion that were started in London 
and continued in Montreal
 *   Policy Extension Review: how a server implements an 
extension, the SHOULD(s), MAY(s), etc.




We will once again use Zoom as a conferencing tool, please use this 
link to connect to the meeting.




Please reply to the list or directly to myself if you plan on 
attending this meeting.






Thanks

Roger




___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Niels ten Oever]

On 10/05/2018 01:14 PM, Hollenbeck, Scott wrote:
>> -Original Message-
>> From: Niels ten Oever 
>> Sent: Friday, October 05, 2018 4:20 AM
>> To: Hollenbeck, Scott ;
>> 'jgould=40verisign@dmarc.ietf.org'
>> 
>> Cc: 'hr...@irtf.org' ; 'h...@irtf.org' ;
>> 'regext@ietf.org' ; 'gursha...@cis-india.org'
>> 
>> Subject: [EXTERNAL] Re: [regext] Human Rights Review of draft-ietf-regext-
>> verificationcode
>>
>> On 10/04/2018 08:34 PM, Hollenbeck, Scott wrote:
> 
> [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 only one instance in which this MAY be useful, perhaps there
>> is no need for standardization of this extension?
> 
> 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

> Scott
> 

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

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Niels ten Oever]

On 10/05/2018 01:55 PM, Eliot Lear wrote:
> I take no position on the HR issues of this draft.  However:
> 
> 
>> If there is only one instance in which this MAY be useful, perhaps there
>> 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.  

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

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

> Eliot
> 

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

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Hollenbeck, Scott]

> -Original Message-
> From: Klaus Malorny 
> Sent: Friday, October 05, 2018 3:39 AM
> To: Hollenbeck, Scott ;
> 'li...@digitaldissidents.org' ; Gould, James
> 
> Cc: 'hr...@irtf.org' ; 'h...@irtf.org' ;
> 'regext@ietf.org' ; 'gursha...@cis-india.org'
> 
> Subject: [EXTERNAL] Re: [regext] Human Rights Review of draft-ietf-regext-
> verificationcode
>
> On 04.10.18 14:26, Hollenbeck, Scott wrote:
> >> -Original Message-
> >> From: regext  On Behalf Of Niels ten Oever
> >> Sent: Wednesday, October 03, 2018 9:42 AM
> >> To: Gould, James 
> >> Cc: hr...@irtf.org; h...@irtf.org; regext@ietf.org; gurshabad@cis-
> >> india.org
> >> Subject: [EXTERNAL] Re: [regext] Human Rights Review of
> >> draft-ietf-regext- verificationcode
> >>
> >> Hi James,
> >>
> >> On Wed, Oct 03, 2018 at 01:14:10PM +, 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?
> >
> > 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
> >
>
> 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.

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
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Eliot Lear]

I take no position on the HR issues of this draft.  However:


> If there is only one instance in which this MAY be useful, perhaps there
> 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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Hollenbeck, Scott]

> -Original Message-
> From: Niels ten Oever 
> Sent: Friday, October 05, 2018 4:20 AM
> To: Hollenbeck, Scott ;
> 'jgould=40verisign@dmarc.ietf.org'
> 
> Cc: 'hr...@irtf.org' ; 'h...@irtf.org' ;
> 'regext@ietf.org' ; 'gursha...@cis-india.org'
> 
> Subject: [EXTERNAL] Re: [regext] Human Rights Review of draft-ietf-regext-
> verificationcode
>
> On 10/04/2018 08:34 PM, Hollenbeck, Scott wrote:

[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 only one instance in which this MAY be useful, perhaps there
> is no need for standardization of this extension?

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

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Peter Koch]

Scott, all,

On Thu, Oct 04, 2018 at 12:26:25PM +, Hollenbeck, Scott wrote:

> > 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?
> 
> 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

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Niels ten Oever]

On 10/04/2018 08:34 PM, Hollenbeck, Scott wrote:
>> -Original Message-
>> From: Niels ten Oever 
>> Sent: Thursday, October 04, 2018 8:36 AM
>> To: Hollenbeck, Scott ;
>> 'jgould=40verisign@dmarc.ietf.org'
>> 
>> Cc: 'hr...@irtf.org' ; 'h...@irtf.org' ;
>> 'regext@ietf.org' ; 'gursha...@cis-india.org'
>> 
>> Subject: [EXTERNAL] Re: [regext] Human Rights Review of draft-ietf-regext-
>> verificationcode
>>
>> Hi Scott,
>>
>> On 10/04/2018 02:26 PM, Hollenbeck, Scott wrote:
 -Original Message-
 From: regext  On Behalf Of Niels ten Oever
 Sent: Wednesday, October 03, 2018 9:42 AM
 To: Gould, James 
 Cc: hr...@irtf.org; h...@irtf.org; regext@ietf.org; gurshabad@cis-
 india.org
 Subject: [EXTERNAL] Re: [regext] Human Rights Review of
 draft-ietf-regext- verificationcode

 Hi James,

 On Wed, Oct 03, 2018 at 01:14:10PM +, 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?
>>>
>>> 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.
>>>
>>
>> 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".
>>>
>>
>> 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.
> 
> 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 ...".
> 

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

Best,

Niels



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

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Klaus Malorny]

On 04.10.18 14:26, Hollenbeck, Scott wrote:

-Original Message-
From: regext  On Behalf Of Niels ten Oever
Sent: Wednesday, October 03, 2018 9:42 AM
To: Gould, James 
Cc: hr...@irtf.org; h...@irtf.org; regext@ietf.org; gurshabad@cis-
india.org
Subject: [EXTERNAL] Re: [regext] Human Rights Review of draft-ietf-regext-
verificationcode

Hi James,

On Wed, Oct 03, 2018 at 01:14:10PM +, 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?


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



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


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext