Re: Definitions of keys and certs

[Paul Hoffman / IMC <phoffman@imc.org>]

At 12:24 AM -0500 1/8/02, Greg Hudson wrote:
>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.

I didn't say it was the only way to look at it. There are exactly two 
trust scenarios:
- you trust a key because another key that you trust has signed it
- you trust a key based on out-of-band trust data

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

When the trust of the key requires something other than its currently 
trusted keys. That is, each time you trust a key based on information 
other than in your current hierarchy/web of trust, you have to make 
that trust using some out-of-band decision.

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

Exactly right.

>   Does the ssh host key
>turn into a certificate?

Yes. Your trust of the SSH key is based on your trust of the web 
server certificate.

>   I don't think it would be helpful to describe
>it as such.

I do. Otherwise, typical users will not understand why any particular 
thing is trusted. Worse yet, they will end up trusting something that 
they would not normally trust because the trust chain is being hidden 
from them. Others may disagree with my desire for precision here.

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

Sometimes that avoidance leads to handwaving over important 
information. I claim that is the case with almost everything having 
to do with certificates today.

--Paul Hoffman, Director
--Internet Mail Consortium