2
$\begingroup$

I have few sub-questions

  1. Do secret keys get expired, or just the public key gets expired?
  2. Do I have to back up the master sec key each time I renew it?

    For an example:

    Let's say I generate gpg keypair and ssb for signing, encrypting, and a revoked certificate. And I backup the master sec key, revoked certificate and place them somewhere safe, and remove master sec from the key-ring.

    Then the pub and sub keys get expire so, I get a copy of master sec key from the safe place and re-import it to the key-ring for the sake of key renewing process. After that, can I just safely remove and delete that copy of master sec key from the key-ring? If so, is master sec key that I saved at the first place aware of these new renewed pub and sec keys, shouldn't I re-backup the sec key after using it for renewing process? and replace to the old sec key that I saved in the safe place?

    What would happen If I generate a new ssb key for authentication after that renewal process? Is my master sec key that I saved in the safe place at the first aware of the newly generated ssb key? If so, how is my revoked certificate affect to these new keys? (new ssb keys, and renewed pub keys)

  3. Do I have to re-generate revoke certificates each time after I renew the secret key, or can I just use the previously generated revoke certificate after renewing the key?

    For an example:

    First I generate a seckey and a revoked certificate, then I generate ssb key.

    Then sec and ssb both get expire and I renew it for a next 6 months, then I lose my master sec key, so Is my revoke certificate still valid? can I revoke the key by importing the revoked certificate?

$\endgroup$
1
$\begingroup$

I am not an expert in cryto or GNUPG/PGP. Nevertheless, as I understand the question(s), it is my belief I can answer all of it from experience.

I have been experimenting with making keys and various arrangements of primary-sub key setups. As such, I have encountered the arrangements you've described. I am not going to address best practices. (With one slight exception about the revocation cert.) Looking for those is why I found this question in the first place.

When you make a GPG/PGP key, it has one, exactly, primary key. It begins with exactly one subkey as well, outside of exceptional intentions on your part. You can add subkeys at will with a variety of expiry times, including none, and for single or multiple purposes. You can also control the purpose(s) of the primary key during creation. The one point to remember in all the purposes is that ONLY the primary key can have the certification [C] purpose, and that means that only the primary key can be used to "sign" other keys.

Part of generating a new key, in the background that you don't notice, is the signing of its UIDs and subkey(s) by the primary key. (if you use the --check-signatures option to GNUPG it will show that self-signing on each UID and subkey.) The consequence of this is that you must have the primary secret key in the keyring to make a new subkey of the primary key, add an UID, or perform almost any other action that modifies any of the information in the key.

Sample of output from --check-signatures:

pub   ed25519/ED3B0F88D23F1094 2003-12-23 [C] [expires: 2004-06-23]
    Key fingerprint = 255E 5FD6 CDCD C8D8 AEFF  084D ED3B 0F88 D23F 1094
uid                 [ultimate] GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sig!3        ED3B0F88D23F1094 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sig!3        84E7CCFEFDD8A4BA 2003-12-23 never       GNUPG Sample <gnupg.sample@example.com>
uid                 [ultimate] Alternate GitKey <gitkey.alternate.identity@example.com>
sig!3        ED3B0F88D23F1094 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sig!3        84E7CCFEFDD8A4BA 2003-12-23 never       GNUPG Sample <gnupg.sample@example.com>
sub   ed25519/FB9E26F42B61D3B2 2003-12-23 [S] [expires: 2003-12-30]
    Key fingerprint = 7DEE 3DDC EDEE 8520 6F27  4B09 FB9E 26F4 2B61 D3B2
sig!         ED3B0F88D23F1094 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sub   rsa4096/F1AB53F9F149D506 2003-12-23 [A] [expires: 2003-12-30]
    Key fingerprint = F8CC 794F 1D25 0E81 48E5  A48D F1AB 53F9 F149 D506
sig!         ED3B0F88D23F1094 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sub   ed25519/E4FEDB7B26371025 2003-12-23 [A] [expires: 2004-06-23]
    Key fingerprint = 2133 B4F2 0D9D 64FD EFCC  5709 E4FE DB7B 2637 1025
