Re: DNS much?

First, I want to apologize if you took offense to the suggestions I
was making - they were made with the intent only of improving the
security of your work.  That said, perhaps I can address the specific
questions raised below so that others can understand how a
certificate authority (CA) comes into the situation.

To those playing along at home, the basic question at hand is how do
you guarantee uniqueness for human readable names in a distributed
environment.  Whether you want to guarantee uniqueness is a whole
different matter thats been discussed more times than I can count,
but for the sake of this email, assume that you *do* want human
readable and globally unique addresses.

> In order to have a true DHT DDNS you can NOT have a CA that signs
> everything. How do you update your Base64 for your Domainname?
> Lease time?
> How do you add a sub Domainname? and make sure its the right
> person adding it?

These are good questions, and the PKI people have done pretty well at
offering solutions.  Here's an example:
 * When registering a name with the CA, they give you a
   public/private keypair and a signed statement saying
   "the public key XYZ is authoritative for *.somename.i2p"
 * Whenever you want to add a new name under *.somename.i2p
   or change the destination associated with one of the names,
   you simply sign a new address entry with the private key that
   the CA gave you.  The entry itself also contains the signed
   statement from the CA, so anyone looking at it can verify it.
 * If you want to expire those entries periodically, you can
   put that data in the signed address entry (for instance,
   "www.somename.i2p is $base64 until midnight on Nov 5, 2004"
 * If the 'grant' of a domain name is intended to be expired
   periodically, the CA could instead give out temporary
   keypairs and statements - e.g. "the public key XYZ is
   authoritative for *.somename.i2p until November 5, 2004"

At this point everyone always knows whether an entry is valid, and
there is no way to spoof it, assuming the integrity of the keys and
the strength of the cryptosystem.  (this is similar to how I2P's
internal network database manages LeaseSets, except they're signed by
individual Destinations)  You can go on and build in things like
revokation lists, though that infers additional overheads to query
for revocation.

> What if the CA goes down? or 2?

No new names can be registered when the CA is unavailable, but
everyone can continue to lookup or verify existing names, as the CA's
public key is well known.

> What if the private key of the CA gets stolen or lost? Hacked?

If whomever controls the unique database isn't acting properly, then
people need to move to another CA.

> Ok you have it signed by the CA, how do other Nodes get it?

There are many options for distributing and searching for names.  The
simplest possible way is how we do it now - a local file manually
updated.  That sucks though, but its all we've had, and is functional
enough for a small network.

Getting more advanced, you can build systems like Ragnarok's address
book tool, which lets you subscribe to other people's hosts file,
pulled from their eepsite.

Another technique is to use a DHT approach - querying the DHT for a
particular name (using H(name) as the key and retrieving the address
entry as the value).

> If you loose your pub/priv key to your domain, how do you update
> it?

This is a hard one.  I suppose a CA could be built that allowed you
to use alternate means of reauthorizing a new certificate (e.g.
register with a PGP key).

> A CA is good for data that will never have to be changed. one
> time use kind of thing.  It can not be used in a dynamic
> enviroment such as a DNS.

Well, I do feel like I'm playing the devil's advocate here, as I
don't think CAs are the way to go for naming.  However, if you want
human readable names that are both secure and globally unique, you're
going to need some authority to guarantee that uniqueness.  IMHO, the
damage that can occur by a successful spoof of a name is tremendous,
and must be avoided at any cost, but thats just my perspective.

You certainly can avoid the public key side of things, requiring the
user to query the authority whenever they are in doubt as to the
validity of some name, but public keys can be used for dynamic data
just fine, as explained above.

Naming is a big issue, and for many applications it will be critical
to get it right.  There has been a lot of work on naming over the
years though, and I think its useful to look back to see what we can
learn from similar systems.

I do hope you'll consider continuing with your work, as a DHT for
naming lookup would be fantastic (and relevent even for non-unique
naming systems).  I'm sure people would be willing to help out with
various parts that you have concerns with too.

=jr