From: p2p-hackers@zgp.org (Gordon Mohr)
Date: Tue Jul 16 11:08:02 2002
Subject: [p2p-hackers] Everything as a file in p2p

Aaron Swartz writes:
> This sounds something like the ESL proposal. It seems silly to abstract 
> things like this because, unlike DNS, there is no central registry for 
> KAUs. I doubt IANA would be eager to start one. It would be far simpler 
> to have each KAU register their own scheme.
> 
> http://lists.w3.org/Archives/Public/www-rdf-
> interest/2001Sep/att-0067/01-draft-palmer-esl-uri-00.txt
> 
> There are some obvious mistakes in this draft (encoding whitespace) but 
> I don't think anyone was really willing to push the scheme thru any 
> further.

Yes, that's similar...  but more than the hash used should be
parameterizable: the signing algorithm should be as well, those
things change for legal/technical reasons more often then the
basic technique would need to be revised.

Also, there's no need to include the actual signature of the name
inside the URI.  All you want in the URI is the public-key 
identifier: you're saying "I am referring to the resource, if any, 
which this key gave this name", not providing the additional 
proof-material that the given key ever used that name (or that a 
particular resource has that name).  

Are you suggesting that instead of a parameterized "kau" type, 
there be different URI types for each signing algorithm? 

That just pops the registration issue up a level, pollutes the
URI-scheme namespace,  and might prevent software from recognizing
when a URI is a key-authority name, but from a yet-unknown 
algorithm. A software module need not understand the algorithms 
to be useful; a DHT-based library might have a rule for finding
the nodes responsible for certain "kau:" entities without knowing
the algorithms in use. 

You don't even really need a formal IANA-type registration 
procedure when your universe of possibilities is small,  and 
all people who might be choosing conflicting tokens can easily
find each other. So just to parameterize the hash names 
("sha1", "sha256", "tiger", "tigertree", etc.) and signing algs
("rsa", "elgamal", "ecc", etc.) barely needs a new registry,
or can piggy-back off existing registries for other purposes.

[Tangent: Just like search engines such as Google have made the 
DNS registration system less important,  do tools like Google
and the Internet Archive make specialized collision avoidance
registries, like IANA, less important? Now you can claim a 
name-token by widespread use, and others who come later can
easily find out if prior uses exist, and in what contexts,
and possibly even as-of-what-date. Of course, some people won't 
check Google, or be tactful about avoiding confusion, but those 
are the same people who won't check IANA and prior activity 
anyway.]

- Gojomo