To:
Simon Josefsson <jas@extundo.com>
Cc:
Edward Lewis <lewis@tislabs.com>, <dnssec@cafax.se>
From:
Derek Atkins <warlord@MIT.EDU>
Date:
31 Aug 2001 17:36:51 -0400
Delivery-Date:
Sun Sep 2 14:24:23 2001
In-Reply-To:
Simon Josefsson's message of "Fri, 31 Aug 2001 10:58:12 +0200 (CEST)"
Sender:
owner-dnssec@cafax.se
Subject:
Re: CERTificates and public keys
Simon Josefsson <jas@extundo.com> writes:
> > If we use the KEY RR, and I already have a public key for the root zone,
> > then I could just follow the DNS hierarchy (assuming a completed tree).
> > For a fragmented tree, I just need the enclosing island of trust's key.
>
> Yes, but what would you know after you've done this?
>
> Only that the key came from a certain origin. To be able to trust that
> the key is bound to a certain host or user, you need more than that.
> Specifically, the key must be signed by someone you trust to make the
> decision to connect a public key to a host or user.
No, you know that:
a) the RR came from the right zone,
b) the has the name asserted by the zone administrator
In other words, you get the same information as you would from any
other certificate, namely that the signer of the certificate asserts
a binding between the name and the key. DNSSec is proving that same
mapping between the CERT record and the _name_ of the record.
For example, a signed record:
my-machine.mit.edu. in cert <blob>
sig cert <xxx>
This ABSOLUTELY asserts that <blob> belongs to "my-machine.mit.edu."
and provides the exact same security as any other PKI that would
attempt to say the same thing.
It doesn't matter what's in <blob>. The fact that <blob> may be
an X.509 certificate with a secondary verification path is, IMHO,
icing on the cake, not the meat-and-potato of the problem here.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available