Re: CERTificates and public keys

[Simon Josefsson <jas@extundo.com>]

On Thu, 30 Aug 2001, Edward Lewis wrote:

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

This is the standard PKI problem, as I see it.  You need to trust someone
to make (good) decisions of what you should trust or not.

There is no single trust point that can make that decision for everyone.
Every user will have to decide which root public key they trust. Once they trust
one key, the host/user key will have to be signed by that trusted key
(possibly via some level of indirection).  If this isn't the case, the end
user simply can't trust that the key belong to the host/user.

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

I certainly would never trust a signature chain leading to the "." DNSSEC
public key to certify a public key belonging to a host or user (e.g.
john.smith.somecompany.com).  DNSSEC isn't intended for that, and this is
why I need CERT.  OTOH, if I knew e.g. the "pdc.kth.se" administrators to
only put proper host/user keys and protect them with a DNSSEC key, I could
trust the "pdc.kth.se" KEY for host/user KEY's within that domain, but
that's it, it doesn't scale very well.

Ok, you could create a zone, say, "level3.verisign.com" and then VeriSign
could populate the zone with only level 3 public key's.  Then by trusting
the KEY for level3.verisign.com you have a useful PKI.  But I'm not sure
DNSSEC was intended for this, I hear people saying DNSSEC is not and
should not be a PKI and I agree.

(NB, using DNS to distribute certificates doesn't make DNS a PKI.)

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

Yup, this is the hard problem.  However, PKIs exist outside DNSSEC (believe
it or not :-)) hence in some cases, the supporting infrastructure is
already there.

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

Right, but with CA's they are better off than even with DNSSEC.  And there
are CA's, some are supposedly even making money from being one.

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

There is still no secure connection between the owner of public key and
the signed KEY record.  DNSSEC doesn't offer that.  In a X.509 world, you
select a certain CA root key which offers the kind of protection you
need -- e.g. the trusted third party promises to some level of protection,
ranging from checking that the certified email address exist (by sending a
challenge to the email address) to demanding presentation of physical I.D.
of the person they certify the key to.

So DNSSEC KEY's and CERT's serve very different purposes, and they don't
even overlap much as I see it.

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

The applications I think about are e.g. TLS, S/MIME or PGP based ones.
They mostly already have the infrastructure ready.  I think IPSEC could
fall into this category as well (there are IPSEC implementations using
X.509 certificates), but I don't know much about IPSEC.