[TSG-Access-RD] For consideration: Proposal to hash PoC in Public Domain Name Whois

[Ram Mohan]

>From my perspective, we only are being asked to consider the proposal. We
don't have to act on it, nor do we have to consider implementation. The
responses from us will go back to the ICANN Board Technical Committee, who
then have to decide what, if anything, they do with it.

The substantive issues below, plus any others we gather, might be all that
we provide as a response.

--------------------------------------------------------------------------
-------
Ram Mohan
(o) +1.215.706.5700 x103  (m) +1.215.431.0958  (f) +1.215.706.5701
rmohan at afilias.info | Skype: gliderpilot30 | Twitter @rmohan123
--------------------------------------------------------------------------
-------

-----Original Message-----
From: Andy Newton <andy at hxr.us>
Sent: Tuesday, February 5, 2019 3:22 PM
To: Hollenbeck, Scott <shollenbeck at verisign.com>
Cc: tsg-access-rd at icann.org
Subject: Re: [TSG-Access-RD] For consideration: Proposal to hash PoC in
Public Domain Name Whois

On Tue, Feb 05, 2019 at 07:07:28PM +0000, Hollenbeck, Scott via
TSG-Access-RD wrote:
> (Trimming recipients)
>
> > -----Original Message-----
> > From: TSG-Access-RD <tsg-access-rd-bounces at icann.org> On Behalf Of
> > Ram Mohan
> > Sent: Tuesday, February 5, 2019 1:02 PM
> > To: Adiel Akplogan <adiel.akplogan at icann.org>
> > Cc: MAEMURA Akinori <akinori.maemura at board.icann.org>; tsg-access-
> > rd at icann.org; David Conrad <david.conrad at icann.org>; John Crain
> > <crain at icann.org>
> > Subject: [EXTERNAL] Re: [TSG-Access-RD] For consideration: Proposal
> > to hash PoC in Public Domain Name Whois
> >
> > Dear Akinori, Adiel,
> > The TSG will consider this proposal and will revert to the BTC on
> > the questions posed below in the next few weeks, certainly prior to
> > the Kobe meeting.
>
> Thanks for passing this on, Ram. At first glance I see potential for
conflict with RFCs 6350/7095 (vCard/jCard)  and  7483 (RDAP responses).
For example, the proposal suggests that an email address (which is
returned as part of a jCard structure by RDAP) could be replaced with a
hash value. RFC 6350 says this about vCard email address values: "Even
though the value is free-form UTF-8 text, it is likely to be interpreted
by a Mail User Agent (MUA) as an "addr-spec", as defined in [RFC5322]".
So, we don't know how downstream consumers (such as vCard parsers) of
these hash values will deal with them when they're expecting structured
email addresses, telephone numbers, etc.
>
> What part of this is actually in our remit? It doesn't have anything to
do with authentication or authorization.

Scott brings up a good point. Saying a field is an email address and
providing something that is not an email address in that field is likely
to cause clients to believe there is a syntax error.

We did discuss similar ideas during our last face-to-face, but I do not
know where we landed regarding a decision.

Can we ask for the requirement that has yielded this implmentation path?
Are they looking for a globally unique identifier? What is the idea behind
the hash? Is it that only certain people know how to reverse the hash
(assuming a two-way hash) or have other knowledge about the hashing
function?

-andy