Key strangeness

Jason Harris jharris at
Wed Dec 15 01:17:48 CET 2004

On Tue, Dec 14, 2004 at 04:12:22PM -0500, David Shaw wrote:
> On Tue, Dec 14, 2004 at 01:09:54PM -0500, Jason Harris wrote:

> > The keyservers (pks, and apparently SKS) hash the pubkey packet
> > exactly as it appears.  Certain encryption clients deconstruct the
> > packet, normalize the MPIs, and hash the new components instead of
> > the original pubkey packet.  With a zero-padded MPI, which is
> > non-RFC-compliant, the non-RFC-compliant behavior of hashing
> > something other than the original pubkey packet breaks the
> > fingerprint (and therefore keyid) calculation, which causes further
> > breakage.
> Hashing a canonicalized pubkey packet is perfectly RFC compliant, and
> in some cases is required.  You must never hash the original pubkey
> packet with header, or you get problems, for example from a public key
> with a 1-octet length encoding versus a 2-octet length encoding.  In

Specifically (albeit from draft-ietf-openpgp-rfc2440bis-12.txt):

   A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
   followed by the two-octet packet length, followed by the entire
   Public Key packet starting with the version field.  The key ID is

Not "the entire Public Key packet starting with the version field,
with whatever fixes you have to make so the key is fully RFC-compliant."

> That said, since it seems GnuPG, PGP, (and PKS?) all resolve the issue
> one way (canonicalize the MPI) and SKS does it the other way, it might
> be nice to get SKS to canonicalize.  But this is not an RFC
> requirement.  The SKS behavior is not incorrect here.

The mentioned keyservers are in agreement and hash "the entire Public Key
packet starting with the version field."  This is why they calculate
different fingerprints for pubkey packets that have different bit sequences.

Whether keyservers should store keys with zero-padded MPIs is debatable,
but it is clear to me that encryption clients should not accept, modify,
and propagate such keys.

Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
jharris at _|_ web:
          Got photons?   (TM), (C) 2004
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : /pipermail/attachments/20041214/fb834218/attachment.bin

More information about the Gnupg-users mailing list