GNUPG and PKI compatibility (?)

[John Clizbe]

gerry_lowry (alliston ontario canada) wrote:
> These may be some keyservers to use for looking up keys with "gpg --recv-key"
>     keyserver hkp://subkeys.pgp.net 
>     keyserver hkp://pgp.mit.edu 
>     keyserver hkp://pool.sks-keyservers.net (random server) 
>     keyserver hkp://keys.nayr.net 

An "interesting" assortment, but the only one I'd keep is pool.sks-keyservers.net.

Here's why:

subkeys.pgp.net: The original purpose of subkeys.pgp.net was to be a set of
subkey safe keyservers, PKS servers that were patched to not mangle V4 keys and
a few of the new SKS servers. Most all maintained PKS boxes have converted to SKS.

The current collection is a subset of the SKS network: sks.gpg.cz,
keys.nayr.net, keyserver.ganneff.de, keyserver.maluska.de, keys.cardboard.net,
and  keys.keysigning.org. pool.sks-keyservers.net gives me all of these servers
and more. BTW, this is also a DNS round robin... you get a random server of the
six. Any of these are likely to be included in pool.sks-keyservers.net.

keys.nayr.net: It is, in general, very poor netiquette to steer traffic to a
single server when load-balancing mechanisms are well-known and available. The
more widely distributed that traffic balancing is, the better for all concerned.
If, for some reason, that single server is down, a user's keyserver operation
will fail. The pooled round-robins minimize this risk. This server is also part
of subkeys.pgp.net and ~50% likely to be part of pool.sks-keyservers.net.

pool.sks-keyservers.net: The *BEST*CHOICE* of this bunch. it is a DNS
round-robin consisting of 20 SKS servers that a) are up, and b) are synchronized
with the rest of the SKS network. 20 randomly chosen from 40-50 that normally
make up the greater pool of SKS servers and the list is updated twice per day.

The win is the b) part - because of the manner changes are distributed in the
SKS network, all servers have nearly or soon to be (within minutes) identical
copies of the entire database. I find that most times, my keyserver's 25+ recon
partners have zero differences from my copy of the database. Said another way,
outside of networking issues such as RTT (round trip time),
		NO SKS SERVER IS ANY BETTER THAN ANOTHER.

Sharing the load among all servers is the best approach for all - server
operators and users.

pgp.mit.edu: Bad, Bad, Bad, Bad idea. Perennial favorite for worst
recommendation of keyserver.

As a friend of mine said on this list two days ago, "Friends don't let friends
use pgp.mit.edu.  It is irreparably broken for modern OpenPGP keys."

"How is it broken?" you may ask. PKS does not handle V4 key features well.
Notable examples of mangled features are multiple subkeys, a revoked subkey (tag
0x28), duplicate keyids, direct key signatures (tag 0x1F), revocation signatures
on userids (tag 0x30), or photo IDs.

There is also no development or maintenance being done on the PKS platform.

Please do not recommend this server.

> Not all of the above may be up.

Your chances of a server not being up increase as the size of your pool of
servers decrease. Single server -> greatest odds of hitting a failure.

If they're listed as part of pool.sks-keyservers.net, they will most likely be
up (or were up within the last 12 hours or so)

Note: this list looks like a selection of keyserver directives from a GnuPG
configuration file, gpg.conf. Unless David or Werner changed the logic and I
missed the commit, only the last uncommented keyserver directive will be used by
GnuPG. There is no iteration over a list of keyservers alá PGP. You get one
active keyserver statement, hence pool.sks-keyservers.net being the best
recommendation.

-- 
John P. Clizbe                      Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-keys at gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 680 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090205/c3f6433b/attachment.pgp>