Design of a Modern Keyserver Network

[Seth McDonald]

> Thank you for this post.
> It's not particularly GNUPG specific, maybe this belongs on openpgp at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250127/d22113cc/attachment.sig>