Re: Trusting keys (was Re: looking for draft volunteers)

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

> To use the obvious example, nobody really likes
> Verisign, and their level of accountability is not as good as it ought to
> be, but the situation isn't so bad that people are credibly arguing for
> lots of lower-profiles DNS roots for people to choose among.

It's one thing to trust VeriSign to maintain the root domain (and I don't
think that trust is well-placed); it's quite another to trust them to sign 
everyone's keys.  NSI managed to keep that gig because of heavy-handed
political coercion, not because they were doing an exemplary job with 
that position of trust.  We're still suffering from NSI's past abuses.  

It would be completely, absolutely irresponsible for IETF to recommend
that everyone place trust in a VeriSign-signed root key - even for casual
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.
> 
> I think that this is a very hard problem, similar to the problem of
> allowing multiple DNS roots without creating hopeless confusion.

I agree that it's a difficult problem, but I don't think it's similar to
the multiple root problem.  Overnight I realized that you can't assign
trust values that can be compared to different keys.  What you can say 
are things like "this key is signed by a key that you trust for purpose 
X" and let users (or their superiors) supply the X for a given key.  
X might be "casual use" or "XYZ company business" or "XX government 
official business" or whatever.

> Moreover, even if we came up with a good solution, I think it would be
> interesting to a vanishingly small fraction of the people in the world who
> need computer security--much as PGP is interesting to a vanishingly small
> fraction of email users today.

I don't think this is due to PGP's key model-  but rather to RSA's efforts 
to discourage PGP and push S/MIME, which ended up diluting the market.

> Should we use DNSSEC-based trust for life-critical applications?  Probably
> not (though I'm sure people will; heck, I'm sure people already do, even
> without DNSSEC).  Should we use DNSSEC to identify banks?  Only sort of;
> you need out-of-band knowledge of what the bank's domain name is.  Should
> users and organizations be able to set up little islands and empires of
> trust which are independent of the DNSSEC trust hierarchy?  Probably, but
> I wouldn't want that capability to delay or destroy the deployment of a
> common-case solution.

I disagree that it's a common-case solution.  It's a common-case problem
pretending to be a solution.  We're probably better off without any DNSSEC 
framework at all than with one that insists that we trust the DNS root 
key axiomatically.

Keith