It has been three months now since we launched keys.openpgp.org . We are happy to report: It has been a resounding success! 🥳

Adoption in clients

The keys.openpgp.org keyserver has been received very well by users, and clients are adopting it rapidly. It is now used by default in GPGTools, Enigmail, OpenKeychain, GPGSync, Debian, NixOS, and others. Many tutorials have also been updated, pointing users our way.

At the time of writing, more than 70.000 email addresses have been verified.

If that isn't a promising curve, I don't know what is :)

A special shout-out here goes to GPGTools for macOS. They implemented the update process so smoothly, the number of verified addresses completely exploded when they released their update.

All's good in operations

There is not a lot to report operationally, and no news is good news in this case! Since launch, there was nearly zero downtime, only a single bug came up that briefly caused issues during upload, and support volume has been comfortably low.

Our traffic is currently at about ten requests per second (more during the day, less on the weekend), and we delivered roughly 100.000 emails in the last month. No sweat.

We made several small operational improvements including deployment of DNSSEC, implementing some rate-limiting, nailing down our content security policy headers, and enabling single-hop mode on our Tor Onion Service. You can find a more complete list here.

Secure email delivery with MTA-STS

One improvement that deserves special mention is MTA-STS, which improves the security of outgoing emails.

While HTTPS is deployed fairly universally these days, that sadly isn't the case for email. Many servers don't do encryption at all, or use a self-signed certificate instead of a proper one (e.g. from Let's Encrypt). But delivery failures upset customers more than reduced security, and many emails are still delivered without encryption.

With MTA-STS, domain operators can indicate (via HTTPS) that their email server does support encryption. When a secure connection can't be established to such a server, message delivery will be postponed or eventually bounce, instead of proceeding insecurely.

This is extremely useful for service like keys.openpgp.org . If encryption isn't reliable, attackers can intercept verification emails relatively easily. But for providers who have MTA-STS deployed, we can be sure that every message is delivered securely, and to the right server.

You can run a check to find out whether your email provider supports MTA-STS. If they don't, please drop them a message and tell them to step up their security game!

Work in progress

We are working on two features:

The first is localization. Most people do not speak English, but so far that is the only language we support. To make this service more accessible, we are working with the OTF's Localization Lab to make the website and outgoing emails available in several more languages.

The second is to bring back third-party signatures. As mentioned in our FAQ, we currently don't support these due to spam and potential for abuse. The idea is to require cross-signatures, which allow each key to choose for itself which signatures from other people it wants to distribute. Despite this extra step, this is fairly compatible with existing software. It also nicely stays out of the way of users who don't care about signatures.

Although work is in progress for both of those features, neither have a planned time of release yet.

Regarding the "no user ID" issue with GnuPG (mentioned in our last news post and our FAQ), a patch that fixes this problem is now carried by Debian, as well as GPGTools for macOS. GnuPG upstream has not merged the patch so far.

That's it! Thanks for your interest! 👋