Re: [Sks-devel] does merge works correctly on SKS

[Pramberger Peter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Verifying your key at http://www.pgpdump.net/ shows two identical
signatures with different length:

Signature Packet(tag 2)(87 bytes)
- - Ver 4 new Sig
- - Positive certification of a User ID and Public Key packet(0x13).
- - Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0xEA9C66EAB9F8D6D9

Signature Packet(tag 2)(95 bytes)
- - Ver 4 new Sig
- - Positive certification of a User ID and Public Key packet(0x13).
- - Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0xEA9C66EAB9F8D6D9

Maybe a merge with data from an older keyserver (PKS) where something
went wrong?

Do you remember when you last changed your key and on which keyserver?

I had a similar problem with my last key (455705C3). At some day there
was a second user attribute identical to the first on my key. However
the data was too short compared to the given length therefore import
failed on gpg with an error.


Peter


Roman Pavlik schrieb:
> Hi,
> I today noticed, that there are two selsign on my key 0xB9F8D6D9 
> on sks keyservers. My PGP key have of course only ony selfsig
> pakets:
> 
> :public key packet:
>       version 4, algo 17, created 990764448, expires 0
>       pkey[0]: [1024 bits]
>       pkey[1]: [160 bits]
>       pkey[2]: [1023 bits]
>       pkey[3]: [1022 bits]
> :user ID packet: "Roman Pavlik <address@hidden>"
> :signature packet: algo 17, keyid EA9C66EAB9F8D6D9
>       version 4, created 1017556599, md5len 0, sigclass 13
>       digest algo 2, begin of digest 0d 5b
>       hashed subpkt 2 len 4 (sig created 2002-03-31)
>       hashed subpkt 11 len 4 (pref-sym-algos: 7 10 3 4)
>       hashed subpkt 21 len 2 (pref-hash-algos: 3 2)
>       hashed subpkt 22 len 2 (pref-zip-algos: 2 1)
>       hashed subpkt 23 len 1 (key server preferences: 80)
>       subpkt 16 len 8 (issuer key ID EA9C66EAB9F8D6D9)
>       subpkt 101 len 6 (experimental / private subpacket)
>       data: [160 bits]
>       data: [157 bits]
> 
> But PGP key from server differ:
> :public key packet:
>       version 4, algo 17, created 990764448, expires 0
>       pkey[0]: [1024 bits]
>       pkey[1]: [160 bits]
>       pkey[2]: [1023 bits]
>       pkey[3]: [1022 bits]
> :user ID packet: "Roman Pavlik <address@hidden>"
> :signature packet: algo 17, keyid EA9C66EAB9F8D6D9
>       version 4, created 1017556599, md5len 0, sigclass 13
>       digest algo 2, begin of digest 0d 5b
>       hashed subpkt 2 len 4 (sig created 2002-03-31)
>       hashed subpkt 11 len 4 (pref-sym-algos: 7 10 3 4)
>       hashed subpkt 21 len 2 (pref-hash-algos: 3 2)
>       hashed subpkt 22 len 2 (pref-zip-algos: 2 1)
>       hashed subpkt 23 len 1 (key server preferences: 80)
>       subpkt 16 len 8 (issuer key ID EA9C66EAB9F8D6D9)
>       data: [160 bits]
>       data: [157 bits]
> :signature packet: algo 17, keyid EA9C66EAB9F8D6D9
>       version 4, created 1017556599, md5len 0, sigclass 13
>       digest algo 2, begin of digest 0d 5b
>       hashed subpkt 2 len 4 (sig created 2002-03-31)
>       hashed subpkt 11 len 4 (pref-sym-algos: 7 10 3 4)
>       hashed subpkt 21 len 2 (pref-hash-algos: 3 2)
>       hashed subpkt 22 len 2 (pref-zip-algos: 2 1)
>       hashed subpkt 23 len 1 (key server preferences: 80)
>       subpkt 16 len 8 (issuer key ID EA9C66EAB9F8D6D9)
>       subpkt 101 len 6 (experimental / private subpacket)
>       data: [160 bits]
>       data: [157 bits]
> 
> Why there are two signature packets with the same keyid on the SKS?
> Only answer I can find is that merge doesn't work correctly. 
> Any (other) idea?
> 
> --
> R.
> 
> 
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/sks-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFATvWpcKsx5K5ighwRAtQYAJ9AA2oL6S2ymQ8m1AO9S6Ku2GpZNACfYInf
FAYKzP+usoopw+mY3KdhVls=
=c/1w
-----END PGP SIGNATURE-----