GnuPG 1.2.4 fetches revoked key

David Shaw dshaw at
Tue May 18 17:21:14 CEST 2004

On Tue, May 18, 2004 at 01:59:09AM +0200, Malte Gell wrote:
> As Atom recently described it I transformed my former key 0x00FCC016 
> into a subkey, now with 0xABBA7881 being the new primary key id. After 
> that I revoked the old key.
> Now, SKS keyservers are able to find the primary key id if a message was 
> signed with a subkey. The strange thing is now that gpg 1.2.4 fetches 
> the old revoked key as well, "include-revoked" is NOT set or used.
> This is confusing people who automatically fetch keys not in their 
> keyring and wonder why the message seem to be signed with a revoked 
> key...
> Of course, this is a "special case" if someone transforms a key into a 
> subkey, nevertheless, GnuPG should not fetch a revoked key until told 
> to do so, right? Is this a situation gpg is not aware of, or is it the 
> SKS keyserver that shouldn't have sent the revoked key?

There is no problem here.  By manipulating a primary key into a
subkey, you create two keys with the same keyid.  SKS is doing the
right thing in giving you both since it has no way to tell which one
you really want (in any event, the key material is identical).
On the GnuPG side, "include-revoked" and "include-disabled" only apply
to --search-keys.  When you use --recv-keys, any key that matches the
specified keyid is retrieved.


More information about the Gnupg-users mailing list