Re: looking for draft volunteers

[Keith Moore <moore@cs.utk.edu>]

> Unless, of course, we have a single CA that we can all trust.  And
> quite honestly the only central authority that anyone in the internet
> has any trust in at the moment (albeit very little trust) is the DNS
> root.

Quite honestly, there is no central authority in the Internet (or
in the Real World) which everyone will (or should) trust absolutely.  

(And if you make it so attractive to attack the DNS root then it becomes
even less trustworthy than it is now)

But in the meatspace world this doesn't stop us from extending limited 
amounts of trust to various kinds of credentials - including some issued 
by central authorities of fairly large domains - but we vary the degree 
of trust that we place in a credential according to the authority that
issued it, our perceived liklihood that it's forged, and the purpose for
which we're authenticating.

If you want to store the DNS root key (or perhaps the keys of most
TLDs) on your client, and use DNSSEC keys to verify the public key
of a random email recipient with which you have no prior association,
that's probably better than having no key at all.  But you'd be 
naive to trust that key to safeguard information for which disclosure
could cost lives.

In other words, getting keys solely by DNSSEC and knowledge of the 
DNS root might be okay for casual use, but it's not a mechanism in
which one should place arbitrary amounts of trust.  At the same time,
using DNS to find keys and using external means to authenticate 
them can provide keys which are more trustworthy (because you have
that external information) without your having to have previously
acquired and verified every key you might want to use.

I think a single framework could accomodate the entire spectrum
of trustworthiness vs. pre-verification.  The real trick is to 
provide the user with enough information so that he doesn't place
an inappropriate amount of trust in whatever keys he's getting.

Keith