Work on localization is in full swing!
we hope to have some languages ready for deployment soon.

If you would like to see keys.openpgp.org
translated into your native language,
please join the translation team
over on Transifex.
We would appreciate help especially for Russian, Italian, Polish and Dutch.

That's all, keeping this one short!
👍️

2019-09-12 📅

It has been three months now
since we launchedkeys.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.

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.

Why a new keyserver?

We created keys.openpgp.org
to provide an alternative to the SKS Keyserver pool,
which is the default in many applications today.
This distributed network of keyservers has been struggling with
abuse,
performance,
as well as privacy issues,
and more recently also
GDPR
compliance questions.
Kristian Fiskerstrand has done a stellar job maintaining the pool for
more than ten years,
but at this point development activity seems to have
mostly ceased.

We thought it time to consider a fresh approach to solve these problems.

Identity and non-identity information

The keys.openpgp.org keyserver splits up
identity and non-identity information in keys.
You can find more details on our about page:
The gist is that non-identity information (keys, revocations, and so on)
is freely distributed,
while identity information
is only distributed with consent
that can also be revoked at any time.

If a new key is verified for some email address,
it will replace the previous one.
This way,
every email address is only associated with a single key at most.
It can also be removed from the listing
at any time by the owner of the address.
This is very useful for key discovery:
if a search by email address returns a key,
it means this is the single key
that is currently valid for the searched email address.

Support in Enigmail and OpenKeychain

The keys.openpgp.org keysever
will receive first-party support in upcoming releases of
Enigmail for Thunderbird,
as well as
OpenKeychain on Android.
This means users of those implementations will
benefit from the faster response times,
and improved key discovery by email address.
We hope that this will also give us some momentum
to build this project into a bigger community effort.

Current challenges

Privacy-preserving techniques in keyservers are still new,
and sadly there are still a few compatibility issues
caused by splitting out identity information.

In particular, when GnuPG (as of this writing, version 2.2.16) encounters
an OpenPGP key without identities,
it throws an error "no user ID"
and does not process new non-identity information
(like revocation certificates)
even if it is cryptographically valid.
We are actively engaged in
providing fixes for these issues.

The future

Privacy-preserving techniques in keyservers are still new,
and we have more ideas for reducing the metadata.
But for now, our plan is only to
keep keys.openpgp.org reliable and fast 🐇,
fix any upcoming bugs 🐞,
and listen to feedback from the community. 👂