Thank you for this post. It's not particularly GNUPG specific, maybe this belongs on open...@ietf.org. Maybe your gist should become an Internet-Draft.
Re Steps 3,4,5: * The keyserver sends the resultant hash to Alice via email using the email address given on her public key's UID. * Alice receives the hash, signs it using her private key, and inputs and submits the ASCII-armoured detached signature to the website, sending it to the keyserver. * The keyserver verifies the signature, and if it is indeed valid, Alice's public key is successfully uploaded. This sounds to my ears a bit like autocrypt. Could it be? As for revocation, and the server(s) having access to it. 1. does Alice have to interact with the same server? (I think so?) Does she even remember which one? :-) 2. it seems that a compromise of a keyserver system could allow attackers to push revocation certificates out for anyone/everyone. I agree with removing photo-like extensions from the key to reduce mischief. I wonder if removing the UID information from a key is enough to be forgotten (vs the entire key). The three responsabilities you list seem to rest upon the key servers always having revocation certificates available, and this concerns me for the reason above. Other than this concern, I think your design is right on. I can't think of a way to satisfy requirements 4,5,6 without the revocation certificiates available, and I think this might be the achilles heel here. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT 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
