3

Following the Debian tutorial on subkeys I like to create a keyring with a primary key (SC) and two subkeys (E and S) and then export and remove the secret primary key. However I struggle to re-import the exported secret key in case I want to revoke and renew the subkeys.

Initial setup with two subkeys

pub  1024R/158C07CE  created: 2015-09-21  expires: never       usage: SC
                     trust: ultimate      validity: ultimate
sub  1024R/588AC467  created: 2015-09-21  expires: never       usage: E
sub  1024R/3637E2AA  created: 2015-09-21  expires: never       usage: S
[ultimate] (1). Foobar

$ gpg -K

sec   1024R/158C07CE 2015-09-21
uid                  Foobar
ssb   1024R/588AC467 2015-09-21
ssb   1024R/3637E2AA 2015-09-21

# sec means the secret is still there

Export primarykey-only, export subkeys-only, remove secret keys, and re-import subkeys

$ gpg --export-secret-keys 158C07CE! > primary.sec
# secret-keys with exclamation mark just exports primary keypair
$ gpg --export-secret-subkeys 158C07CE > subs.sec
$ gpg --delete-secret-keys 158C07CE
$ gpg --import subs.sec
$ gpg -K

sec#  1024R/158C07CE 2015-09-21
uid                  Foobar
ssb   1024R/588AC467 2015-09-21
ssb   1024R/3637E2AA 2015-09-21

# sec# means the secret key is missing (this is what I want)

Now I want to re-import the primary secret key

$ gpg --allow-secret-key-import --import primary.sec

gpg: key 158C07CE: already in secret keyring
gpg: Total number processed: 1
gpg:       secret keys read: 1
gpg:  secret keys unchanged: 1

What? Why?

$ gpg -K

sec#  1024R/158C07CE 2015-09-21
uid                  Foobar
ssb   1024R/588AC467 2015-09-21
ssb   1024R/3637E2AA 2015-09-21

Here is useful Stackexchange article on which keys GPG exports in which case

1 Answer 1

4

GnuPG pre-2.1 (ie. GnuPG 1 and GnuPG 2) cannot merge private keys. There are different ways to scope with that:

  • Install GnuPG 2.1, which finally resolved this limitation.
  • Import the private primary key to a new keyring (--homedir will come in handy for doing so), for revocation you only need the public subkey, no private ones.
  • Use gpgsplit to break up the exported secret keys into the individual packets, and concatenate them again in the right order. This works very well, but requires deeper knowledge of RFC 4880 (OpenPGP).

I'd propose to go with GnuPG 2.1, and if necessary export the private key(s) again and switch back to GnuPG 1 or 2 if you prefer.

4
  • I just noticed the same restriction with sub keypairs too and wondered how I will ever be able to revoke any future subkeys in case I forgot to back up the whole keyring before "degrading" it (removing primary secret key). But as you mentioned already one only requires the public subkey to create revocations which can be imported. What is the motivation behind these restrictions? In some way it appears that GnuPG tries very hard to prevent any accidental or even unnecessary exports,... but, gosh, it's so confusing. Commented Sep 24, 2015 at 18:39
  • "What is the motivation behind these restrictions?" -- If you speak about the restrictions in merging keys before GnuPG 2.1, that's just because nobody implemented it.
    – Jens Erat
    Commented Sep 24, 2015 at 19:22
  • GnuPG was released 16 years ago! Commented Oct 15, 2015 at 13:04
  • 1
    I have this problem on GPG 2.2, so the version alone isn't the problem. Commented Nov 29, 2017 at 10:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .