Re: CERTificates and public keys

[Simon Josefsson <simon+dnssec@josefsson.org>]

Derek Atkins <warlord@MIT.EDU> 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.

Yes.  But some applications aren't concerned with the name.  Some need
additional trust.

For example, a S/MIME mail client may need to trust the binding
between the owner of a certificate and a public key.  DNSSEC can
provide a binding between the email address and the public key, but
that isn't enough for all applications.

Admittedly, today most S/MIME CAs only guarantee the binding between a
mail address (= domain name) and a public key.  Today there is no
semantic difference in most cases.  But consider a CA that only issues
certificates if you show up physically with a I.D. card.  A S/MIME
client that trusts this CA provides "better" security than a S/MIME
client that trusts a CA that issues certificates after only checking
the domain name binding.

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

No, a PKI may provide better security than only binding virtual names
to public keys.

CERT allows for this, KEY does not.