keyserver scheme http broken?

[David Shaw]

On Nov 12, 2009, at 3:19 PM, Bernhard Reiter wrote:

>> There isn't really a *http* keyserver (in the sense of
>> being a database of many keys that can be queried).  If you specify a
>> http URL with the --keyserver command, you're really describing a the
>> path to a particular file to fetch.  It's not really indended for  
>> that
>> use, and you can't --search-keys or --recv-keys a web server.
>
> http://gpg4win.de/doc/gpg4win-compendium-de_21.html at least is  
> confusing
> on this part (and I think Werner read over it as well). It makes the  
> reader
> believer that http://keyserver.pramberger.at and http://gpg-keyserver.de
> could be viable "keyserver" for use with --keyserver.
> We (as in the Gpg4win Team, especially Emanuel) must change that.

The rule of thumb is that things that you can use with --keyserver are  
protocols where you can tell it which key you want (like hkp, ldap, or  
mailto)  http can't do this, as there is no standard way to specify  
the key ID (the path to the key could be different on my web server  
compared to yours).

It also doesn't help that the PGP product calls them "http keyservers" !

> http://keystats.gnupg.net/ did not put that idea to rest, neither did
> the --keyserver section of gpg.texi. Na, now I know. The different  
> port can be
> a problem for enterprise firewalls, though.

Some keyservers run hkp over port 80 to deal with firewalls (so it's  
hkp://keyserver.example.com:80 in those cases).   I'm not sure why  
11371 was chosen instead of 80.  It was set a long time ago.  It might  
be something as simple as they needed a port >1024 so non-root could  
bind it, but I don't really know.

Incidentally, newer (1.4.10 + 2.0.13) versions of GPG can use DNS  
service discovery to detect the port number for hkp automatically.

I'll take a look at gpg.texi and see if I can make this a bit clearer.

David