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