sig!         ED3B0F88D23F1094 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sub   rsa4096/F88391D0F627D690 2003-12-23 [S] [expires: 2003-12-30]
    Key fingerprint = 8FFF 298E 8CA3 B392 3CDA  0ED2 F883 91D0 F627 D690
sig!         ED3B0F88D23F1094 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sub   ed25519/8EDB7F8917E70B8D 2003-12-23 [S] [expires: 2004-06-23]
    Key fingerprint = 8552 A5C1 0027 18E4 E8CA  B386 8EDB 7F89 17E7 0B8D
sig!         ED3B0F88D23F1094 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>

Notice that the ID of the primary key ED3B0F88D23F1094 has signed (sig!) every UID and every subkey. A third-party signing the key, here 84E7CCFEFDD8A4BA, only signs the UIDs. (They could chose to sign only selected ones if they hadn't verified all of the UIDs.)

The same key after a, contrived mixture, of expiry date renewals. The renewals were done on 2004-07-01 with the sig check done date 2004-11-01.

pub   ed25519/ED3B0F88D23F1094 2003-12-23 [C] [expires: 2004-12-31]
    Key fingerprint = 255E 5FD6 CDCD C8D8 AEFF  084D ED3B 0F88 D23F 1094
uid                 [ultimate] GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sig!3        ED3B0F88D23F1094 2004-07-01 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sig!3        02A69DB001C11351 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
uid                 [ultimate] Alternate GitKey <gitkey.alternate.identity@example.com>
sig!3        ED3B0F88D23F1094 2004-07-01 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sig!3        02A69DB001C11351 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sub   ed25519/FB9E26F42B61D3B2 2003-12-23 [S] [expired: 2004-09-30]
    Key fingerprint = 7DEE 3DDC EDEE 8520 6F27  4B09 FB9E 26F4 2B61 D3B2
sig!         ED3B0F88D23F1094 2004-07-01 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sub   rsa4096/F1AB53F9F149D506 2003-12-23 [A] [expired: 2003-12-30]
    Key fingerprint = F8CC 794F 1D25 0E81 48E5  A48D F1AB 53F9 F149 D506
sig!         ED3B0F88D23F1094 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sub   ed25519/E4FEDB7B26371025 2003-12-23 [A] [expires: 2005-07-01]
    Key fingerprint = 2133 B4F2 0D9D 64FD EFCC  5709 E4FE DB7B 2637 1025
sig!         ED3B0F88D23F1094 2004-07-01 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sub   rsa4096/F88391D0F627D690 2003-12-23 [S] [expired: 2003-12-30]
    Key fingerprint = 8FFF 298E 8CA3 B392 3CDA  0ED2 F883 91D0 F627 D690
sig!         ED3B0F88D23F1094 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sub   ed25519/8EDB7F8917E70B8D 2003-12-23 [S] [expires: 2004-12-28]
    Key fingerprint = 8552 A5C1 0027 18E4 E8CA  B386 8EDB 7F89 17E7 0B8D
sig!         ED3B0F88D23F1094 2004-07-01 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>

Here the potential for divergent expiry dates can be seen. The primary key is 2004-12-31, two of the subkeys are 2003-12-30 (their original expiry and not renewed) while the other 3 subkeys have been renewed for different times, including one that has since expired again. Bear in mind that while there can be a variety of dates on the key and its subkeys, if the primary key expires, the subkeys are no longer valid, expired or not.

No changes to the key, but effective date of 2005-01-01:

pub   ed25519/ED3B0F88D23F1094 2003-12-23 [C] [expired: 2004-12-31]
    Key fingerprint = 255E 5FD6 CDCD C8D8 AEFF  084D ED3B 0F88 D23F 1094
uid                 [ expired] GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sig!3        ED3B0F88D23F1094 2004-07-01 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
Preferred keyserver: hkp://pool.sks-keyservers.net
sig!3        02A69DB001C11351 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
uid                 [ expired] Alternate GitKey <gitkey.alternate.identity@example.com>
sig!3        ED3B0F88D23F1094 2004-07-01 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sig!3        02A69DB001C11351 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sub   ed25519/FB9E26F42B61D3B2 2003-12-23 [S] [expired: 2004-09-30] passone
    Key fingerprint = 7DEE 3DDC EDEE 8520 6F27  4B09 FB9E 26F4 2B61 D3B2
sig!         ED3B0F88D23F1094 2004-07-01 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sub   rsa4096/F1AB53F9F149D506 2003-12-23 [A] [expired: 2003-12-30]
    Key fingerprint = F8CC 794F 1D25 0E81 48E5  A48D F1AB 53F9 F149 D506
sig!         ED3B0F88D23F1094 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sub   ed25519/E4FEDB7B26371025 2003-12-23 [A] [expired: 2005-07-01]
    Key fingerprint = 2133 B4F2 0D9D 64FD EFCC  5709 E4FE DB7B 2637 1025
sig!         ED3B0F88D23F1094 2004-07-01 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sub   rsa4096/F88391D0F627D690 2003-12-23 [S] [expired: 2003-12-30]
    Key fingerprint = 8FFF 298E 8CA3 B392 3CDA  0ED2 F883 91D0 F627 D690
sig!         ED3B0F88D23F1094 2003-12-23 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>
sub   ed25519/8EDB7F8917E70B8D 2003-12-23 [S] [expired: 2004-12-28]
    Key fingerprint = 8552 A5C1 0027 18E4 E8CA  B386 8EDB 7F89 17E7 0B8D
sig!         ED3B0F88D23F1094 2004-07-01 never       GNUPG Sample GitKey <gitkey.gnupg.sample@example.com>

The third subkey, E4FEDB7B26371025, still has 6 months until it expires, yet it is listed as expired because the primary key is expired. A renewal for the primary key would make the third subkey again valid without needing a new expiry date (for 6 months anyway).

The primary key is the key, or the "certificate" (depending on the terminology someone may choose, and I'm not involved in crypto to know all the proper terms). Any, and all, subkeys created, and their expiry are known to, and recorded in, the primary key. When you export the pub or the sec it will include all the UIDs and subkeys, as they exist at the time of export. (The pub is the same as the sec with the all the secret keys stripped, but all other data remains.) When you export any of the subkeys the sub or ssb file will contain all the information about that subkey and all the data about the primary key. An export of ssb will have the secret key for the subkey included, and the secret key for the primary key excluded. The sub will have the same information as the ssb without any of the secret keys. If, per chance, you were to export all the subkeys in one sub file it would be bit-identical to the pub file from the same key. The one important point to remember, relative to your question, is that the sec, ssb, pub, and sub files all contain the information as it exists at the momemt you do the export!

After doing a refresh on the expiry for the primary key, any subkey, or all the subkeys you will have to re-export every sub, ssb, pub, and sec and re-publish them to the keyserver if you use one. Of special concern is that you also have to update the sec you have in a safe place. You also need to make a new paperkey if you use that system. So, direct answer, you cannot delete the secret key from the keyring until you make a new export of it. And, yes you should re-backup the sec key and replace the old one in the safe place.

Things are basically the same for when you add a new subkey. If you have exported sub and ssb files that only have one key in them, then they do not need to be replaced. If you have exported sub and ssb intending for them to have all the subkeys, then those do need to be replaced. In either case the sec file needs to be re-exported and replaced in the save place, and the pub needs to be re-published (or nobody will know the new subkey exist and won't be able to use it).

In all that exporting, the one thing you don't need to update is the revocation certificate. That is a seperate certificate "signed" by the primary key. A revoc cert generated a decade ago will still revoke a cert renewed for 50 years 1 second ago, and even if a couple dozen new subkeys have been added. Without a valid primary key, all the subkeys, whenever made, are also not valid. (This is where I touch on what I understand about best practice just a bit.) The revoc cert generated at key creation is an emergency measure. If your loose your key, or the passphrase, and have no other option, then that cert is the one to use. For all other cases, where you still have use of the primary private key, you should generate a new revocation certificate, including the reason for revocation. If the key has been compromised, or you've decided to upgrade to a different strength key, etc., adding that information into the newly generated revoc cert allows others that rely on your published key(s) to not only know that it's no longer valid, but what they need to do about it, including finding your new key if you have made one.

The situation where you loose the master sec key, or its password, is the reason for creating the generic revoke certificate when making the primary key rather than waiting for the user to requset one. Sometimes it's too late.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.