Design of a Modern Keyserver Network

[andrewg]

On 2025-01-30 11:29, Michael Richardson wrote:
> 
> I think that that the place where we actually need to differ from the 
> past is
> actually the flood-fill between key servers.  I think that's probably 
> not
> going to work.

Speaking for the current SKS keyserver operators, it *is* currently 
working. There are occasional glitches when vandals find a way around 
our flooding protections, but we are constantly improving these. (I 
realise I'm tempting fate by saying this...)

> Autocrypt seems like the right way for key servers to interact with 
> users.
> Effectively, what we want is a kind of STAR:
> 
>    Support for Short-Term, Automatically Renewed (STAR) Certificates in 
> the
>    Automated Certificate Management Environment (ACME)
>    RFC 8739
> 
> specifically, keyservers will stop publishing keys that they can't 
> confirm
> that the user actually still wants published.

It's a good idea in principle, but the practicalities of getting 
continually refreshed consent to publish are currently prohibitive. ACME 
works because the end user (i.e. the server operator) has an automated 
job that periodically polls the issuer (e.g. letsencrypt) for fresh 
certifications, and the issuer can validate the request by making a 
simple HTTP request that the user does not need to be aware of. This 
does not translate well to email, which is a fundamentally interactive 
protocol. It is true that enigmail used to automatically handle WKS 
verification emails, but this did not catch on elsewhere 
(unfortunately!) and having multiple keyservers send out such 
verifications on a recurring schedule would quickly become annoying (and 
potentially get a keyserver blacklisted).

A