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 [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
