Design of a Modern Keyserver Network

[Michael Richardson]

I was awake a bunch last night, and I was pondering the six points that Seth
made.  I am more and more concerned with having key servers have access to
revocation (certificates), and I have no understanding how this will work with
key server to key server communication.  It seems to me that there is no way
to keep those revocation blobs from becoming public, and therefore abused.
That seems the biggest risk to me.

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.  Effectively, each key server (organization) needs to make
contact with the key owner to establish right to publish key.  And that needs
to expire.

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.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


-------------- 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/20250130/7ab6bdd4/attachment.sig>