Revoking a Key

Revoking an OpenPGP key means that we publish a statement saying that the key should not be used anymore. The statement may include a reason why the key shouldn’t be used (e.g., it has been compromised, or the user simply has a new one), and when the revocation should come into effect. The statement is a machine readable, cryptographic artifact and is called a “revocation certificate”.

Revocation certificates should be widely published (e.g. via WKD and on Key Servers) so that third parties will quickly learn that the key should not be used anymore, and to prevent an attacker from hindering distribution of the revocation certificate.

There are different reasons why we might want to revoke a user’s OpenPGP key. For example, the user’s key might have been compromised, or the user has left our organization. Revocation certificates contain information about the reason why the affected key has been revoked. OpenPGP implementations can use this information to determine how to treat existing artifacts. For instance, if a key has been compromised, the attacker could create backdated signatures. Thus, all signatures should be considered suspect. But, if a user simply switched to a new key, old signatures may still be considered valid.

Managing Revocations

In OpenPGP, to be able to generate a revocation certificate for a key, the private part of that key is needed. Since OpenPGP CA doesn’t keep a copy of a user’s private key, this means that revocations can typically only be generated by the user themselves.

While OpenPGP CA never stores users’ private keys, it does optionally store revocation certificates for our users’ keys. This means that the OpenPGP CA admin can choose to invalidate users’ keys.

A risk that follows from centrally storing revocation certificates is that if the OpenPGP CA data (including the revocation certificates) is compromised, a third party is able to invalidate our user’s keys - leading to a denial-of-service attack scenario, where our users can’t use OpenPGP anymore. That is bad. However, it is much less severe than a scenario in which the attacker gains access to the user’s private key material.

For every user, one or many revocation certificates may be stored in OpenPGP CA.

To check which revocation certificates exist for a given user, we can query by email:

$ oca -d example.oca user show-revocations --email alice@example.org

Revocations for OpenPGP key B7D7DB3180B91CEF4F34B7A77BADF98D5CF091CE, user "Alice Adams"
 - revocation id 9D769852A313A2CA: No reason specified (Unspecified) (05/08/2020)

The results show an ID for each individual revocation certificate.

When we’ve determined which revocation certificate we want to apply, we can apply that revocation to the user’s key:

$ oca -d example.oca user apply-revocation 9D769852A313A2CA

Afterwards, “show-revocations” will display the additional note: “this revocation has been APPLIED”, and the user’s public key contains the revocation certificate:

$ oca -d example.oca user show-revocations --email alice@example.org

Revocations for OpenPGP key B7D7DB3180B91CEF4F34B7A77BADF98D5CF091CE, user "Alice Adams"
 - revocation id 9D769852A313A2CA: No reason specified (Unspecified) (05/08/2020)
   this revocation has been APPLIED

Publishing the revocation

Now the revocation has been applied to our local copy of the user’s OpenPGP key. We still need to publish this newly revoked version of the user’s key.

To achieve this we should regenerate our organization’s WKD and publish the new version of this user’s OpenPGP key there.

Also, we can manually export the user’s key

$ oca -d example.oca user export --email alice@example.org > alice.pub

and then upload it to a public key server, or distribute it using other mechanisms.

As the revoked version of the user’s key gets disseminated, the OpenPGP implementations of third parties learn that the key should no longer be used.