> Thank you for this post. > It's not particularly GNUPG specific, maybe this belongs on open...@ietf.org.
Thanks, I'll give it a look! > 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? To my understanding, Autocrypt is a specification which details how emails should include a particular header containing the sender's public key, allowing for automated key exchange and subsequent encryption. However, the steps in question aim to verify that the client (Alice) has 1) access to the email address, and 2) access to the private key. This is done by including in the body of the email some data (in this case a hash), and requiring the client to sign that data with the private key. So I suppose it's similar in the sense that communication occurs via email, though the purpose of this communication is much different. > 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? :-) Given that the revocation certificates are stored in the metadata of the public keys, they should just be synchronised across keyservers along with the rest of the keys, allowing revocation to occur at any keyserver in the synchronising network. > 2. it seems that a compromise of a keyserver system could allow attackers to > push revocation certificates out for anyone/everyone. Indeed, this is a weakness of the design. However, it also means that of the possible attacks against a keyserver network, the least infeasible against this design is not certificate poisoning, but rather unwanted revocation. And while such an attack would certainly be disruptive and annoying, it can be rectified with relative ease: just generate a new key pair and upload the new public key. Users of the public key can import the new key and remove the old one, and after some re-certification things are back to normal. In comparison, the certificate poisoning attack in 2019 didn't only render the poisoned keys unusable; to my knowledge, it completely broke many users' key management programs (including GnuPG), forcing them to rebuild their keychains from scratch. In a way, the design makes a trade-off by reducing the possibility of a certificate poisoning attack, but increasing the possibility of an unwanted revocation attack. Though given the two attacks' comparative capacity for damage, I personally find such a trade-off to be reasonable. Additionally, to prevent an attack from revoking a large number of public keys en masse, a simple countermeasure would be to have keyservers keep track of how many public keys have been newly revoked during synchronisation. And if an exceptional amount of revocation seems to have occurred, synchronisation can be automatically halted until the keyserver operators manually allow it to continue. This way, if a particular keyserver is compromised and a lot of public keys are revoked, most other keyservers will notice this jump in revocations and stop synchronising with the compromised keyserver, effectively quarantining the attacked keys. From here, the compromised keyserver can be reset, altered, or similar, and then continue operation as normal. This process can significantly mitigate the damage of an unwanted revocation attack due to many of the targeted public keys being prevented from synchronising throughout the network, effectively shielding them from the attack. > I wonder if removing the UID information from a key is enough to be forgotten > (vs the entire key). (Disclaimer: I am *not* a lawyer) I believe it should be enough to satisfy the right to be forgotten. According to Article 4(1) of the GDPR, "‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’)". By removing all UID data from the public key, the data subject (key owner) is not identified by the key itself. But is the data subject identifiable through the key + some additional research to find external references to the key that relate it to the data subject? Potentially, yes. Though an important detail to note is that for the keyserver to remove UID information from a pubic key, that key must be revoked. And it can be reasonably expected that most or all references to the now-revoked public key would be removed or changed. After all, why would anyone ever want to advertise a revoked key? It's completely useless! As such, it likely can be reasonably assumed that with all UID data removed, the public key neither identifies the data subject, nor does it make the data subject identifiable within reason. > 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. I can for certain agree that requiring the upload and storage of revocation certificates is the design's main limitation. Both for the reasons you've outlined, and also because it shifts more trust onto keyservers and their operators, which arguably goes against the web of trust's principle of entrusting solely users with the responsibility of managing their own key pairs. But since keyservers act as a middleman for the distribution of public keys, they too likely require at least some (ideally limited) ability to manage said keys in the event of legal intervention. So I mainly view it as a compromise between abstaining from interference of users' keys and adhering to legal obligations. Thank you for the thoughtful feedback, and apologies for the late response. Sincerely, Seth. PGP Fingerprint 82B9 620E 53D0 A1AE 2D69 6111 C267 B002 0A90 0289
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
