On Mon, 27 Jul 2015 14:43, [email protected] 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 [email protected] 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. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
