[TSG-Access-RD] Comment and question re 4 June 2018 letter from APWG to ICANN re hashing PoC data

Steve Crocker steve at shinkuro.com
Tue Feb 5 20:57:02 UTC 2019


Joe and Dave,

I'm a member of Ram Mohan's Technical Study Group (TSG).  The TSG just
received a copy of your proposal for consideration within the group.
Separately, I've been looking at the multiplicity of possible policies
related to whois data.  I've got a question and a comment, but let me
hasten to say this note is solely from me and does not represent anyone
else or any group.

Comment: The use of a private key as part of a hash seems odd to me.  There
is a ton of advice as well as practice that private keys are heavily
protected, most often within a hardware device that does not expose them
for any use other than to sign or decrypt messages.  I understand the
intended use, and it looks like you're simply using this as a salt.
Therefore, why not generate a suitably strong salt?  If you want to use
something related to strong crypto keys, then I guess the way to do it
would be to generate a public-private key pair and use the *public* part as
the salt.  You would, of course, need to protect the public part and not
expose it publicly.

Question: Can you say more about the reasoning related to different keys
(salts) across different registries?  I understand that it might be hard to
design a system that yields the same hash across all registries -- and all
registrars for a thin registry -- so that might be the reason for your
decision, but that seems like a decision determined by the pragmatics of
keeping the salt(s) safe and not because it was the preferred result.  This
issue leaped out at me as I read through the document and when I got to the
FAQs, I saw the question was asked but the answer was simply it was an
intentional design choice.

Thanks,

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tsg-access-rd/attachments/20190205/de7b0783/attachment-0001.html>


More information about the TSG-Access-RD mailing list