<div dir="ltr">Joe and Dave,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div><br></div><div>Steve</div><div><br></div></div>