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

[Ted Hardie <Ted.Hardie@nominum.com>]

On Mon, Jan 14, 2002 at 02:12:24PM -0500, Keith Moore wrote:

> >      such that a client which starts out
> >      knowing only the public key of the DNS root can securely associate
> >      application data with DNS names.
> 
> ...  but it doesn't imply the second part.  no client should axiomatically
> trust "the public key of the DNS root" - that's investing far too much
> trust in one organization.  it would be completely irresponsible for
> IETF to recommend that clients invest such trust.  
> 
> nor does trust in the root (or any zone) imply that the zones under 
> it should be trusted.
> 

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?

"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?

> 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.

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?
				regards,
					Ted Hardie