
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>Hi, Seth.</div><div><br></div>On 17 Jan 2025, at 22:59, Seth McDonald via Gnupg-users <gnupg-users@gnupg.org> wrote:<br><div><blockquote type="cite"><div><div><div class="content-isolator__container"><div class="protected-part"><div class="protected-title"><br></div><div class="protected-content">To my understanding, it seems the vast<br>majority of keyservers (connected via the 'SKS network') were functionally<br>damaged due to a 2019 'certificate poisoning' attack, and were subsequently<br>shut down in 2021 due to being unable to comply with the GDPR.<br></div></div></div></div></div></blockquote><div><br></div><div>This is not strictly accurate. The <a href="http://sks-keyservers.net">sks-keyservers.net</a> domain shut down due to the legal ambiguity of running (effectively) a proxy service for random other operators. And the SKS network transitioned away from the sks-keyserver software (which was unable to handle deletion requests or poisoned keys) to the more modern hockeypuck software (see <a href="https://hockeypuck.io">https://hockeypuck.io</a>). In the meantime, <a href="http://keys.openpgp.org">keys.openpgp.org</a> was set up as a less-functional (but more reliable) service that was suitable as a safe default for existing clients.</div><div><br></div><div>The SKS network is therefore alive and well, it just doesn’t run on sks-keyserver any more. It also has fewer nodes (currently 21 exposed publicly) than it did at its peak (over 100) -- but due to the more modern codebase it is much more performant (and reliable). You can see the current state of the network at <a href="https://spider.pgpkeys.eu">https://spider.pgpkeys.eu</a></div><div><br></div><div>It is a long-term goal of most operators to realign the various keyservers around a more sustainable model. Suggestions are always appreciated, and anyone interested in working on keyserver improvements is most welcome. :-)</div><br><blockquote type="cite"><div><div><div class="content-isolator__container"><div class="protected-part"><div class="protected-content">https://gist.github.com/McDaMastR/d4781ce0fd0e4a0ad60fd85201031f5d<br><br>I would be beyond grateful if you could provide some constructive feedback!</div></div></div></div></div></blockquote></div><br><div>Thanks for this; I’ll read through it in more detail later. You may also be interested in the various existing proposals for fixing keyservers, some of which are already in the process of being implemented:</div><div><br></div><div>* <a href="https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-1pa3pc">https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-1pa3pc</a></div><div>* <a href="https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore/-/issues/2" rel="nofollow">https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore/</a></div><div>* <a href="https://github.com/hockeypuck/hockeypuck/wiki/HIP-3:-Timestamp-aware-merge-strategy">https://github.com/hockeypuck/hockeypuck/wiki/HIP-3:-Timestamp-aware-merge-strategy</a></div><div>* <a href="https://github.com/hockeypuck/hockeypuck/wiki/HIP-5:-Reliable-personal-data-deletion-using-self-signatures">https://github.com/hockeypuck/hockeypuck/wiki/HIP-5:-Reliable-personal-data-deletion-using-self-signatures</a></div><div><br></div><div>Thanks again for your interest in the keyservers!</div><div><br></div><div>A</div><div><br></div></body></html>