keyserver scheme http broken?
dshaw at jabberwocky.com
Fri Nov 13 05:12:30 CET 2009
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
>> 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
> on this part (and I think Werner read over it as well). It makes the
> 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.
More information about the Gnupg-devel