On Mon, 27 Jul 2015 14:43, paul(_at_)nohats(_dot_)ca said:
Then you really need better tools that filter out bogus and older keys,
if this has to work for average users. One of my old keys uses idea
NO! There a no bogus keys. It is a desirable feature that you can't
remove the keys. If you want to revoke a key or user id you upload a
copy of the key with the revocation certificiate.
right. But at least with DNSSEC, at this moment, you know that no one
can publish OPENPGPKEY records for paul(_at_)nohats(_dot_)ca except those who
run
nohats.ca. That's already a lot more pinned down then the current key
Right and it is a Good Thing. I proposed that 9 years ago [1].
There might be 100 of those, but those using the tools can't just let
the tools find them, so if I'm on the wrong side of the Great Firewall,
the only names I know of servers to use would be pgp.mit.edu,
The example from gpg's conf file template is hkp://keys.gnupg.net which
is just a CNAME for the mentioned pool.sks-keyservers.net.
[paul@thinkpad ~]$ gpg --recv-key 0x12345678
gpg: requesting key 0x12345678 from hkp server search.keyserver.net
keyserver.net is a proprietary keyserver services from a Belgian(?)
company. I was not aware that this server still exists; it is/was also
not synced with the regular keyserver network.
three key servers. Until today, I had not even heard of
sks-keyservers.net, and I'm probably a long term, better than average
SKS has replaced Marc's keyserver ~12 years ago. Bascially all sites
are using it and perhabs keys.pgp.mit was the last to switch a few years
ago. The old commonly pool used to be subkeys.pgp.net. For some time
keys.gnupg.net ran its own pool but eventually it switched to the well
maintained sks-keyservers.net pool.
Note that I checked enigmail and it does seem use pool.sks-keyservers.net
(also, apparently it had two different keys with ID 0x12345678)
Always use the long keyid - there are less duplicates. And of course
using the fingerprint is the canonical right way of specifiying keys.
I know John Gilmore also had additional patches for gnupg to assist
with keyring discovery in the same LAN, aimed at keysigning parties, but
those patches were apparently reject and he has given up on this project.
We talked about that but he did not send any patches and iirc he gave up
on this. gpg's new --quick-* commands have been implemented on his
request.
you cannot use --recv-key 0x12345678 --keyserver pool.sks-keyservers.net
(the order matters)
gpg's requires that option come before other arguments (classic Unix
style, partly done this way for compatibility with pgp 2). Thus the
above is equivalent to
gpg --recv-key -- 0x12345678 --keyserver pool.sks-keyservers.net
and --keyserver is thus not considered an option.
I'm not smart enough to remember if it is --keyserver or --key-server or
$ gpg --dump-options | grep keyserv
--keyserver
--keyserver-options
--sig-keyserver-url
--default-keyserver-url
Shalom-Salam,
Werner
[1] W. Koch, “Public key association,” in GUUG Frühjahrsfachgespräche 2006:
Proceedings. Köln, Germany: GUUG, 2006, pp. 159–167.
[Online]. Available: http://g10code.com/docs/pka-intro.de.pdf
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp