Re: Definitions of keys and certs

[Greg Hudson <ghudson@MIT.EDU>]

On Mon, 2002-01-07 at 16:23, Paul Hoffman / IMC wrote:
> A bare public key that you will only trust if you trust a public key 
> that has signed it is not a public key: it is a part of a 
> certificate. DNSSEC "keys" are in fact not keys, they are a part of a 
> certificate.

Questionable.  As Derek said, a "certificate" is a <key, signature>
pair, and that's not really the way the "bare public key" crowd is
thinking about things.  From our perspective, DNSSEC is just a method of
securely advertising DNS data, whether it's an A record or an
application key.  For some small-scale situations, TSIG or a firewall
would do just as well.

Yes, you can look at the process of fetching an application key through
DNSSEC as very similar to the process of verifying a certificate, but
that's not the only way of looking at it.

> A bare public key that you will trust based on out-of-band 
> information is in fact a public key. SSH public keys usually match 
> that definition.

When does something become "out-of-band?"  If you use automated tools to
retrieve ssh host keys using an SSL connection to a web server before
making ssh connections, then the key has been signed by the web server's
public key, which was in turn signed by a CA.  Does the ssh host key
turn into a certificate?  I don't think it would be helpful to describe
it as such.

Anyway, in practice, whenever I use the word "certificate" in most
technical contexts, people assume I'm talking about X.509 certificates
(similarly, if I use the abbreviation "PKI", people assume I'm talking
about a PKI built on X.509 certificates).  Sometimes it's convenient to
avoid loaded words.