Jeff,
I've read the exchanges generated by your question about how
one indexes a database via keyid for various name forms as propose din
the MIME-PEM draft. The response was interesting in part because it
discussed various groups that argued about the relative merits of
different approaches, yet I don't recall seeing any of that discussion
on PEM-DEV. Nonetheless, the points you raised were good ones and I
do think that a more open discussion of key identifiers is
appropriate. I agree with the observation that if there is a traffic
analsyis motivation behind some aspects of this design, then this
should become an explicit requirement for MIME-PEM, even though it was
explicitly not a requirement for PEM in any of the previous RFCs.
Also, I concurr with the observation that not placing public keys in
messages headers, to avoid possible (cryptographic) weaknesses is a
bad idea, as it suggests use of algorithms that are probably not
suitable in the first place.
A better rationale for the complex set of key id options now
in the draft might be an argument about the size of key ids in terms
of header size. However, that argument has not been put forth
explciitly. Also, the PEM WG notes point out that the requirements
for originator and recipient key ids are different, and that might
argue against adopting a uniform approach to selecting such ids,
across the various "name forms" cited in the I-D, especially since the
syntactic uniformity exists primarily at the top level and then
diverges for various specific name forms.
Finally, the question of compliance is an appropriate one.
With the greater diversity of ID options present in this I-D
(vs. 1421) it is natural to ask whether a compliant implementation
must support all of these forms, and thus have database searching
capabilities appropriate for each, or if compliance is achieved by
supporting any one form, or is there a default form? Different
answers have implications for implementation complexity and size, and
for interoperability.
Steve