That is a limitation of the keyservers.

this is not a limitation of the keyservers; gpg itself is stripping all but the
short keyid. adding "--keyserver-options debug" to the command shows that in
every case, gpg is requesting the following URL:

/pks/lookup?op=get&options=mr&search=0x7028E350

However, direct queries of the keyservers show that longer-form keyIDs or full
fingerprints are capable of limiting the number of keys returned.

0 dkg@pip:$ wget -q -O-
'http://pgp.mit.edu:11371/pks/lookup?op=get&options=mr&search=0x7028E350' | gpg
--list-packets | grep -c '^:public key packet:'
2
0 dkg@pip:$ wget -q -O-
'http://pgp.mit.edu:11371/pks/lookup?op=get&options=mr&search=0x72236E167028E350' |
gpg --list-packets | grep -c '^:public key packet:'
1
0 dkg@pip:$ wget -q -O-
'http://pgp.mit.edu:11371/pks/lookup?op=get&options=mr&search=0x137D009EB55B362E7D1A89BB72236E167028E350'

1
0 dkg@pip:$

Indeed, the hkp I-D suggests [0]:

Key ID
strings may be 8 digits (32-bit key ID), 16 digits (64-bit key ID),
32 digits (version 3 fingerprint), or 40 digits (version 4
fingerprint).

[0] https://tools.ietf.org/html/draft-shaw-openpgp-hkp-00#section-3.1.1.1

I believe the problem is around line 276 of keyserver/gpgkeys_hkp.c, which is
where the truncation happens.

It may be that these days keyservers can cope with long keyids. However old
keyservers are not able to do that.

Given that the referenced draft was written in 2003, we now have 8 years of
documented expectations that keyservers can do this. The dominant keyserver
implementation today (SKS) can handle this with no trouble.

All the responsive keyservers in keys.gnupg.net, pool.sks-keyservers.net, and
subkeys.pgp.net are capable of using longer keyIDs.

Perhaps gpg can now drop the truncation? It's trivial to craft a key matching a
specific short Key ID. The fewer places gpg implicitly suggests uniqueness, the
better.

D149: 332_1340.diff

Attached is a proposed patch that should permit passing long keyIDs or full
fingerprints to the keyservers.

I think this is fine. I originally wrote the code to send short keyids as pksd
couldn't properly handle long keyids or fingerprints. As pksd is now dead, and
sks properly handles this, I think it is reasonable to send the longest ID
appropriate (send fingerprints if we have them, long keyids if we have them, and
short keyids if we must).

I tested this patch, and it does in fact change the behavior as requested.

Thanks to dkg for writing the patch.

werner, in my limited role as a random enthusiast in the community, I think this
patch in GnuPG. Let me know if there's anything else I can do to help that happen.

Can i get an update on where this patch stands? I'm concerned that people are
actively sniffing around the idea of crafting duplicate short keyids:

http://seclists.org/fulldisclosure/2011/Sep/207

They are trivial to create, alas. The search space is so small, i can exhaust
it in a couple of hours on a crappy 3-year-old netbook.

It would be really great to have gpg avoid using the short keyid wherever
possible, particularly when dealing with data from sketchy sources like the network.

We don't have any plans for a new release.