Keylist RFC: Distributing OpenPGP Keys with Signed Keylist Subscriptions

Privacy and security are fundamental to First Look Media’s mission, which is why everyone here uses PGP to encrypt their email , sign their Git commits , and authenticate with remote services .

To ease the inherent friction in using PGP — and there is no shortage of friction — First Look developed GPG Sync , a tool that keeps everyone’s keystore up-to-date with their colleagues’ latest keys so that PGP key sharing is effortless.

GPG Sync has been so effective at First Look that we thought other organizations would find it useful too. That’s why we’re taking the first steps to turn GPG Sync into an official Internet standard:

Distributing OpenPGP Keys with Signed Keylist Subscriptions https://datatracker.ietf.org/doc/draft-mccain-keylist/

Keylist RFC GitHub Repository https://github.com/firstlookmedia/keylist-rfc

The Challenges of PGP at Scale

When First Look decided to adopt PGP in 2013, we could count the number of employees on one hand. But as First Look grew to nearly 200 people, the problems of using PGP-encrypted email at scale became clear.

In order to use PGP, everyone needs to have their own private key and everyone else needs to have the corresponding public key . To encrypt a message to someone, you use their public key. To decrypt that message, the recipient uses their private key. As new people join the organization, their public key needs to be distributed to everyone else. And when it’s time for someone to renew their key — as is recommended every couple years — the updated public key needs to be distributed to everyone else in the organization.

This sounds reasonable — and public key encryption is a proven model — but sharing PGP keys across the enterprise doesn’t scale well.

It’s easy to see how this system quickly becomes untenable in large organizations. As people come and go, new keys are created and old keys are revoked. With changes every week, it would be unreasonable to require every employee to manually import all the new and updated keys. On top of that, once an organization has been operating for a couple years, existing keys begin to expire and are renewed — further adding to the key churn.

It’s a foundational requirement that every member of an organization have the most recent public key of everyone else, and the danger is that people working in a fast-paced environment won’t take the time to find someone’s new or updated key when needed.

This can lead to serious security issues: for example, if you have an encrypted email conversation with someone and then forward that email to someone whose key you don’t have, the entire conversation becomes unencrypted. If you accidentally send an email to an outdated and compromised key, the security of your message will be compromised as well. PGP works wonderfully when everyone’s keys are kept in sync—but the system fails entirely when they aren’t.

At First Look, we have found that if we want our employees to actually use PGP to encrypt their communications, we need to ensure that it “just works”. This is no easy task, but with the help of GPG Sync we’ve pulled it off — and we want you to be able to as well!

What is GPG Sync, and why would I want to use it?

GPG Sync makes it possible for large organizations to adopt PGP by streamlining key distribution. Micah Lee explained how GPG Sync works in detail in thev0.2 announcement, but here’s an overview:

• A member of the tech staff creates a list of the PGP fingerprints that all members of the organization should keep updated, called a “keylist,” and signs the file with an authority key
• The tech staff publishes both the keylist and the signature online
• Everyone in the organization installs GPG Sync and subscribes to the keylist

It’s that simple! GPG Sync will then keep all the keys listed in the keylist up-to-date. When someone new joins your organization, the tech staff adds the new PGP key fingerprint to the keylist, re-signs it with the authority key, and uploads it to the same URL. From the perspective of the user, it all works seamlessly.

Micah released GPG Sync in 2016, and since then it’s become a vital part of First Look’s operational security. It’s used by all the staff at Topic , The Nib , Field of Vision , and The Intercept . Outside of First Look, the Freedom of the Press Foundation has started using it too. It’s caught on in the greater open-source community as well: the project has hundreds of stars on GitHub, and Micah did an interview for the Free Software Foundation about the project.

There is clearly demand for a tool like GPG Sync, and that made us ask: Why isn’t this functionality already built in to PGP clients themselves?

Making GPG Sync Universal

GPG Sync has one main problem: it requires a command-line `gpg` install, making it desktop-only and impossible to use with many PGP implementations.

Our vision is that one day, you’ll be able to open up your primary PGP client — whether that’s GPGTools , Mailvelope , Canary Mail , or something else entirely — and subscribe to a keylist. There will be no need to install third party software like GPG Sync to keep your keys up to date; your PGP client will do all that for you.

In order for this to happen, we believe there should be an official specification — an Internet standard — for the clients to implement.

The standard would define the format of keylists so that they remain client-agnostic. It would specify the protocol by which the keylist is retrieved from the remote server. And it would also standardize error handling, so that a malformed keylist fails in the same way across all clients.

If done right, such a specification would enable PGP clients to implement GPG Sync’s functionality themselves — and keeping keys up to date would be just a little bit simpler.

Turning GPG Sync into an Internet Standard

The Internet is made of standards, and those standards are defined by thousands of technical documents called RFCs. RFC stands for “request for comment”, but it could be more accurately described as a de facto “law of the Internet”. Among other things, RFCs define the rules that all web browsers, network switches, and servers play by in order to work together. HTTP? That’s defined in RFC 2616 . The domain name system? That’s in RFC 1035 . PGP , HTML , HTTPS , and nearly every other fundamental Internet technology are also RFCs. (There is even an RFC about writing RFCs — in fact, there are dozens of them.)

We want GPG Sync to be a standard so on August 6, 2018 we took our first major step towards that goal and submitted a preliminary draft of the RFC to the Internet Engineering Task Force (IETF).

You can view the document, called an Internet-Draft, using the IETF’s official “Datatracker” tool here .

Next Steps

This process is far from over. Submitting an Internet-Draft to the IETF is only the first step in the long road to publishing an RFC. Our submission still needs to be adopted by the IETF, assigned to a working group for development, and published. And while there’s no guarantee any of that will happen, by submitting a first draft of the RFC to the IETF we’ve taken the first step towards standardizing key distribution in large organizations — and PGP will be better for it.

---

Are you familiar with the IETF standards process? Do you have experience with PGP? We’d love to hear from you. Reach out to our Keylists RFC mailing list .

We are developing this RFC in the open on GitHub. If you’d like to get involved with the development of this RFC, you can view and contribute to the repository here .

Photo by Matt Artz on Unsplash