From 2698cecd4c34a4bc1dec5ca019a0ba8b0ee561fe Mon Sep 17 00:00:00 2001 From: apiraino Date: Tue, 28 Apr 2020 16:19:18 +0200 Subject: [PATCH] Add instruction to create a revoke certificate --- README.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/README.md b/README.md index 3895fd6..af705c5 100644 --- a/README.md +++ b/README.md @@ -27,6 +27,7 @@ If you have a comment or suggestion, please open an [Issue](https://github.com/d * [Authentication](#authentication) * [Add extra emails](#add-extra-emails) - [Verify](#verify) +- [Create a revoke certificate](#create-a-revoke-certificate) - [Export](#export) - [Backup](#backup) - [Configure Smartcard](#configure-smartcard) @@ -843,6 +844,20 @@ $ gpg -o \path\to\dir\mastersub.gpg --armor --export-secret-keys $KEYID $ gpg -o \path\to\dir\sub.gpg --armor --export-secret-subkeys $KEYID ``` +# Create a revoke certificate + +Although we will backup and store the master key in a safe place, it is best practice to never rule out the possibility of losing it or having the backup fail. Without the master key it will be impossible to renew or rotate subkeys or generate a revoke certificate, our keychain will be basically useless. + +Even worse, we cannot advertise this fact in any way to those that are using our keys. It is therefore safe to assume that at some point in the future this *will* happen and the only thing that will allow us to deprecate our *orphan* keys is a revoke certificate. + +In order to create the revoke certificate: + +``` console +gpg --output revoke.asc --gen-revoke $KEYID +``` + +The newly created `revoke.asc` file should be stored (or printed) in a place that allows us to retrieve it in case our backup strategy fails. + # Backup Once keys are moved to YubiKey, they cannot be moved again! Create an **encrypted** backup of the keyring and consider using a [paper copy](https://www.jabberwocky.com/software/paperkey/) of the keys as an additional backup measure.