...
It was suggested that I could use one of the two <id> forms that don't require a <keyid>, which are <id-publickey> and <id-issuer>. But since the TIS PCA has no issuer, I can't use <id-issuer>. This will be the same problem for any entity at the "top" of a chain.
The TIS PCA certificate is currently self-signed, so its issuer distinguished name is the same as its subject distinguished name. This should be true for any top-level authority, so <id-issuer> will still work.
And using <id-publickey> requires the CRL database to be indexed by public key instead of disinguished name as most are. So, using one of the other <id> forms which still have the unknown <keyid> may still be necessary.
If you buy into any of the new naming models it becomes necessary to index certificates by more than just subject name and/or issuer name/serial number as done previously. Using the public key as the index is useful since it is the only truly cryptographically-necessary information. This allows the trust and certificate/CRL retrieval models to be separated from the low-level mechanics of verifying a signature or decrypting a message. With a pubic key, I can *do something* even if the level of trust is unknown. Besides, for a CRL to be useful, I must have the associated certificate, which must have a public key.
I bring up this example to highlight the implementation difficulties
of keeping track of an arbitrary keyid. Nonetheless, we do need a way
to distinguish among the public keys that an entity may use. The
previous draft, draft-ietf-pem-mime-05.txt, used fields like this:
<id-email> ::= "EN" "," <atstring>
"," <hashalgid> "," <hashpublickey>
<id-string> ::= "STR" "," <string>
"," <hashalgid> "," <hashpublickey>
<id-dname> ::= "DN" "," <dname>
"," <hashalgid> "," <hashpublickey>
This is basically what we have in the current draft except a public
key hash was used instead of the present keyid. It had the advantage
that the key identifier was not arbitrary and could be derived
directly from the public key. There was no need for a database to
seperately store the keyid or for a user to have to convey it.
However, this scheme was abandoned because not all applications would
be willing to implement the hash algorithm that a sender might use
such as MD5 or SHA.
One problem with the above, as you stated, is choosing the hash algorithm. It could be chosen on a per-certificate basis based on the signature algorithm being used, but not everyone will implement all signature algorithms. It would be nice to be able to index a certificate even if it can't be used immediately. Since the hash of the public key is merely hinting at the certificate to be used and not trusted information, any hash algoritm can be used. MD5 could be used universally and even if it were possible to produce collisions, it wouldn't matter, except that folks might get bad connotations if the standard used a "broken" hash.
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). 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. 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. Mark
binB0R8kQYXNB.bin
Description: application/signature