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

key identifiers




In the examples I've used so far, the key identifier was just the key ID
and hash.  Various people have commented to me, months ago, that there's
a psychological need to have a name as part of a key ID -- even if it's
totally superfluous from a security point of view -- to give the key owner
a warm, fuzzy feeling that he hasn't been reduced to a number.

We need the hash of the key and a pointer to it -- or the key itself.  In the
interest of saving space, I prefer the hash+pointer, but there might be
offline interpreters of certs who would need the key supplied as well.

Keys could be supplied prior to the cert, for such cases, and be put into
a cache of fetched keys.  The application checking certs could check its
cache of keys for those matching the hash in the cert -- and, if it's there,
not bother fetching the key again.

This leaves a key identifier with 3 fields: [name],hash,URL

Let me propose the following key identifier format, for example:

Certifying-key: "Carl Ellison",
  61E2DE7FCB9D7984E9C8048BA63221A2,
  http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0x7362BE39

or

Signed-key: "Elrod, the fatigued",
    61E2DE7FCB9D7984E9C8048BA63221A2,ftp://ftp.clark.net/pub/cme/cme.asc

 - Carl

+--------------------------------------------------------------------------+
|Carl M. Ellison          cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc., Suite 430                   http://www.cybercash.com/    |
|2100 Reston Parkway           PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Reston, VA 22091      Tel: (703) 620-4200                                 |
+--------------------------------------------------------------------------+