Why don't PGP keyservers enforce double-opt-in?

Question

One thing that I found out when starting using PGP: When I uploaded my keys to the SKS keyserver, the keyserver did not take any action to verify that I am who I claim to be.

Since a PGP key contains a email adress, at least, the keyserver could have sent an email with an link inside that must be clicked for the key to become live on the keyserver. Then you atleast know that the person who uploaded the PGP key, does atleast Control the email adress he claims to own.

Why does not PGP keyservers verify the ownership of the claimed email account?

Yes, I do understand the web of trust system, but doing a simply automated "Click this link to make your key go live on the key servers" would at least require any impostor to have access to the email account, and such a system could be implemented on keyservers with only a few lines of code.

Another thing I dont know, is how do people verify other's claimed email at Key signing parties? At key signing parties, people show their ID card. But there are no email addresses on the ID card. Yes today with the smartphone evolution, you could send a email to the claimed email address and ask the other person to read it out loud, but how did people do at KSP's when smartphones were not a big thing and you didn't have access to the email account for the moment on the KSP? Especially with email accounts that are behind firewalls, eg Corporate or ISP accounts that can only be used inside the authorized network?

Answer 1

Key servers may never be understood as a source of trust and valid keys. Their only job is to exchange keys, so users of OpenPGP can use the web of trust formed by certifications between keys to validate trusted ones.

Access to a Mail Address Does not Imply Impersonation

Trusting a key is (for most people) more than just verifying a mail address once. Mail addresses tend to change, to invalidate, even to be assigned again afterwards.

Validating an email address based on trust would require some form of invalidation, eg. removal. But how should for example a revocation or other changes be distributed afterwards?

Some Key Servers Do!

But, there are key servers doing so, and thus take the role of a certification authority. Ever wondered about certifications issued by the PGP Global Directory Verification Key? These are issued by the PGP Global Directory Service after validating the mail address contained in a UID, will invalidate after a given time without re-approval (six months, if I remember correctly) and your key will be removed from the server if the certification expired.

But remember: this key server is different from the others, as it offers a very basic authentication of key ownership, but does not support the OpenPGP "way" to validate keys using the web of trust.

How to Define Valid Keys?

As there is no central "trust institution", no certificate authority (or even not several hundred of them, as in X.509); who should define whom to trust? The key server operator? This would at best reduce the number of available keys by order of magnitude, in fact possibly to a few dozen or hundred trusted keys of the operator, compared with millions of keys mostly not even connected to the OpenPGP web of trust.

Additionally, each OpenPGP users potentially has his own rules to decide how to validate keys, although these might be rather similar most of the time.

Key servers simply form a method to exchange data between OpenPGP clients. and usually do not take the role of a certification authority.

Key Servers Synchronize

Most key servers synchronize with each other. Already the ones listed in the SKS key server pool list about two hundred of them, most of them operated by individuals who even don't know each other.

Having such a decentralized key server infrastructure is crucial against several attacks (denial of service, deletion of keys, having a central log of what's requested), especially from those having access to large portions of a network (ISPs, governments).

But: how should email address verification be achieved in such a distributed network of unrelated servers not trusting each other? The only possibility (at least, no other was proposed so far) is to replicate everything, and each key server would have to decide on the validity.

Would you like to approve each of your mail addresses to 200+ key servers in given (and very likely different and rather short) time intervals?

Answer 2

It's very important to understand that OpenPGP keyservers are not certificate authorities. They are not responsible for key verification. OpenPGP employs a decentralized trust model, so it's the user's job to verify a key either by directly checking the fingerprint or by using the web of trust (like you already said).

When people use keyservers to download a key for a given e-mail address without any further validation, they fundamentally misunderstand the trust model of OpenPGP. That's not the keyserver's fault.

Of course keyservers could introduce basic verification to reduce to amount of garbage keys. However, this would further blur the line between keyservers and CAs, and it might create a false sense of security. The fact that somebody was able to read a link within an unencrypted confirmation e-mail doesn't prove anything, because the e-mail may very well have been captured in transit. So a keyserver offering “verified keys” based on this method would be walking on thin ice.

The purpose of key signing parties is not to check e-mail addresses. As the name already implies, they are about keys. To be exact: Typically, a participant A checks the identity of another participant B, asks for B's fingerprint and then signs the corresponding key. So if I want to communicate with B and already trust A, I may use that signed key. Of course B might lie and provide a false e-mail address, but that's a social issue, not a technical one. If a person just refuses to have a private e-mail conversation, no protocol will fix that.

Answer 3

As far as double opt-in is concerned you only want to perform the check once rather than once for each server in the network. That means the checks aren't proof against even a single key server accepting keys without checking and there isn't an easy way to verify which server accepted a key. One could design a different protocol which included verification of which server accepted a key but transition would be hard.

The normal way to verify the e-mail address of a PGP key after a key signing is to send the signed key, encrypted to the key to that address and let the owner decrypt and upload it to the keyservers themselves. You don't incorporate it into your regular public key ring until you download it from the keyservers or otherwise get a signed copy from the key owner. One could see this as a form of TOFU (trust on first use) security akin to the way ssh keys are often handled. There are tools to facilitate this model such as Pius and