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
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
