[Gpg4win-users-en] torproject pubkey (Re: gpg4win 3.1.16 with updated GnuPG 2.2.32: No public key found despite having refreshed the keys)

Andrew Gallagher andrewg at andrewg.com
Thu Dec 23 12:09:31 CET 2021

> On 23 Dec 2021, at 09:45, Bernhard Reiter <bernhard at intevation.de> wrote:
>> More sophisticated protections are a work in progress, however it is not
>> correct to say that modern synchronising keyservers lack functionality.
> Currently they cannot serve third party signatures on those pubkeys or those 
> pubkeys at all, which I believe is a lack of functionality.

This was always true, keyservers could never serve poisoned keys and we had been living on borrowed time until someone took advantage of it. The substantial change is in the existence of poison keys; the “old functionality” that you speak of never existed. 

>> All that is missing is a shared DNS entry to replace
>> pool.sks-keyservers.net, but this just means that you have to pick a
>> specific keyserver (GnuPG upstream has chosen keyserver.ubuntu.com as
>> the default).
> This is also a certain lack of functionality.

It’s a change in how the service is presented to the end user but IMO, provided you choose a well-run keyserver, the overall experience has actually improved - many of the servers formerly in the pool were run on a casual basis and the pool monitor was not responsive enough to remove them from rotation as they failed, leading to persistent reliability issues. 

Where the ecosystem has noticeably gone backwards is in the (hopefully temporary) fragmentation of keyservers into two camps that do not sync with each other - but this is orthogonal to the loss of the pool (keys.openpgp.org would not have qualified for pool membership in its current format). Whether the existence of keys.openpgp.org counts as a “loss of functionality” in the servers that it refuses to sync with is a stretch…

> (I had just meant to make a very brief statement, glossing over the details.

I’m nitpicking, I concur with the majority of your points!

> Maybe you can point me to the reasons you have mentioned elsewhere, why the 
> pool DNS entry is problematic.)

Lack of legal clarity. The pool DNS led to one individual fielding data protection queries about the content of servers that were outside his control. Individual server operators can act as data controllers, but the pool owner cannot.


More information about the Gpg4win-users-en mailing list