Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

[Thomas Corte]

Hello,

On 12/26/18 15:32, Gould, James wrote:

> Do others in the working group believe that either the verification process 
> of the VSP is in scope based on the current wording of the draft or that a 
> consideration section can cover something that is outside the defined scope 
> of the draft?

No, I agree that it's way out of scope. Gurshabad's proposed additions
are in my point of view an attempt to address *judicial* issues (ensuring
people's right to privacy, non-discrimination etc.) by adding wording to
a *technical* specification. Lawyers and politicians exist to deal with
such issues; engineers should not be required to waste their time with them.

Plus, even *if* such wording should end up in the draft, it would be
utterly pointless. Looking at the various implementations of EPP and EPP
extensions which are out in the open (especially for country code TLDs),
it's obvious that even the most basic technical requirements (such as
strict XML schema compliance) and MUST regulations are often ignored or
violated by many operators. I'd therefore be surprised if anyone who's
determined to "abuse" the extension for human rights violations would
care much about the proposed additions anyway.

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] DOODLE: select your documents

[Hollenbeck, Scott]

> -Original Message-
> From: regext  On Behalf Of James Galvin
> Sent: Friday, December 21, 2018 11:13 AM
> To: Registration Protocols Extensions 
> Subject: [EXTERNAL] [regext] DOODLE: select your documents
>
> Please take the time to select the documents you support for advancement
> in this working group.
>
> https://doodle.com/poll/6nyguby3yr8dx9cp
>
> Please select from 1-5 documents.

Jim, how do you propose to address submissions that contain more than five 
"green checkmark" selections?

Scott

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

Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

[Niels ten Oever]

Hi all,

I strongly support the inclusion of text in the draft. 

I think the differentiations that are being made here between 'technical' and 
'policy', and 'technical' and 'judicial' here are merely rhetorical. No clear 
definition of the either terms and/or the difference have been offered thus 
far. Thus the argument to not include the text seems unfounded.

Next to that, I have not been able to locate the limitation for the use of MUST 
and MAY, as defined by John Levine, in RFC2119.

Best,

Niels

  

On 1/2/19 12:07 PM, Thomas Corte wrote:
> Hello,
> 
> On 12/26/18 15:32, Gould, James wrote:
> 
>> Do others in the working group believe that either the verification process 
>> of the VSP is in scope based on the current wording of the draft or that a 
>> consideration section can cover something that is outside the defined scope 
>> of the draft?
> 
> No, I agree that it's way out of scope. Gurshabad's proposed additions
> are in my point of view an attempt to address *judicial* issues (ensuring
> people's right to privacy, non-discrimination etc.) by adding wording to
> a *technical* specification. Lawyers and politicians exist to deal with
> such issues; engineers should not be required to waste their time with them.
> 
> Plus, even *if* such wording should end up in the draft, it would be
> utterly pointless. Looking at the various implementations of EPP and EPP
> extensions which are out in the open (especially for country code TLDs),
> it's obvious that even the most basic technical requirements (such as
> strict XML schema compliance) and MUST regulations are often ignored or
> violated by many operators. I'd therefore be surprised if anyone who's
> determined to "abuse" the extension for human rights violations would
> care much about the proposed additions anyway.
> 
> 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] Privacy and HR considerations for draft-ietf-regext-verificationcode

[Gould, James]

Gurshabad,

For the defined purpose of draft-ietf-regext-verificationcode, the VSP needs to 
be defined as an entity, but the VSP's verification process is not defined and 
is out-of-scope.  The use of examples in an IETF draft does not classify as 
guidance.  The only obligation of the VSP within 
draft-ietf-regext-verificationcode is to generate a technically compliant 
verification code and to store the proof of verification and the generated 
verification code.  There is no concrete definition defined within 
draft-ietf-regext-verificationcode of: 
- the forms of verifications performed by a VSP, 
- the data that must be passed for verification, 
- how the verification data is processed,
- the data sources that are used to perform the verification,
- the interface(s) or protocol(s) used by a VSP, and 
- other policies and technical details of a VSP.  

