SeanOMik
/
YubiKey-Guide
mirror of https://github.com/SeanOMik/YubiKey-Guide.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add steps for renewing (not rotating) sub-keys 

As discussed in issue #164, the current section on Rotating Keys
presents two alternatives: replacing the existing keys with a newly
generated key or extending the validity of existing keys by changing
their expiration.  However, it only provides instructions for the
first approach.  This commit adds instructions for renewing sub-keys.

I am far from an expert, and am submitting this change mostly in hopes
that it will provide documentation for the next time I need to renew
my sub-keys.  I would welcome any changes or clarifications others
would care to offer.
This commit is contained in:
Daniel Sockwell 2020-03-24 12:42:42 -04:00
parent 2c2cec316c
commit b5adb349ad
1 changed files with 102 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

103
README.md
View File

@ -1604,6 +1604,8 @@ Replacing keys, on the other hand, is less convenient but more secure: the new s
Neither rotation method is superior and it's up to personal philosophy on identity management and individual threat model to decide which one to use, or whether to expire sub-keys at all. Ideally, sub-keys would be ephemeral: used only once for each encryption, signing and authentication event, however in practice that is not really feasible or worthwhile with YubiKey. Advanced users may want to dedicate an offline device for more frequent key rotations and ease of provisioning.
### Initial setup for rotating keys or renewing sub-keys
To renew or rotate sub-keys, follow the same procedure to boot to a secure environment. Install required software and disconnect networking. Decrypt and mount the offline volume, then import the master key and configuration to a temporary working directory:
```console
@ -1625,7 +1627,106 @@ Secret key is available
[...]
```
Follow the original steps to generate each sub-key. Previous sub-keys may be kept or deleted from the identity.
### Renewing sub-keys
Renewing sub-keys is simpler: you do not need to generate new keys, move keys to the YubiKey, or update any SSH public keys linked to the GPG key. All you need to do is to change the expiry time associated with the public key (which requires access to the master key you just loaded) and then to export that public key and import it on any computer where you wish to use the **GPG** (as distinct from the SSH) key.
To change the expiration date of all sub-keys, start by selecting all keys:
```console
$ gpg --edit-key $KEYID
Secret key is available.
sec rsa4096/0xFF3E7D88647EBCDB
created: 2017-10-09 expires: never usage: C
trust: ultimate validity: ultimate
ssb rsa4096/0xBECFA3C1AE191D15
created: 2017-10-09 expires: 2018-10-09 usage: S
ssb rsa4096/0x5912A795E90DD2CF
created: 2017-10-09 expires: 2018-10-09 usage: E
ssb rsa4096/0x3F29127E79649A3D
created: 2017-10-09 expires: 2018-10-09 usage: A
[ultimate] (1). Dr Duh <doc@duh.to>
gpg> key 1
Secret key is available.
sec rsa4096/0xFF3E7D88647EBCDB
created: 2017-10-09 expires: never usage: C
trust: ultimate validity: ultimate
ssb* rsa4096/0xBECFA3C1AE191D15
created: 2017-10-09 expires: 2018-10-09 usage: S
ssb rsa4096/0x5912A795E90DD2CF
created: 2017-10-09 expires: 2018-10-09 usage: E
ssb rsa4096/0x3F29127E79649A3D
created: 2017-10-09 expires: 2018-10-09 usage: A
[ultimate] (1). Dr Duh <doc@duh.to>
gpg> key 2
Secret key is available.
sec rsa4096/0xFF3E7D88647EBCDB
created: 2017-10-09 expires: never usage: C
trust: ultimate validity: ultimate
ssb* rsa4096/0xBECFA3C1AE191D15
created: 2017-10-09 expires: 2018-10-09 usage: S
ssb* rsa4096/0x5912A795E90DD2CF
created: 2017-10-09 expires: 2018-10-09 usage: E
ssb rsa4096/0x3F29127E79649A3D
created: 2017-10-09 expires: 2018-10-09 usage: A
[ultimate] (1). Dr Duh <doc@duh.to>
gpg> key 3
Secret key is available.
sec rsa4096/0xFF3E7D88647EBCDB
created: 2017-10-09 expires: never usage: C
trust: ultimate validity: ultimate
ssb* rsa4096/0xBECFA3C1AE191D15
created: 2017-10-09 expires: 2018-10-09 usage: S
ssb* rsa4096/0x5912A795E90DD2CF
created: 2017-10-09 expires: 2018-10-09 usage: E
ssb* rsa4096/0x3F29127E79649A3D
created: 2017-10-09 expires: 2018-10-09 usage: A
[ultimate] (1). Dr Duh <doc@duh.to>
```
Then, use the `expire` command to set a new expiration date. (Despite the name, this will not cause currently valid keys to become expired).
```console
gpg> expire
Changing expiration time for a subkey.
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)
```
Follow these prompts to set a new expiration date, then `quit` to save your changes.
Next, export your public key:
```console
$ gpg --export $KEYID > pubkey.gpg
```
Transfer that public key to the computer from which you use your GPG key, and then import it with:
```console
$ gpg --import pubkey.gpg
```
This will extend the validity of your GPG key and will allow you to use it for SSH authorization. Note that you do _not_ need to update the SSH public key located on remote servers.
### Rotating keys
Rotating keys is more a bit more involved. First, follow the original steps to generate each sub-key. Previous sub-keys may be kept or deleted from the identity.
Finish by exporting new keys: