I suggest solving this by using the checksum defined by the TCP/IP
protocol as the keyid. It is easy to implement and all applications
implicitly use it already. It does not need to be irreversible like
MD5 or SHA. All we need is to distinguish among the few possible
public keys that an entity may use. Therefore, for example,
<id-email> for me would look like:
Originator-ID: EN, 1FF3, jefft(_at_)netcom(_dot_)com
where 1FF3 is the hex-encoded 16-bit checksum of the DER encoding of
my public key. The recipient of my message may look up however many
public keys in the database for jefft(_at_)netcom(_dot_)com, compute the
checksum
on the public key encodings and select the one that matches. Best of
all, there is no need to convey or store a seperate arbitrary keyid.
...
Regardless of what you use as the keyid in the above model, you still
need to index by the various name forms or, at least, have a mapping
from each name form to a distinguished name (indirect indexing).
Can the draft authors speak to this point? Is an implementation
required to process name forms with a keyid in order to be compliant?
If so, what exactly is the recommended database mechanism which will
let me "index by the various name forms" and how is it supposed to be
secured/authenticated? If the keyid is not required, then as Mark
very eloquently explains below, just using the public key will
suffice. The keyid arose only to keep public keys private for various
reasons.
Also, a problem with a 16-bit checksum is the relatively high
probability of a collision. While, as you said, irreversibility is
not a problem, collisions are. A 32-bit CRC would be better and MD5
or SHA would be better than that.
I agree. The TCP/IP style checksum can easily be exteneded to 32 bits
or more. As I understand it, using MD5 or SHA was abandoned for
political reasons for people who didn't want anything to do with the
other's hash algorithm, which is why I proposed something "neutral"
like the checksum.
For complete freedom from collisions, just use the public key. At one
point, <keyid> was called <pk> going to be the public key in all name
forms. Public keys aren't all that big, aren't too bothersome at the
end of the message, and can be used, to some extent, immediately.
Nothing to derive. No ambiguity. Nothing arbitrary. Something that
everyone must have.
A strong objection was raised by one camp to using <pk> in all name
forms on, I believe, two grounds. First, privacy of the public key.
It was claimed that key exchange might take place out-of-band between
individuals and making public keys available to snooping adversaries
provides a potential weakness. Second, I believe that traffic
analysis may have been a concern, but I may not be remembering that
correctly.
In response to the above objections, if a snooping adversary is a
concern, use a bigger key. If traffic analysis is a concern, which
has never been addressed by PEM, use trusted, encrypting, re-mailers.
The current draft is compromise that allows individuals to keep their
public keys hidden and still uniquely identify the keys/certificates
to use.
I summary: If my application doesn't implement keyid and is still
considered MIME/PEM compliant, I will use the public key and be
merrily on my way. If it is required, I propose using the checksum
which is non arbitrary and does not need a seperate machanism for
keeping track of it.
- Jeff