Re: CERTificates and public keys

[Derek Atkins <warlord@MIT.EDU>]

There is absolutely no assumption at all in RFC 2538 that a
certificate is signed.  If there is, please point out the section so I
can go re-read it again.  However, having just read the RFC yet again,
I can see no mention of just a requirement or assumption anywhere in
the draft (well, except when talking specifically about X.509/PKIX
keys).

This means that when you "enter a key into a certificate" you don't
have to worry about who signs it, because quite frankly NOBODY has to
"sign" it.

The main reason, IMHO, to use a CERT record over a KEY record is that
KEY records imply DNSSec keys whereas CERT records imply application
keys.

-derek

Edward Lewis <lewis@tislabs.com> writes:

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

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