[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Simon Josefsson <jas@extundo.com>
Cc: Edward Lewis <lewis@tislabs.com>, dnssec@cafax.se
From: Edward Lewis <lewis@tislabs.com>
Date: Thu, 30 Aug 2001 16:20:19 -0400
Delivery-Date: Fri Aug 31 20:34:43 2001
In-Reply-To: <ilur8ttny7y.fsf@barbar.josefsson.org>
Sender: owner-dnssec@cafax.se
Subject: Re: CERTificates and public keys

At 3:29 PM -0400 8/30/01, Simon Josefsson wrote:
>I do not think I understood the first paragraph (what do you mean by
>there being no CA backing the CERT record?  I agree with the
>statement, but I do not see why it matters), but here are my
>top-of-the-head reasons for preferring certificates in CERT over
>public keys in KEY.

Assuming a certificate is not self-signed, the signature attached to the
certificate is generated by another entity.  The idea being that I, as a
user of a certificate, can start with the public key of a CA (whether as a
key or an assumed certificate), and chain through a set of certificates to
ascertain the goodness of the certificate in question.  Once that is
accomplished I can "trust" that the name in the certificate (and ancillary
data) is bound to any data with a signature that is verified by the
certificate's public key.

The problem that Wes and I discussed involved entering an SSH host key into
a certificate.  Who signs the certificate?  Would it be self-signed?  Would
it be signed by the administrator of the machine?  Would it be signed by a
site-wide adminitistrator?  Ultimately, how would I, as an arbitrary user
come to trust the SSH key certificate - in a way that is less cumbersome
than configuring the public key in my client?

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.

I am aware of the benefits of a CERT (more fields, hence more information)
over a KEY, but that assumes there is a supporting infrastructure.  KEY
already has one - the DNS itself, but what is behind the CERT?

>
>* No requirement on DNSSEC to protect the keys.
>
>  DNSSEC isn't happening now, while applications using public keys
>  (SSH, IPSec, S/MIME, PGP..) is happening.
>

Without CA's, there applications aren't better off than DNS.

>* DNSSEC only guarantee origin authentication.
>
>  This is probably too weak for some applications. I want to trust
>  that a public key belong to a certain host or person.  Only being
>  able to trust the origin of the information is weaker.  Putting a
>  SSH KEY RR in DNS doesn't authenticate that key as belonging to the
>  host (which is what you want) but rather that you trust that the
>  public key came from a certain origin.  Maybe this is subtle and can
>  be ignored for SSH or IPSEC (where you could assume that if it came
>  from the domain where the machine lives in you trust it as belonging
>  to the host). But I wouldn't trust a key for S/MIME or PGP purposes
>  based only on the fact that I know where the key came from (how do I
>  know they checked the identity of the user before signing his public
>  key?).

If SRV naming is used, then the key can be tied to a host via the domain
name, which is covered by the SIG RR.  For identity of folks, there is a
email-address convention defined (replace the @ with .).

>
>* Key revocation.
>
>  Keys used by several applications have different requirements than
>  DNSSEC KEY's, several applications need revocation functionality.

This is true, KEY can't do that but CERT can.

>* Reuse of trust infrastructure in applications.
>
>  Today applications usually trust some predefined set of CAs.
>  Changing the trust infrastructure in the application to support the
>  DNSSEC way is more difficult than retrieving keys signed by the CAs
>  using DNS.  (And I don't see any advantages of doing the change,
>  only some disadvantages, like giving up revocation.)

What are the predefined set of CA's?  That's what isn't obvious.

What applications are you referring to?  Netscape is shipped with
certificates signed by Verisign.  I don't know of an SSH that uses
certificates.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.



Home | Date list | Subject list