ietf-openpgp
[Top] [All Lists]

Key IDs

1998-04-01 20:46:25
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