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.
Thanks for the comments. I waited a couple of days for other people
to respond, but I wonder why there doesn't seem to be the interest.
I'd be interested in comments from other people who are thinking
towards trying to implement this stuff.
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.
I know that in a least one conversation with the TIS folks, header
size was explicitly stated as not a factor in choosing the right
approach. Barring comments to the contrary, let's assume this is the
case.
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.
I think allowing different originator and recipient forms is
reasonable and consistent with how the cryptography is actually
utilized.
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.
If the (beautiful) use of an MD5 digest was rejected simply because
the SHA folks didn't want MD5 in their application, what is going to
happen when more stringent people dicover they have to support PGP
identifiers? What are they going to tell their lawyers? Should it
only be "post PGP 2.6"? Has anyone explicitly addressed this issue?
Also Steve (Kent), I wonder what you think about Sandy Murphy's
comments on the TIS database implementation:
We have eliminated the certificate orientation for the database as
well as the hashing and lookups. We are making the public key itself
the fundamental orientation of the database. We are also going to a
flat ascii file with no hierarchy.
A while back, I suggested making the public key the fundamental
orientation and you pointed out that this is not a good idea since
such a database cannot be distributed. Based on TIS's approach, it
seems that a distributed database is not being kept open as a design
goal. I wonder what your view is on this, Steve?
- Jeff