Key IDs

[Jim Gillogly <jim@xxxxxxx>]

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