[chord] new auth type patch

[Michael Walfish]

Frans wrote:

| What the exact interface to dhash should be is not only an interesting
| implementation question but gets at the heart of what a DHT is and for
| what it is useful.

So are people curious about other requirements or anticipated future 
requirements users might have for dhash? If that's a conversation that 
dhash developers and designers are having, then permit me to mention 
another interface / block type it might be nice to have:

I mentioned this in my first e-mail to the list as "option B" (option A
being what is now called "pubkey+salt"). Option B mentioned a block type
that would not be self-certifying, but dhash (a cooperating dhash, anyway)
would ensure that if a user inserts a block with id I and public key P
that future updates to the contents of I have been signed with P's
corresponding secret key, S. The reason for abandoning self-certification
is that one could imagine wanting to update the public key associated with
a block.

Our motivation is that chordIDs wind up being long lived references in our
application, and, ideally, the lifetime of our references would not be
constrained by the lifetime of the corresponding public key. Also, we
envision some degree of management over the nodes comprising the dhash, so
we needn't assume arbitrary maliciousness.

I realize it is very difficult to get key update to work and that this
kind of thing might require assumptions about the types of attacks that
are expected (and the level of trust of nodes), but for now, I'll just say
that it might be useful to have a block type where the user selects the id
completely independently of the contents; this differs from noauth because
users would have to present a valid signature on insert and on update.

Also, depending on the application and on whether the dhash nodes are part
of a "managed infrastructure" vs. being behind cable modems, trust
assumptions might be more or less reasonable. For example, everyone trusts
the root and top-level domains of DNS even though these do not currently
use meaningful security.

I don't have a suggestion for this block type that yields the same
guarantees provided by self-certification, but I would like to toss this
into the conversation if people are talking about block types and the
requirements of applications that use dhash. And if there is demand for
the block type, I would be happy to implement it.

Thanks,
Mike