The majority of your considerations (Privacy and identified paragraphs from the 
HR) is focused on the policies and interfaces / protocols of the VSP that is by 
design out-of-scope from draft-ietf-regext-verificationcode.  

My recommendation is to strictly focus your proposed considerations text on the 
scope of draft-ietf-regext-verificationcode, that includes the definition of 
the verification code (e.g., digitally signed, typed identifier that provides 
proof of verification) and the passing of the verification code between the 
client (registrar) and the server (registry) over EPP. 

> I recommend that inclusion of these sort of elements be brought up to
> the IETF-level.

Not sure what you mean here. I think there is enough clarity from
the chairs and the IESG that it is entirely up to the WG about what to
include in the WG draft. [0][1][2]
  
Yes, it is my position that the proposed text included in your proposed 
sections as non-technical and focused on policy elements that the WG is not 
qualified to discuss and come to consensus on.  If you desire to have these 
sort of sections in WG drafts, it is best for it to be handled at the 
IETF-level and not at the WG-level.

Can you provide your latest proposed section(s) on the list for consideration 
by the WG?  

We also need to continue to hear from others in the working group.

Thanks,

—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 12/28/18, 5:49 AM, "Gurshabad Grover"  wrote:

On 26/12/18 8:02 PM, Gould, James wrote:
> [...] The thread with Andrew Newton did not clarify the applicability of 
the Privacy Considerations, but addressed two technical issues related to 
fixing the described relationship of the client with the server, and fixing the 
inappropriate inclusion of a normative policy statement.  The clearly out of 
scope elements of the HR Considerations section include the following bulleted 
items that are only associated with the VSP, and have nothing to do with 
draft-ietf-regext-verificationcode. [...] 
>  

For the context of the considerations, let's look at some text from the
draft:

"The VSP has access to the local data sources and is authorized to
verify the data. Examples include verifying that the domain name is not
prohibited and verifying that the domain name registrant is a valid
individual, organization, or business in the locality."

"It is up to the VSP and the server to define the valid values for the
"type" attribute. Examples of possible "type" attribute values include
"domain" for verification of the domain name, "registrant" for
verification of the registrant contact, or "domain-registrant" for
verification of both the domain name and the registrant. The typed
signed code is used to indicate the verifications that are done by the VSP."

"The VSP MUST store the proof of verification and the generated
verification code; and MAY store the verified data."

So, the draft
(1) describes the role of the VSP;
(2) has guidance on what types of verification the VSP can perform; and
(3) places certain obligations on the VSP.

So, I think it's unfair to say that considerations that touch upon the
VSP's role "have nothing to do with draft-ietf-regext-verificationcode."

Re: text of the considerations...

The proposed privacy considerations rely entirely on the draft and the
guidance in RFC6973 (very commonly used across working groups to write
privacy considerations). Specifically, the excerpts above and the
following items in RFC6973:

* "Are there expected ways that information exposed by the protocol will
be combined or correlated with information obtained outside the
protocol?" [3]

* "Does the protocol provide ways for initiators to express individuals'
preferences to recipients or intermediaries with regard to the
collection, use, or disclosure of their person

Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

[Gould, James]

John,

The 2119 words MUST and MAY are used to signify requirements; although that 
does imply interoperability as well.  This statement is associated with making 
the verification code functional, since the verification code represents a 
signed and typed verification pointer, it must point to something.  The VSP is 
required, by the normative MUST, to store the proof of verification and the 
generated verification code, and can optionally, by the normative MAY, store 
the verified data.  The "; and MAY store the verified data" can be removed, 
since the proof of verification is the only requirement for the verification 
code to be a functional pointer.  

Do you agree that the "; and MAY store the verified data" text should be 
removed?The statement would then read:

"The VSP MUST store the proof of verification and the generated verification 
code."

Thanks,
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 12/28/18, 2:45 PM, "regext on behalf of John Levine" 
 wrote:

In article <41f72627-faf2-1fd4-b356-065b3cb98...@cis-india.org> you write:
>"The VSP MUST store the proof of verification and the generated
>verification code; and MAY store the verified data."

