Folks, Anyone can run a keyserver pool in DNS. There are at least two codebases for generating the data needed (I know of stuff in PHP and Go).
The only thing special about Kristian's pools is that, in the opinion of people making decisions which impact others, they've been well run for long enough that they're worth using as a default. (I run my own pool as an experiment, because I wanted to learn and to not have a monoculture, but in practice for real deployment, I use one of Kristian's pools (when not using a specific server)). So people point CNAMEs at one of Kristian's pools, and some of those become bundled as default. There's inertia, but mostly people are sticking with demonstrated competence. If anyone believes they can run pool definitions better, then do so. Demonstrate that you can walk the walk, not just talk the talk. Make something which works, and work with other people to get them to buy into your scheme, as Kristian did with his HKPS setup. If you make something which is better, then folks will start to use it. GnuPG might. Any of the new competitors to GnuPG might. GnuPG defaults to a hostname under their control and can repoint DNS to a different pool if they feel it appropriate to do so. My own thoughts on the security model we have today: http://www.openwall.com/lists/oss-security/2017/12/10/1 In the absence of _showing_ a better _pool_ system, working in practice, all this talk I've just forced myself to wade through is IMO not helpful for SKS development or operations and not appropriate for this mailing-list. Once we have another pool with a different security model for TLS, which operators can choose to start using, _then_ we have something which might be relevant for this mailing-list. -Phil, speaking only for myself. I might be wrong. _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel