Re: RESCAP/RC: an alternative to key distribution using DNS

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

> I'm a tad confused here, so forgive me for restating this to make
> sure I understood you.
> 
> "no client should axiomatically trust "the public key of the DNS root"
> means that they shouldn't trust it for purposes other than as
> an authentication mechanism for the root.  Yes?

Mostly yes.  However, if there is reason to believe that the root key 
(or the key of any other zone) might have been compromised, it's not 
clear that you should believe a signature from that key even to sign
information in that zone, much less to sign keys of other zones. 

And absent reliable information about how a zone maintains its keys, 
my assumption would be that the key of almost *any* zone "might have
been compromised".  So I wouldn't place much trust in them.
and I think this assessment is realistic given the current level of
knowledge about cryptosystems.  Most people can't be trusted to lock 
doors reliably, even though they presumably understand how locks work.

OTOH, if I did trust a particular tree of zones  to maintain
their keys properly, and I had the key for the root of that tree, I'd 
very much like to have a well-defined mechanism to use that zone's 
DNSSEC records to validate keys signed by parties in that zone. 

> "nor does trust in the root (or any zone) imply that the zones
> under it should be trusted".  I'm not sure what "trust in
> the root" means here.  My guess is that you are saying that having
> a signed zone that can be traced back to the root doesn't
> imply anything about the trust which a client should place in
> the keys stored in that signed zone.  Yes?

yes.
 
> > instead, clients need to be configurable as to which public keys they
> > trust, and for what purposes.  there's no getting around this.
> 
> I think the major force driving this group is that it is not scalable
> to do that configuration on a per client basis.  I believe we are
> trying to reach for a system that allows an administrator to configure
> a client by reference to an external system.

And that's quite a reasonable thing to do - at say, an organizational
level.  But saying "the client needs to know only the public key of 
the root" - and that such a key is trustworthy for any purpose - is 
just too much of a stretch.

> Imagine for a moment that we introduce an RR that indicates the CA
> associated with a particular A record.  It does nothing else: no key
> data is present, no signature is present; it just says, the CA for
> this is FOO.  I can now easily imagine configuring a client to say:
> "do not trust a certificate presented by a host when that certificate
> is not associated with the CA associated with the A record for the
> host."  This does not replace any mechanism for installing trust
> in root CAs, it simply adds a check (i.e. if there is another
> rule that says "Don't trust Joe's Bait and Tackle CA, it doesn't
> over ride it).
> 
> I can easily see doing the same thing by naming the CA in the metadata
> stored at RESCAP server.
> 
> How far off are we?

You can certainly do that.  But that approach wouldn't allow the client
to have any more confidence in the rescap data even if it did trust
the key for the DNS zone.  It would only give the client reason to 
have negative confidence in the rescap data if the CA names didn't match.

Keith