Jon announced at IETF that he's about ready to go to a penultimate
call on op-fmts.txt, so I'd better get a few suggestions into the
hopper.
Here's a cluster of Key ID comments and questions.
- v3 Key ID and Fingerprint are handled in 5.5.2
v4 Key ID and Fingerprint are handled in 11.2
I suggest they ought to be discussed in the same place, or that
the v3 and v4 discussions be more parallel. I understand that the
current structure is the result of handling it from a historical
or archaeological viewpoint, but I think a functional breakdown
makes more sense.
- 11.2 says a Key ID may be 32 or 64 bits, but doesn't say when
each is meaningful. From a formats point of view I think we
always use 64 bits for the Key ID, and truncating it for display
to 32 bits is a user interface issue, so we may as well say flat
out that it's a 64 bit quantity.
- 5.5.2 alludes to the 0xDEADBEEF problem with respect to v3 keys.
Geoff Keating posted a message Monday in
comp.security.pgp.tech entitled "Two different DSA keys with
identical key IDs", but I haven't been able to confirm them:
pgpk -a goes haring off to the Netherlands to try to install
them (I didn't realize PGP had a browser built in!). Doing the
fingerprinting "by hand" results in different IDs than the ones
shown in his message -- at least for me. If somebody else can
confirm his result, the v4 key explanation might need to include
a similar caveat.
Also, this discussion seems awkward. I suggest replacing
Since the release of V3 keys, there have been a number of
improvements desired in the key format. For example, if
the key ID is a function of the public modulus, it is easy
for a person to create a key that has the same key ID as
some existing key. Similarly, MD5 is no longer the preferred
hash algorithm, and not hashing the length of an MPI with its
body increases the chances of a fingerprint collision.
with something along the lines of
V3 keys SHOULD be used only for backward compatibility because
of three weaknesses. First, they are subject to a Key ID
spoofing attack: a key can easily be constructed with an ID
matching the ID of any target key. Second, the fingerprint of
a key may often be made to match the fingerprint of a target
key by taking advantage of the fact that MPI lengths are
not included in the hash. Finally, the MD5 algorithm used in
V3 keys has begun to come under mild suspicion.
- Should we offer any more specific advice than in 3.3 about when
an implementation SHOULD NOT assume the Key ID is unique? Like
"if the signature doesn't match, see if you have another such
Key ID"? Or is even the mention in 3.3 beyond the scope of a
formats document?
--
Jim Gillogly
Trewesday, 11 Astron S.R. 1998, 01:25
12.19.5.1.0, 6 Ahau 18 Cumku, Second Lord of Night