The 2119 words MUST and MAY are about interoperation.

Now that you point it out, this has nothing to do with interoperation
unless compliance somehow affects interop.

I would suggest removing that part, or at least making it
non-normative since business practices are generally way out of scope
for IETF specs.

R's,
John

___
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] Privacy and HR considerations for draft-ietf-regext-verificationcode

[John R Levine]

The 2119 words MUST and MAY are used to signify requirements; although 
that does imply interoperability as well.  This statement is associated 
with making the verification code functional, since the verification 
code represents a signed and typed verification pointer, it must point 
to something.


I don't understand why.  The code is a signed token.  Imagine the registry 
goes back to the signer asks about token 123-foo666 and the answer is 
"We're the Ministry, we signed it, of course it's valid.  The details are 
secret."


While that would not be my favorite way to work, and I can easily imagine 
other scenarios with auditing and transparency business requirements, why 
wouldn't that interoperate?


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [regext] DOODLE: select your documents

[James Galvin]

Thanks Scott, for your question.  I have also gotten a few private 
questions about details of how “selections” will be interpreted and 
acted upon.  Rather than respond to your specific question let me make a 
general statement that I have made privately to a few folks.


Antoin and I are not trying to make this a particularly formal process.  
The IETF generally and certainly this working group specifically are 
guided by consensus.  It is our intention to interpret any results as 
broadly as possible.  We will certainly explain our decision process 
with any announcement of results.  If there are questions or concerns 
then we’ll address them, including the possibility of trying something 
different if this path doesn’t yield a consensus.


Of course, any decision we propose will be subject to approval by the 
working group.


We’re all working together to progress the work that is most 
interesting to the most people.


Hopefully no one will create entries that are problematic, hint hint!  
Note that folks can choose to edit their entry, until the Doodle is 
closed, or even add a second entry with a comment at the moment 
explaining which is preferred.


Of course anonymous entries will be problematic.  Please don’t do 
that.  If you do we’ll probably look at results both with and without 
your entries.  If that creates a problem then we’ll have to ask the 
working group to help us resolve the issue.


To everyone, please be fair and reasonable.  Antoin and I will do our 
best to do the same.


Thanks,

Jim






On 2 Jan 2019, at 9:55, Hollenbeck, Scott wrote:


-Original Message-
From: regext  On Behalf Of James Galvin
Sent: Friday, December 21, 2018 11:13 AM
To: Registration Protocols Extensions 
Subject: [EXTERNAL] [regext] DOODLE: select your documents

Please take the time to select the documents you support for 
advancement

in this working group.

https://doodle.com/poll/6nyguby3yr8dx9cp

Please select from 1-5 documents.


Jim, how do you propose to address submissions that contain more than 
five "green checkmark" selections?


Scott


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

Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

[Adam Roach]

[as an individual]

On 1/2/19 12:10 PM, John R Levine wrote:
The 2119 words MUST and MAY are used to signify requirements; 
although that does imply interoperability as well.  This statement is 
associated with making the verification code functional, since the 
verification code represents a signed and typed verification pointer, 
it must point to something.


I don't understand why.  The code is a signed token.  Imagine the 
registry goes back to the signer asks about token 123-foo666 and the 
answer is "We're the Ministry, we signed it, of course it's valid.  
The details are secret."


While that would not be my favorite way to work, and I can easily 
imagine other scenarios with auditing and transparency business 
requirements, why wouldn't that interoperate?



If we're concerned merely with interoperation, the same is true of most 
-- if not all -- normative keywords used in "Security Considerations" 
sections. Your position might (or might not) be correct, but the logic 
of "2119 language is only used for interoperabilty reasons" simply isn't 
true.


/a

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

Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

[John R Levine]

On Wed, 2 Jan 2019, Adam Roach wrote:

 I don't understand why.  The code is a signed token.  Imagine the registry
 goes back to the signer asks about token 123-foo666 and the answer is
 "We're the Ministry, we signed it, of course it's valid.  The details are
 secret."

 While that would not be my favorite way to work, and I can easily imagine
 other scenarios with auditing and transparency business requirements, why
 wouldn't that interoperate?


