Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:49
Anonymous (nobody@replay.com)
Tue, 2 Mar 1999 21:08:49 +0100
[I suggest that CodherPlunks discussion be restricted to technical issues
and avoid political commentary on trademark law.]
> 1) every registrant can be anonymous or pseudonymous but must provide
> contact details that could be accessed in the event of a subpoena. They
> would not show up on whois to the whole world. (data is entered into a
> computerized form with no human verification) The best version has the
> data put in some form whichthe registrant can decrypt when the subpoena
> comes or else lose the domain name.
By "anonymous/pseudonymous" we mean that it should not be possible for
a third party to determine who owns which domain name. Even someone
who could guess the owner's contact information should not be able to
confirm a guess at whether that person owned a particular domain name, not
without going through the challenge procedure. Therefore we don't want
to make the whois database hold just a hash of the contact information.
Anyone could verify a guess at that information.
It would probably also be desirable that there is no special third party
who is able to confirm such guesses. Such a third party would become
a target for attacks, both legal and illegal. Storing contact info
encrypted with some special public key would not satisfy this condition,
because the corresponding private key would expose all the linkage.
Likewise, storing a hash of the contact info concatenated with a secret
string known only to an arbitration party would not be good, because
that party would be able to confirm guesses at contact info.
> Again, if we start with the model that we want easy, cheap, instant
> registration (that's what the customers want and are used to), then we
> can't front-end all this. The serious processing/checking can't start
> until the challenge, I think.
If we don't verify contact information at the time registration is
made, then it will be easy to register in false names. It is important,
therefore, that there be no value in a false registration. For example,
if challenging a registration were costly to the challenger, it might
be an effective strategy to register names knowing that they would not
survive a challenge. This could impede a competitor who would want to
use certain names, while leaving the malicious registrant anonymous.
This is not a problem?
> 2) registrants who provide false contact details can be detected upon a
> challenge by a third party, but the third party does not get to know
> accurate contact details.
It goes without saying that the actual verification of contact info has
to be done by a person. The accuracy of the information is a contingent,
physical fact about the world which can't be verified by mathematical
means. Cryptography obviously can't do this part. Someone will have to
at least make a phone call, or pay a visit, or do some other real world
checking.
> I'm willing to hypothesize the existence of an honest broker if I
> have to, in which case #s 1 & 2 are trivial, but I would rather not.
If the challenger doesn't get to know contact details, then he is
not the person making the phone call. Someone else must be doing so.
Such a person should be honest, and as an intermediary he is acting
as a broker. It is therefore impossible to avoid an "honest broker"
in this verification step.
The best we can do is to have the system such that *any* third party
can perform the contact info verification. He could be an arbiter who
is acceptable both to the challenger and the registrant (one or both of
whom may be participating anonymously in the discussion). Once such an
arbiter is selected, he can verify the contact information and report
the results (in terms of success/failure) to the challenger. It might
be possible to set things up so that even the arbiter doesn't learn
which domain name's validity he is checking.
> 3) it is possible for a third party who wishes to challenge the
> registration of Domain DN1 to find out how many other domains have been
> registered by the owner of DN1, and what they are, without necessarily
> finding out the identity of the registrant.
I can see two ways to accomplish this. One is to set it up so that
all registrations by a given party have the same information in the
(public) database. This way everyone can see which and how many
registrations each owner has allocated. But no mapping of database
entries to names/addresses is possible unless a challenge occurs.
The other way is to allow all of an owner's registrations in the database
to look different. But then there must be a special third party which
is able to map from database entries to some kind of identifier which
is unique per person.
(In particular, it would not be practical to use a protocol which
detected when two entries are owned by the same person, only with the
cooperation of the owner(s). With millions of entries in the database,
it would be intractable to learn which other domains are owned by a
particular owner, since that would require millions of interactions.
Hence the need for a trusted third party who can learn this information
on his own, without the cooperation of the domain owners.)
For this third party, the structure of the database in this approach
is the same as it is for everyone in the first approach. The special
third party can know which domain names are owned by the same person.
No one else can tell.
Is there any advantage in hiding this information so that only the third
party knows it? I think not. It only makes the third party a target
for coercion or theft. And the information is not so sensitive that it
must be kept secret. The first approach appears superior.
I see two methods of arranging that all the DN registrations for a given
party will have the same information. One is to make the DN registration
information a deterministic function of the contact information.
It could be a hash of the contact info, but that would violate the
principle in the first paragraph above. Or it could be a hash of the
contact info plus a secret value known by a special third party, but
that would violate the principle in the second paragraph, above.
The second method is to give out tokens for each registrant, and prevent
anyone from getting two of them. This also requires a special third
party, but he has no power to learn the mapping between owner name
and registry information. His only job is to ensure that tokens are
given "one per customer".
This requires storing all owner names to which tokens have been given,
or at least a hash of them. Although this may appear to be setting up a
"global ID system" it is actually not that big a database. An 80 bit
hash ought to be enough to prevent birthday collisions, which is 10
bytes per person. With 6 billion people in the world the server need
only store 60 GB of data max, which should be pretty cheap in a couple
of years.
As for the concern about "creative data entry" to make variations
on contact information, this can largely be addressed by putting the
information into a canonical form. Ideally there would be no variation
on how a given piece of information would be represented.
As described previously, these tokens can be blinded for anonymity.
A third party (the "arbiter" above) can verify the mapping between
contact information and token. This would only be done at challenge
time, so the expense is not large. Anyone can see which domain names
are owned by the same person, since he has only one token and so they
will all have the same entry in the whois database (modulo fraud issues
which have been discussed previously).
One problem with this approach is that the necessary technologies for
blinding are patented in many countries. However with the DigiCash
bankruptcy there has been discussion of making these patents more
generally available. Even if the patents are not made freely available,
this application could be considered a good advertisement for the
technology and it might be possible to negotiate a free license for this
particular purpose.
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:49