[Sks-devel] Re: Key strangeness

[Yaron Minsky]

Ah, that explains why I couldn't find it.  Does this problem come up with
PKS, or is it SKS specific?  Is one possibility here that the lead packet
is malformed, and as a result some difference in implementation of rfc2440
results in differently evaluated keyids?  i.e., maybe SKS things that this
key really does have keyid 3A546EC2, and GPG thinks it has a different
one, basically because the key packet is malformed.

Anyway, I'm away from my home computer so I can't really look into this
right this second, so if this doesn't resolve itself, I'll track it down
in a few days.

Yaron

David Shaw said:
> On Sun, Feb 08, 2004 at 01:20:37PM -0500, Yaron Minsky wrote:
>> Hmmm.  I am confused.  When I query 0x3A546EC2, I get the right key.
>> Again, this is from sks.dnsalias.net.  Here's the URL I tried:
>>
>> http://sks.dnsalias.net:11371/pks/lookup?search=0x3A546EC2&op=vindex
>>
>> Any examples of keyserver weirdness would be more useful if they were
>> accompanied by the actual URLs that elicited the odd behavior.
>
> vindex or index does not show the problem.  The actual keyblock
> returned by SKS is the problem.  Try:
>
>     http://sks.dnsalias.net:11371/pks/lookup?search=0x3A546EC2&op=get
>
> Import that armored key into GnuPG or PGP, or even re-submit it to
> SKS.  That key is 0x7EDB7A47.
>
> David
>


|--------/            Yaron M. Minsky              \--------|
|--------\ http://www.cs.cornell.edu/home/yminsky/ /--------|

Open PGP --- KeyID B1FFD916
Fingerprint: 5BF6 83E1 0CE3 1043 95D8 F8D5 9F12 B3A9 B1FF D916