On 2019-05-26 at 10:43 +0200, Werner Koch wrote: > On Sat, 25 May 2019 14:53, i...@zeromail.org said: > You mean from the left over 5 servers in the default hkps pool: > > pgpkeys.eu 51.38.91.189 AS16276 (UK) > pgpkeys.uk 192.146.137.98 AS57672 (UK) > pgpkeys.co.uk 192.146.137.99 AS57672 (UK) > fks.pgpkeys.eu 46.4.246.179 AS24940 (DE, Hetzner) > keys2.kfwebs.net 37.191.231.105 AS57963 (NO) > > which according to rumours have only two or three different operators?
My old SKS membership file had both pgpkeys.co.uk and pgpkeys.eu maintained by Daniel Austin; the off-by-one for pgpkeys.uk suggests Daniel runs that one too. That covers the first four. kfwebs.net is Kristian Fiskerstrand, who runs the pool tracking system and sks-keyservers.net. hkps is limited because Kristian doesn't hand out certs to anyone who shows up with a new keyserver and asks; he tends to do so with people who've been around and part of the community, because of the fairly obvious problems with assuming TLS is buying you anything when entirely unknown-to-others folks run the servers. Kristian takes a lot of flak for not giving people the power they want just because they ask for it. With the various problems of SKS today, I tentatively suggest that not defaulting to the HKPS pool and choosing a different target for the keys.gnupg.net CNAME might be beneficial. <https://sks-keyservers.net/overview-of-pools.php> has the criteria; I suspect that >> subset.pool.sks-keyservers.net << is likely to be the best choice for GnuPG; the meaning of "subset" changes over time, picking newer servers, but for a while now that's been "updated SKS software able to handle Curve25519 keys". Spitballing crazy design now: The only way to get back HKPS while still having diversity and yet still some accountability is likely to be by requiring DNSSEC-signed reverse-DNS which points to matching DNSSEC-signed forward DNS to prove domain matching, and a trigger record in DNS indicating to use TLS; once there's a forward-name which doesn't require central coordination, you can verify normally and "anyone" can run a keyserver again. With all the pros and cons that entails. GnuPG can pretty much define what it wants here. Including changing the URL scheme name if needed to avoid confusion. TLSA records are available for opportunistic TLS. Effectively, "DANE for HKP with work-arounds to handle the pool nature and bounce into a verifiable name for arbitrary pool names". Shove a TLSA record in reverse DNS to indicate it's supported and you're good. Hrm, probably don't strictly need the reverse DNS to be DNSSEC-signed, as long as the TLSA-or-other-marker is present and the forward DNS is still signed. There's ways around it, but none of it will make folks who object to DNSSEC happy. Tough. -Phil _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel