Why we created ProtonCA

In October 2022, Proton developed its own OpenPGP certificate authority (CA), ProtonCA, and began signing encryption keys to guarantee that they belong to a specific account. This allows OpenPGP users to trust other users’ PGP keys and makes sending end-to-end encrypted (E2EE) messages easier. 

This article explains why CAs are necessary for OpenPGP, why we decided to develop a CA, and how our CA works. 

Why is Proton acting as a certificate authority?

OpenPGP, the open-source encryption standard we use to end-to-end encrypt emails on Proton Mail, is one of the most secure ways to communicate online, but even it has minor potential vulnerabilities. One issue is anyone can create a key and claim it belongs to a specific email address. This could potentially allow an attacker to substitute in a PGP key they created for yours, giving them access to any messages encrypted using that key. 

This issue exists in other cryptography protocols as well. For example, the Transport Layer Security protocol (TLS) that protects all websites that use HTTPS relies on a few centralized CAs to verify that a specific key belongs to the person or website claiming it. To address this issue, the OpenPGP community recently developed OpenPGP CA(new window), making it easy to deploy decentralized CAs. The goal is to create a broad system with many CAs working together to eliminate points of failure. 

We decided to launch ProtonCA because we’re uniquely positioned to act as a CA. We can easily confirm that a specific key belongs to a particular email address as we control the email domain. While Proton users will not see any major difference in service, this will make life much easier for people that use PGP to send E2EE emails to Proton users. Now, no matter how you get a hold of a Proton user’s PGP key, you can be sure that it’s valid and recent (actively used within the past six months) if ProtonCA signed it.

Third-party signatures

The underlying technology OpenPGP CA uses — third-party signatures — has existed for years. Third-party signatures are the primary tool CAs use to authenticate a key. Basically, if you’re a CA, you add your signature to someone else’s key, stating that you’ve verified it belongs to them. This creates a tamperproof binding between the key and the user.

For example, Alice wants to send an email to Bob, so her first step is to retrieve his public encryption key. This downloaded key contains a signature from Ted stating that he certifies this key belongs to Bob. If Alice trusts Ted to correctly verify Bob’s identity, then she indirectly trusts Bob’s key. Ted is the trusted authority in this case, acting as a (very small) CA.

How ProtonCA works

At Proton, we developed ProtonCA according to the system outlined by OpenPGP CA to act as a CA for the keys of millions of Proton users. 

All email addresses hosted by Proton have a key that allows them to receive E2EE messages. ProtonCA adds a third-party signature to each email encryption key using a master key called the CA key. This certifies that Proton guarantees the key belongs to the address associated with it. When a key is generated or imported to Proton Mail, ProtonCA verifies that it’s only associated with one email address, the one it was uploaded for. We then sign the key and store it on our servers. Proton does not verify the identity of individual users (for example, we do not require our users to provide a government ID).  ProtonCA simply confirms that a particular email address corresponds to a specific key.

Let’s go back to our original example with Alice and Bob, but let’s replace Ted with ProtonCA. Now, when Alice fetches Bob’s key, she will receive a key with a ProtonCA signature stating that [email protected] uses that key. Alice, who might be using an external OpenPGP client, can verify the authenticity of this signature, and if she trusts Proton, she’ll indirectly trust this key automatically. This trust applies regardless of how Alice obtained Bob’s key. Even if she found it on an insecure medium, ProtonCA’s signature makes it tamperproof.

ProtonCA’s signature also adds non-repudiability to keys served by Proton. In other words, if Proton serves a bad key, ProtonCA’s signature proves the key was downloaded from Proton. This would reduce trust in Proton and disincentivize us from serving malicious keys.

To avoid certifying old keys, ProtonCA enforces a strict expiration policy. Each key is certified for six months at a time. A month before a certificate expiration, ProtonCA checks to see that the associated email address is still active and the current key has not been removed. If both criteria are met, ProtonCA will renew the certification for an additional six months.

How to trust ProtonCA in other OpenPGP clients

The ProtonCA key can be retrieved here(new window) and has the following fingerprint: 0a8652fe5d53386057899fe9d806c1af5978e8c7.

You can import this key into your GnuPG keyring using the following command:

You must then set the following trust level:

PGP will then automatically flag this key as trusted and all the keys signed by this key as indirectly trusted.

Trust level five (ultimate) is necessary if you don’t have your own OpenPGP key. Each indirect trust path must start with an ultimately trusted key.

To set a trust level lower than five, you must locally sign the [email protected] key. You can do this with the following commands:

This will create a non-exportable signature on the ProtonCA key. Once you’ve performed this step, you can set a different trust level:

Using your own certifications

Since OpenPGP CA’s goal is to set up a decentralized signature system, having a single central CA that issues signatures would defeat the purpose. That is why we’ve added support for certifications on imported PGP keys.

You can set up your own instance of OpenPGP CA(new window) or sign the keys using Sequoia or GnuPG and then import these directly into Proton. You simply need to import the signed private key for the desired address. The public key that we’ve made available to Proton Mail users via Web Key Directory (WKD)(new window) or our Public Key Server (PKS) contains the imported signature.

Note that if you want to add a new key, the signature will not automatically be transferred to the new key. You will need to sign it again manually after it has been added.

UPDATE October 28, 2022: This article added three paragraphs explaining how to set your trust level lower than five.