Key strangeness

[David Shaw]

On Tue, Dec 14, 2004 at 01:09:54PM -0500, Jason Harris wrote:
> On Sun, Feb 08, 2004 at 10:46:58AM -0500, David Shaw wrote:
> 
> > A bug in his software (CryptoEx) would explain nearly everything
> > here.  Since CryptoEx naturally would be compatible with itself, it
> > would see the keyid as 3A546EC2.  It would fill in 3A546EC2 as the
> > issuer of signatures, and it would be able to verify its own
> > signatures so the key would be valid.
> > 
> > That theory doesn't explain why the keyservers indexed the key as
> > 3A546EC2 though.  GnuPG, PGP 6 and 8, and my local copy of pksd all
> > agree the keyid is 7EDB7A47.

[..]

> 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
fact, there was an old PKS bug from exactly that problem.

This problem is a little different in that it is the MPI that causes
the problem, which is inside the pubkey packet itself and not a
header.  This is not a RFC compliance issue because the RFC forbids
leading zeroes in an MPI, period.  Since this key has leading zeroes,
it is a broken, non-RFC compliant key.  Any behavior is legal,
RFC-wise at this point, including discarding the bad key completely.

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.

Of course, you're responding to a post from over 10 months ago.  This
may well have been resolved since then.

David