recommendation for key servers

[Andrew Gallagher]

> On 13 Jul 2021, at 09:43, Bernhard Reiter <bernhard at intevation.de> wrote:
> 
> Am Mittwoch 30 Juni 2021 19:35:25 schrieb Andrew Gallagher via Gnupg-devel:
>> The "permission-recording keyserver" as described here requires the
>> various keyserver operators to trust each other to validate these
>> permissions correctly. 
> 
> Not quite.
> It is designed the other way around without "mandatory validation":
> it allows for later opt-out or finding the party that publishes
> unwanted information. So it can work at first try.

If there is no cryptographic verification, then Mallory can trivially fake the recorded permissions, rendering the entire proposal pointless.

> And email servers also do not trust each other fully, they just delegate
> and assume some initial trust.

Yes, and this opened the spam floodgates, which is why DKIM had to be invented.

Speaking of which, perhaps we could piggyback the provenance verification on DKIM, since most public keyserver operators would presumably be admins of their own domains. That way we wouldn’t need to have a pre-approved list of “good” keyservers. 

>> Technically, this could be done if the validating 
>> keyserver signs the user IDs that it has personally checked, and each of
>> its peers verifies this third-party sig against their own trusted
>> keyservers list.
> 
> This comes with too much power for the "validating keyserver" to me.
> My feeling is that this is unneeded.

Some form of spam prevention is needed, and I don’t see how that is possible without cryptographic verification of provenance. What form that takes is debatable. 

A