Design of a Modern Keyserver Network

[Michael Richardson]

andrewg <andrewg at andrewg.com> wrote:
    > 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...)

But, today, you don't keep/flood revocations, right?

    >> 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)

I think that it can't happen unless it's automated.
Whether autocrypt or something else.

    > 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).

Let's take this to openpgp at ietf.org.


--
Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250131/4dcbf8f6/attachment.sig>