If we're concerned merely with interoperation, the same is true of most -- 
if not all -- normative keywords used in "Security Considerations" sections. 
Your position might (or might not) be correct, but the logic of "2119 
language is only used for interoperabilty reasons" simply isn't true.


I think there's a difference -- in security sections the goal is usually 
to prevent leakage or spoofing or something else that would allow a 
malicious party to interoperate with a victim.  One part of good interop 
is not to interoperate with attackers.  But that's not what's going on 
here.  The signature shows that the token is valid, and unless I'm missing 
something, whatever you might learn from the thing the token represents is 
outside the scope of EPP.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

[Gould, James]

John,

To remove any concerns related to the inclusion of VSP policy in 
draft-ietf-regext-verificationcode, the sentence " The VSP MUST store the proof 
of verification and the generated verification code; and MAY store the verified 
data." can be removed.  If there are no objections to the removal of this 
sentence, it will be removed in the next version of the draft.  
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 1/2/19, 3:56 PM, "regext on behalf of John R Levine" 
 wrote:

On Wed, 2 Jan 2019, Adam Roach wrote:
>>  I don't understand why.  The code is a signed token.  Imagine the 
registry
>>  goes back to the signer asks about token 123-foo666 and the answer is
>>  "We're the Ministry, we signed it, of course it's valid.  The details 
are
>>  secret."
>>
>>  While that would not be my favorite way to work, and I can easily 
imagine
>>  other scenarios with auditing and transparency business requirements, 
why
>>  wouldn't that interoperate?
>
> If we're concerned merely with interoperation, the same is true of most 
-- 
> if not all -- normative keywords used in "Security Considerations" 
sections. 
> Your position might (or might not) be correct, but the logic of "2119 
> language is only used for interoperabilty reasons" simply isn't true.

I think there's a difference -- in security sections the goal is usually 
to prevent leakage or spoofing or something else that would allow a 
malicious party to interoperate with a victim.  One part of good interop 
is not to interoperate with attackers.  But that's not what's going on 
here.  The signature shows that the token is valid, and unless I'm missing 
something, whatever you might learn from the thing the token represents is 
outside the scope of EPP.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

[John R Levine]

On Wed, 2 Jan 2019, Gould, James wrote:

To remove any concerns related to the inclusion of VSP policy in 
draft-ietf-regext-verificationcode, the sentence " The VSP MUST store the proof of 
verification and the generated verification code; and MAY store the verified data." 
can be removed.  If there are no objections to the removal of this sentence, it will be 
removed in the next version of the draft.


That's OK with me.  I'm not totally opposed to it but without some hint 
about what an interoperating system would do with the object the token 
points to, I think it's confusing.  As you can see, it confused me.




—

JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com 

On 1/2/19, 3:56 PM, "regext on behalf of John R Levine"  wrote:

   On Wed, 2 Jan 2019, Adam Roach wrote:
   >>  I don't understand why.  The code is a signed token.  Imagine the 
registry
   >>  goes back to the signer asks about token 123-foo666 and the answer is
   >>  "We're the Ministry, we signed it, of course it's valid.  The details are
   >>  secret."
   >>
   >>  While that would not be my favorite way to work, and I can easily imagine
   >>  other scenarios with auditing and transparency business requirements, why
   >>  wouldn't that interoperate?
   >
   > If we're concerned merely with interoperation, the same is true of most --
   > if not all -- normative keywords used in "Security Considerations" 
sections.
   > Your position might (or might not) be correct, but the logic of "2119
   > language is only used for interoperabilty reasons" simply isn't true.

   I think there's a difference -- in security sections the goal is usually
   to prevent leakage or spoofing or something else that would allow a
   malicious party to interoperate with a victim.  One part of good interop
   is not to interoperate with attackers.  But that's not what's going on
   here.  The signature shows that the token is valid, and unless I'm missing
   something, whatever you might learn from the thing the token represents is
   outside the scope of EPP.

   Regards,
   John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
   Please consider the environment before reading this e-mail. https://jl.ly




Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext