same key or RFC misinterpretation?

[David Shaw]

On Wed, Mar 12, 2003 at 03:50:52PM -0500, Jason Harris wrote:

> The pubkey packets (for the first two keys) differ by +1 (0x9f + 1 = 0xa0):
> 
> 9c9
> < 00000080  db a0 94 0d 65 26 4d fd  22 49 4b 00 a0 5f bd c0  |....e&M."IK.._..|
> ---
> > 00000080  db a0 94 0d 65 26 4d fd  22 49 4b 00 9f 5f bd c0  |....e&M."IK.._..|
> 
> which pgpdump says is due to the size of q (must be 0, and in the leading
> bit):
> 
> 6c6
> <       DSA q(160 bits) - 5f bd c0 de a2 b7 2a a3 5a 92 b4 91 7d 53 50 7e 5f a1 d7 9f 
> ---
> >       DSA q(159 bits) - 5f bd c0 de a2 b7 2a a3 5a 92 b4 91 7d 53 50 7e 5f a1 d7 9f 

[..]

> RFC 2440 (bis-06) says:
> 
>   A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet
>   Tag, followed by the two-octet packet length, followed by the entire
>   Public Key packet starting with the version field.  The key ID is
> 
> 
> Which is the correct method?

What you quoted from the RFC is correct, though slightly misleading
since the "one-octet Packet Tag" is always 0x99 regardless of the
actual packet tag.  See
http://www.imc.org/ietf-openpgp/mail-archive/msg05004.html for more on
this.

It's an interesting example, but I don't think it is a bug anywhere.
It looks like you have three copies of the same key, and two of the
three are corrupt.  If a key is corrupt, you'd want and expect the
fingerprint to be different, and any signatures to break (which they
have).  It is interesting that GnuPG's MPI code is capable of handling
one of the corrupt keys.  I haven't looked at exactly why, but MPIs
are not supposed to have leading zeroes, so perhaps the MPI parser in
GnuPG was compensating.

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 243 bytes
Desc: not available
Url : /pipermail/attachments/20030312/8cfd6704/attachment.bin