Project:Infrastructure/Generating GLEP 63 based OpenPGP keys
Creating a new key is only necessary if you don't have one already, if it's a DSA key or a weak (<2048 bits) RSA key. Otherwise, it is strongly preferable to fix the existing key instead.
This guide provides Gentoo developers with best practices and detailed instructions on creating a GLEP 63 compliant OpenPGP key pair.
Overview
OpenPGP
OpenPGP is one of the most widely used cryptographic standards in the world. The OpenPGP standard was originally derived from PGP (Pretty Good Privacy), first created by Phil Zimmermann in 1991, and is now maintained by the OpenPGP Working Group of the Internet Engineering Task Force. One of the most used open source implementations of the OpenPGP standard is the GNU Privacy Guard (GnuPG).
The OpenPGP standard is a hybrid scheme utilizing both asymmetrical and symmetrical cryptography to establish the cryptosystem. The asymmetrical components are used to establish a nPKI (Public Key Infrastructure) ad when mentioning keys in this document, it is a reference to the asymmetrical components. It is a hybrid system when used for data encryption, as the data itself is encrypted symmetrically using a random session key, which is afterwards encrypted individually using the asymmetrical encryption keys of each recipient.
OpenPGP keys (i.e. asymmetrical) normally consists of a primary key used for certification and signing and a subkey capable of Encryption. This is often extended to using a primary key for certification purposes only, and separate subkeys for Signing and Encryption. Such a scheme allows for the primary key to be stored offline, while the subkeys are used for day-to-day use.
When generating a new User ID, a new subkey, creating a certification (signature) of another key, or performing revocation procedures, the primary key will have to be used, and as such these operations are normally conducted on a more secure system. As certifications by other users are tied to the primary key, as components structured below the User ID and User Attribute, this allows for key-rotation without losing existing certificates of the key, e.g. in the event of a key compromise due to loss of a device.
GLEP 63
GLEP 63 is a proposal accepted by the Gentoo Council which provides both a minimum requirement and a recommended set of OpenPGP key management policies for the use of GnuPG by Gentoo Linux developers. It is intended to provide a basis for future improvements such as consistent ebuild or package signing and the possibility of verification of integrity by end users.
Generating a GLEP 63-compliant OpenPGP key
In the next few steps we will show you how to generate a GLEP 63-compliant OpenPGP key. This key should last be flexible enough to support as many setups as possible (e.g. various hardware token). In the end this key should allow you to become part of the Web of Trust while helping to keep Gentoo secure.
According to GLEP 63, the expiration date on the key and all subkeys must be set to no more than 900 days into the future.
Step 1: Install the tools you will need
We will need the normal GnuPG 2.x CLI client. If it is not installed yet, you can install it with:
root #emerge --ask app-crypt/gnupgStep 2: Backup an existing GnuPG setup
First, backup an existing GnuPG configuration, including the private keyring. The location of the current GnuPG configuration and keyrings can be displayed with:
user $gpgconf --list-dirssysconfdir:/etc/gnupg bindir:/usr/bin libexecdir:/usr/libexec libdir:/usr/lib64/gnupg datadir:/usr/share/gnupg localedir:/usr/share/locale socketdir:/home/larry/.gnupg dirmngr-socket:/home/larry/.gnupg/S.dirmngr agent-ssh-socket:/home/larry/.gnupg/S.gpg-agent.ssh agent-extra-socket:/home/larry/.gnupg/S.gpg-agent.extra agent-browser-socket:/home/larry/.gnupg/S.gpg-agent.browser agent-socket:/home/larry/.gnupg/S.gpg-agent homedir:/home/larry/.gnupg
Now that GnuPG's current homedir has been discovered (/home/larry/.gnupg in this example), create a backup of the current GnuPG configuration, including the keyrings:
user $(umask 077 && tar -caf $HOME/gnupg-backup_`date +%Y%m%d_%H%M%S`.tar.xz -C ${HOME} .gnupg)tar: .gnupg/S.gpg-agent.extra: socket ignored tar: .gnupg/S.gpg-agent.browser: socket ignored tar: .gnupg/S.gpg-agent: socket ignored tar: .gnupg/S.gpg-agent.ssh: socket ignored
umask is used to restrict access to the backup file. Note the parenthesis - the command is running in a subshell to avoid resetting umask afterwards. It is safe to ignore the warnings regarding ignored sockets above.
When the homedir is not in ${HOME}/.gnupg, be sure to adjust the end of the tar command above accordingly!
When using a customized GnuPG configuration, it is possible that the keyring is not stored in GnuPG's homedir. In this case, it is recommend to check the output of the following command:
user $gpg --list-secret-keys/home/larry/.gnupg/pubring.kbx
------------------------------
sec rsa2048 2016-01-28 [SC] [expires: 2020-01-27]
9AAC460432EA972BD950D9C6F76839562DD99092
uid [ultimate] Larry the Cow <larry@the-cow.de>
ssb rsa2048 2016-01-28 [E] [expires: 2018-01-27]
Step 3: Update gpg.conf
This step is optional but recommended: Make sure the gpg.conf file (usually located in ${HOME}/.gnupg/gpg.conf) contains the following settings:
${HOME}/.gnupg/gpg.conf# Assume that command line arguments are given as UTF8 strings.
utf8-strings
# when outputting certificates, view user IDs distinctly from keys:
fixed-list-mode
# long keyids are more collision-resistant than short keyids (it's trivial to make a key
# with any desired short keyid)
# NOTE: this breaks kmail gnupg support!
keyid-format 0xlong
# when multiple digests are supported by all recipients, choose the strongest one:
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
# preferences chosen for new keys should prioritize stronger algorithms:
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
# You should always know at a glance which User IDs GPG thinks are legitimately bound to
# the keys in the keyring:
verify-options show-uid-validity
list-options show-uid-validity
# include an unambiguous indicator of which key made a signature:
# (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)
# (and http://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html)
sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g
# when making an OpenPGP certification, use a stronger digest than the default SHA1:
cert-digest-algo SHA512
s2k-cipher-algo AES256
s2k-digest-algo SHA512
Step 4: Create a new master key
With the configuration from above in place, a new master key can be created. The master key will only have the capability "Certify" and is only needed when the key is modified or when you sign someone else's key. Separating capabilities will allow you to split master key from subkeys so that you can keep master key in a secure, air-gapped, environment for example.
user $gpg --expert --full-generate-keygpg (GnuPG) 2.2.9; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(9) ECC and ECC
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(13) Existing key
Your selection? 8
Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Sign Certify Encrypt
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? s
Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify Encrypt
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? e
Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? q
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
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) 2021-01-01
Key expires at Fri Jan 1 12:00:00 2021 CET
Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: Larry the Cow
Email address: larry@gentoo.org
Comment:
You selected this USER-ID:
"Larry the Cow <larry@gentoo.org"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key 5C6A132050668578 marked as ultimately trusted
gpg: revocation certificate stored as '/home/larry/.gnupg/openpgp-revocs.d/EFA6F1BD36FA9FDE3C0432975C6A132050668578.rev'
public and secret key created and signed.
pub rsa4096 2019-05-08 [C] [expires: 2021-01-01]
EFA6F1BD36FA9FDE3C0432975C6A132050668578
uid Larry the Cow <larry@gentoo.org>Step 5: Create subkeys
To be able to sign commits or push signed to any Gentoo repository, we will need a subkey with "Sign" capability. Therefore we will create a RSA key with keysize of 2048-bits and a validity of 1 year (note that we will use the previous shown fingerprint when we specify which key we want to edit):
user $gpg --expert --edit-key EFA6F1BD36FA9FDE3C0432975C6A132050668578gpg (GnuPG) 2.2.9; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2020-01-27
sec rsa4096/5C6A132050668578
created: 2018-08-27 expires: 2021-01-01 usage: C
trust: ultimate validity: ultimate
[ultimate] (1). Larry the Cow <larry@the-cow.de>
gpg> addkey
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(12) ECC (encrypt only)
(13) Existing key
Your selection? 4
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
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) 2020-01-01
Key expires at Wed Jan 1 12:00:00 2020 CET
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
sec rsa4096/5C6A132050668578
created: 2019-05-08 expires: 2021-01-01 usage: C
trust: ultimate validity: ultimate
ssb rsa2048/3B3FD31FA2609F1F
created: 2019-05-08 expires: 2020-01-01 usage: S
[ultimate] (1). Larry the Cow <larry@gentoo.org>
gpg> q
Save changes? (y/N) y
A keysize of 2048-bits was selected instead of 4096-bits; signing with a 4096-bit key is much slower than using a 2048-bits key while the security improvement in using a 4096-bits key is minimal[1].
An expiration date in 1 year to enable something like a dead man's switch, which is a form of fail-safe.
An ECC subkey can be created instead of an RSA subkey for signing. But as best practice it is recommended to keep RSA keys for now because using ECC would cause trouble for anyone outside Gentoo who wants to verify stuff you signed if they don't have ECC support yet.
But don't worry: The good thing about about OpenPGP is, that it allows you to switch to ECC subkeys in future if ECC support becomes a standard without the need to re-create a new complete new key so you won't lose your gained Web of Trust.Now it is also recommended that you will create a subkey you can use for encryption. This will allow you to encrypt files against your OpenPGP key and allow others to send you encrypted messages for example:
user $gpg --expert --edit-key EFA6F1BD36FA9FDE3C0432975C6A132050668578gpg (GnuPG) 2.2.9; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa4096/5C6A132050668578
created: 2019-05-08 expires: 2021-01-01 usage: C
trust: ultimate validity: ultimate
ssb rsa2048/3B3FD31FA2609F1F
created: 2019-05-08 expires: 2020-01-01 usage: S
[ultimate] (1). Larry the Cow <larry@gentoo.org>
gpg> addkey
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(12) ECC (encrypt only)
(13) Existing key
Your selection? 6
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
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) 2020-01-01
Key expires at Wed Jan 1 12:00:00 2020 CET
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
sec rsa4096/5C6A132050668578
created: 2019-05-08 expires: 2021-01-01 usage: C
trust: ultimate validity: ultimate
ssb rsa2048/3B3FD31FA2609F1F
created: 2019-05-08 expires: 2020-01-01 usage: S
ssb rsa2048/B08BA148BB85CE7B
created: 2019-05-08 expires: 2020-01-01 usage: E
[ultimate] (1). Larry the Cow <larry@gentoo.org>
gpg> q
Save changes? (y/N) yStep 6: Add a subkey for authentication
This example alternatively shows how to create cv25519 key. Note that cv25519 is not supported by Nitrokey Pro 2; if you want to store your key on the device, you should use RSA (option 8) instead.
This step is optional. If you want to use your OpenPGP key for SSH authentication as well, it is recommended to add a dedicated subkey just for authentication:
user $gpg --expert --edit-key EFA6F1BD36FA9FDE3C0432975C6A132050668578gpg (GnuPG) 2.2.9; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa4096/5C6A132050668578
created: 2019-05-08 expires: 2021-01-01 usage: C
trust: ultimate validity: ultimate
ssb rsa2048/3B3FD31FA2609F1F
created: 2019-05-08 expires: 2020-01-01 usage: S
ssb rsa2048/B08BA148BB85CE7B
created: 2019-05-08 expires: 2020-01-01 usage: E
[ultimate] (1). Larry the Cow <larry@the-cow.de>
gpg> addkey
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(12) ECC (encrypt only)
(13) Existing key
Your selection? 11
Possible actions for a ECDSA/EdDSA key: Sign Authenticate
Current allowed actions: Sign
(S) Toggle the sign capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? s
Possible actions for a ECDSA/EdDSA key: Sign Authenticate
Current allowed actions:
(S) Toggle the sign capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? a
Possible actions for a ECDSA/EdDSA key: Sign Authenticate
Current allowed actions: Authenticate
(S) Toggle the sign capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? q
Please select which elliptic curve you want:
(1) Curve 25519
(3) NIST P-256
(4) NIST P-384
(5) NIST P-521
(6) Brainpool P-256
(7) Brainpool P-384
(8) Brainpool P-512
(9) secp256k1
Your selection? 1
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) 2020-01-01
Key expires at Wed Jan 1 12:00:00 2020 CET
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
sec rsa4096/5C6A132050668578
created: 2019-05-08 expires: 2021-01-01 usage: C
trust: ultimate validity: ultimate
ssb rsa2048/3B3FD31FA2609F1F
created: 2019-05-08 expires: 2020-01-01 usage: S
ssb rsa2048/B08BA148BB85CE7B
created: 2019-05-08 expires: 2020-01-01 usage: E
ssb ed25519/4286BF690A6B34B8
created: 2019-05-08 expires: 2020-01-01 usage: A
[ultimate] (1). Larry the Cow <larry@gentoo.org>
gpg> q
Save changes? (y/N) ySummary
The creation of a new, GLEP 63-compliant OpenPGP key is now completed. Let's view the new key:
user $gpg --list-key EFA6F1BD36FA9FDE3C0432975C6A132050668578pub rsa4096/0x5C6A132050668578 2019-05-08 [C] [expires: 2021-01-01]
EFA6F1BD36FA9FDE3C0432975C6A132050668578
uid [ultimate] Larry the Cow <larry@gentoo.org>
sub rsa2048/0x3B3FD31FA2609F1F 2019-05-08 [S] [expires: 2020-01-01]
sub rsa2048/0xB08BA148BB85CE7B 2019-05-08 [E] [expires: 2020-01-01]
sub ed25519/0x4286BF690A6B34B8 2019-05-08 [A] [expires: 2020-01-01]
Next steps
Submit the new key to the keyserver
After the newly generated key has been configured, the key should be published to the Gentoo keyserver.
Check the key using app-crypt/glep63-check before proceeding!
Normally it should take no more than 20 minutes for the newly uploaded key to propagate to git.gentoo.org. If the new key is still rejected after that time, please ping Infra (in the #gentoo-infra (webchat) IRC channel) to investigate.
The Gentoo keyserver is restricted to accepting uploads from authorized Gentoo hosts. A convenience key upload script is provided on the developer machine:
user $gpg --export EFA6F1BD36FA9FDE3C0432975C6A132050668578 | ssh dev.gentoo.org /usr/local/bin/openpgp-key-uploadgpg: keybox '/tmp/tmp.GVbNMzf01U/pubring.kbx' created gpg: key 5C6A132050668578: 21 signatures not checked due to missing keys gpg: /tmp/tmp.GVbNMzf01U/trustdb.gpg: trustdb created gpg: key 5C6A132050668578: public key "Larry the Cow <larry@gentoo.org>" imported gpg: Total number processed: 1 gpg: imported: 1 gpg: no ultimately trusted keys found gpg: sending key 5C6A132050668578 to hkps://keys.gentoo.org
Non-developers cannot upload their keys to the Gentoo keyserver.
It is recommended to also upload the new key to a public keyserver. This will allow others to easily discover it and send encrypted mails. A privacy-friendly and stable keyserver is keys.openpgp.org:
user $gpg --export-options export-minimal --export EFA6F1BD36FA9FDE3C0432975C6A132050668578 | curl -T - https://keys.openpgp.orgKey successfully uploaded. Proceed with verification here: https://keys.openpgp.org/upload/...
Do not forget to visit the link displayed in the output of the previous command and proceed with verification or the key will not be available on the keyserver!
Updating LDAP
The next step is to update the LDAP entry on woodpecker, so that the new key will be recognized and is allowed to push to Gentoo repositories. See this FAQ entry for more details.
Split key
TODO: Add information how to split key so that you can keep master key on an air-gapped system for example and/or use keycard, YubiKey...
Fix an existing key
If you already have an existing OpenPGP key and maybe want to keep the received signatures (i.e. Web of Trust status), it maybe possible to adjust the existing key to become GLEP 63-compliant. The following guide provides some examples non-compliant keys and how they can be fixed:
Assume the key looks like the following:
user $gpg --list-key 9AAC460432EA972BD950D9C6F76839562DD99092pub rsa2048/0xF76839562DD99092 2016-01-28 [SC] [expires: 2026-01-25]
9AAC460432EA972BD950D9C6F76839562DD99092
uid [ultimate] Larry the Cow <larry@the-cow.de>
sub rsa2048/0x594CA20866E92013 2016-01-28 [E]
sub rsa1024/0x5AD7FB3114AA19AD 2016-01-28 [SA] [expires: 2020-01-27]
What's wrong with this key? Let's assume today's date is 2019-08-27:
- This key violates
2. Signing subkey that is different from the primary key, and does not have any other capabilities enabled
because the subkey (0x5AD7FB3114AA19AD) has both, "Sign" and "Authenticate" capability enabled. - This key violates
3. Primary key and the signing subkey are both of type EITHER:\na) RSA, >=2048 bits (OpenPGP v4 key format or later only),
because the signing subkey has a keysize <2048 bits. - This key violates
4. Expiration date on key and all subkeys set to no more than 900 days into the future.
because the master key doesn't expire within next 900 days and the encryption subkey (0x594CA20866E92013) has no expiration date set at all. - This key violates
6. UID using your @gentoo.org e-mail included in the key.
because Larry the Cow hasn't added his Gentoo UID (@gentoo.org address).
Replace an invalid subkey
To fix a violation of requirement #2 and #3, the violating subkey must be replaced with a new subkey. Because a subkey cannot be removed, the offending subkey must be marked as expired, and a new subkey added.
user $gpg --expert --edit-key 9AAC460432EA972BD950D9C6F76839562DD99092gpg (GnuPG) 2.2.9; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa2048/0xF76839562DD99092
created: 2016-01-28 expires: 2026-01-25 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/0x594CA20866E92013
created: 2016-01-28 expires: never usage: E
ssb rsa1024/0x5AD7FB3114AA19AD
created: 2016-01-28 expires: 2020-01-27 usage: SA
[ultimate] (1). Larry the Cow <larry@the-cow.de>
gpg> key 2
sec rsa2048/0xF76839562DD99092
created: 2016-01-28 expires: 2026-01-25 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/0x594CA20866E92013
created: 2016-01-28 expires: never usage: E
ssb* rsa1024/0x5AD7FB3114AA19AD
created: 2016-01-28 expires: 2020-01-27 usage: SA
[ultimate] (1). Larry the Cow <larry@the-cow.de>
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) 1d
Key expires at Wed 28 Aug 2019 08:23:54 PM CEST
Is this correct? (y/N) y
sec rsa2048/0xF76839562DD99092
created: 2016-01-28 expires: 2026-01-25 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/0x594CA20866E92013
created: 2016-01-28 expires: never usage: E
ssb* rsa1024/0x5AD7FB3114AA19AD
created: 2016-01-28 expires: 2019-08-28 usage: SA
[ultimate] (1). Larry the Cow <larry@the-cow.de>
gpg> save
The violating key will expire tomorrow.
Next add the new, valid signing subkey:
user $gpg --expert --edit-key 9AAC460432EA972BD950D9C6F76839562DD99092gpg (GnuPG) 2.2.9; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa2048/0xF76839562DD99092
created: 2016-01-28 expires: 2026-01-25 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/0x594CA20866E92013
created: 2016-01-28 expires: never usage: E
ssb rsa1024/0x5AD7FB3114AA19AD
created: 2016-01-28 expires: 2019-08-28 usage: SA
[ultimate] (1). Larry the Cow <larry@the-cow.de>
gpg> addkey
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(12) ECC (encrypt only)
(13) Existing key
Your selection? 4
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
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) 2020-01-01
Key expires at Wed 1 Jan 2020 12:00:00 PM CET
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
sec rsa2048/0xF76839562DD99092
created: 2016-01-28 expires: 2026-01-25 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/0x594CA20866E92013
created: 2016-01-28 expires: never usage: E
ssb rsa1024/0x5AD7FB3114AA19AD
created: 2016-01-28 expires: 2019-08-28 usage: SA
ssb rsa2048/0x0B45B2392BA396A2
created: 2018-08-27 expires: 2020-01-01 usage: S
[ultimate] (1). Larry the Cow <larry@the-cow.de>
gpg> q
Save changes? (y/N) y
GnuPG will always use the most recent, usable subkey. Because there's a newer unexpired subkey with signing capability, the previous subkey will no longer being used.
In this example we have disabled a subkey which could have been used for authentication. If you used this key for authentication don't forget to add a new subkey for authentication (see step 6) and update your authorized_keys file/LDAP or you will lose access to systems where you previously used this key for authentication.
Invalid expiration date
An OpenPGP key can have an expiration date for the master key itself and a unique/Independent expiration date for each subkey. In the example above, we have to fix two expiration dates:
- For the master key (currently set to 2026-01-25 which violates the maximum expiration date of 900 days)
- For the encryption key (doesn't have an expiration date at the moment but GLEP 63 requires that every key has an expiration date set)
To fix this, edit key and set a new expiration date:
user $gpg --expert --edit-key 9AAC460432EA972BD950D9C6F76839562DD99092gpg (GnuPG) 2.2.9; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa2048/0xF76839562DD99092
created: 2016-01-28 expires: 2026-01-25 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/0x594CA20866E92013
created: 2016-01-28 expires: never usage: E
ssb rsa1024/0x5AD7FB3114AA19AD
created: 2016-01-28 expired: 2018-08-28 usage: SA
ssb rsa2048/0x0B45B2392BA396A2
created: 2018-08-27 expires: 2020-01-01 usage: S
[ultimate] (1). Larry the Cow <larry@the-cow.de>
gpg> expire
Changing expiration time for the primary key.
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) 2021-01-01
Key expires at Fri Jan 1 12:00:00 2021 CET
Is this correct? (y/N) y
sec rsa2048/0xF76839562DD99092
created: 2016-01-28 expires: 2021-01-01 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/0x594CA20866E92013
created: 2016-01-28 expires: never usage: E
ssb rsa1024/0x5AD7FB3114AA19AD
created: 2016-01-28 expired: 2018-08-28 usage: SA
ssb rsa2048/0x0B45B2392BA396A2
created: 2018-08-27 expires: 2020-01-01 usage: S
[ultimate] (1). Larry the Cow <larry@the-cow.de>
gpg> save
Changing the expiration date for the encryption subkey (0x594CA20866E92013) works the same; just be sure to select the correct subkey:
user $gpg --expert --edit-key 9AAC460432EA972BD950D9C6F76839562DD99092gpg (GnuPG) 2.2.9; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2021-02-12
sec rsa2048/0xF76839562DD99092
created: 2016-01-28 expires: 2021-01-01 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/0x594CA20866E92013
created: 2016-01-28 expires: never usage: E
ssb rsa1024/0x5AD7FB3114AA19AD
created: 2016-01-28 expired: 2018-08-28 usage: SA
ssb rsa2048/0x0B45B2392BA396A2
created: 2018-08-27 expires: 2020-01-01 usage: S
[ultimate] (1). Larry the Cow <larry@the-cow.de>
gpg> key 1
sec rsa2048/0xF76839562DD99092
created: 2016-01-28 expires: 2021-01-01 usage: SC
trust: ultimate validity: ultimate
ssb* rsa2048/0x594CA20866E92013
created: 2016-01-28 expires: never usage: E
ssb rsa1024/0x5AD7FB3114AA19AD
created: 2016-01-28 expired: 2018-08-28 usage: SA
ssb rsa2048/0x0B45B2392BA396A2
created: 2018-08-27 expires: 2020-01-01 usage: S
[ultimate] (1). Larry the Cow <larry@the-cow.de>
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) 2020-01-01
Key expires at Wed Jan 1 12:00:00 2020 CET
Is this correct? (y/N) y
sec rsa2048/0xF76839562DD99092
created: 2016-01-28 expires: 2021-01-01 usage: SC
trust: ultimate validity: ultimate
ssb* rsa2048/0x594CA20866E92013
created: 2016-01-28 expires: 2020-01-01 usage: E
ssb rsa1024/0x5AD7FB3114AA19AD
created: 2016-01-28 expired: 2018-08-28 usage: SA
ssb rsa2048/0x0B45B2392BA396A2
created: 2018-08-27 expires: 2020-01-01 usage: S
[ultimate] (1). Larry the Cow <larry@the-cow.de>
gpg> save
It is possible to change the expiration date for both keys in one step. This guide used two steps to demonstrate how to switch/select keys separately.
Adding missing Gentoo UID
GLEP 63 requires that the UID of the key is your Gentoo e-mail address. Let's add one to our key:
user $gpg --expert --edit-key 9AAC460432EA972BD950D9C6F76839562DD99092gpg (GnuPG) 2.2.9; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa2048/0xF76839562DD99092
created: 2016-01-28 expires: 2021-01-01 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/0x594CA20866E92013
created: 2016-01-28 expires: 2020-01-01 usage: E
ssb rsa1024/0x5AD7FB3114AA19AD
created: 2016-01-28 expired: 2018-08-28 usage: SA
ssb rsa2048/0x0B45B2392BA396A2
created: 2018-08-27 expires: 2020-01-01 usage: S
[ultimate] (1). Larry the Cow <larry@the-cow.de>
gpg> adduid
Real name: Larry the Cow
Email address: larry@gentoo.org
Comment:
You selected this USER-ID:
"Larry the Cow <larry@gentoo.org>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
sec rsa2048/0xF76839562DD99092
created: 2016-01-28 expires: 2021-02-12 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/0x594CA20866E92013
created: 2016-01-28 expires: 2020-01-01 usage: E
ssb rsa1024/0x5AD7FB3114AA19AD
created: 2016-01-28 expired: 2020-01-01 usage: SA
ssb rsa2048/0x0B45B2392BA396A2
created: 2019-08-27 expires: 2020-01-01 usage: S
[ultimate] (1) Larry the Cow <larry@the-cow.de>
[ unknown] (2). Larry the Cow <larry@gentoo.org>
gpg> save
Summary
Now that we have fixed all issues, our now GLEP 63-compliant key looks like
user $gpg --list-key 9AAC460432EA972BD950D9C6F76839562DD99092pub rsa2048/0xF76839562DD99092 2016-01-28 [SC] [expires: 2021-02-12]
9AAC460432EA972BD950D9C6F76839562DD99092
uid [ultimate] Larry the Cow <larry@gentoo.org>
uid [ultimate] Larry the Cow <larry@the-cow.de>
sub rsa2048/0x594CA20866E92013 2016-01-28 [E] [expires: 2019-08-27]
sub rsa2048/0x0B45B2392BA396A2 2018-08-27 [S] [expires: 2019-08-27]Don't forget to submit the updated key to the keyserver(s) so that the Gentoo project infrastructure can discover the changes.