5

I would like to have a GnuPG identity that I can use both for a long time (so that I can build a wide web of trust) and immediately with as many people as possible. As of today, the second goal is best met with an RSA (or DSA) key, because it is supported even by very old versions of GnuPG. However, regarding the first, long-term goal, I am personally more in favor of an ECC key. Thus, to achieve both goals, my idea was to simultaneously maintain both an RSA and an ECC key (with the same UIDs) and let the former expire once support for ECC is widespread enough.

At the level of the master keys, this should be no problem: I can cross-sign each key with the other, so that signatures on one key also contribute to the web of trust of the other key. Contacts can then sign both keys if they support both, or only the RSA key if they cannot handle ECC yet.

For ease of use, I would like to have only one set of subkeys, because I would like to store them on a single smart card. Thus, my idea was to share the same set of subkeys among the two master keys. This should allow me to decrypt, sign, and authenticate for both master keys with just one set of subkeys, which would avoid the hassle of choosing the right key for each communication exchange.

Q: Is my idea of sharing subkeys reasonable and possible, or have I overlooked some design aspects of GnuPG that prevent this or raise practical problems?

As far as I understand it technically, what makes a key a subkey is basically a certificate by the master key that it belongs to the master key. Such certificates (or signatures) can be extracted from a key with

gpg --export-secret-keys <your keyid> | gpgsplit

I found a quite old post that describes importing a subkey into an existing master key, but could not apply it to my purpose because I do not know how to manually issue the "subkey certificate" for the master key for which the subkey was not originally created.

More specifically, I exported and decomposed each key into a directory using the command above. Then, I have the subkey and the "subkey certificate" for the first key in key1/000004-007.secret_subkey and key1/000005-002.sig, respectively. To import this subkey to the second master key, I tried the following three approaches, combining and importing the result with

cat key2/* > key2/key.gpg
gpg --import key2/key.gpg

after each approach:

  1. Copy the subkey without modification (i.e., cp key1/000004-007.secret_subkey key2/), hoping that GnuPG would ask me if it should issue a certificate at import.

  2. In addition to 1, copy the certificate without modification (i.e., cp key1/00000{4-007.secret_subkey,5-002.sig} key2/), hoping that GnuPG would ask me if it should replace the certificate by the first key through one issued by the second key.

  3. In addition to 2, modify the certificate by replacing the fingerprint of the first key with the fingerprint of the second key, hoping that GnuPG would discard the forged certificate and ask me if it should issue a valid one instead.

In all cases, neither the first nor the second key were in my keyring before the import. The result is always the same, though:

gpg: key 0x<id of key2>: secret key imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
gpg:  secret keys unchanged: 1

Q: How can I issue a valid certificate for the subkey with the second master key, so that I can import the subkey to this master key?

akku
  • 55
  • 4
  • I have not tried this, so I'm not posting an answer yet. Does GnuPG generally not recognize the subkey or are you only missing the certificate? In latter case, modifying the key's validity period should create a new signature. You can also reset the expiry date to never afterwards if you want to. – Jens Erat Mar 25 '17 at 09:23
  • @JensErat I have edited my question to be more detailed about my approach so far and where I fail. I hope it did not become lengthy; I just wanted to spare others work I have already tried unsuccessfully. – akku Mar 25 '17 at 10:59
  • I just found [this answer](https://security.stackexchange.com/a/62480/92316) to a similar question. Directly manipulating the keyring files and using a 15-year-old version of GnuPG at some point to skip some validity checks seemed to do the trick. I will try this next and report the outcome. – akku Mar 25 '17 at 13:53
  • Did you try fiddling with the subkey's validity period? As the expiration date is stored in the subkey's binding signature, GnuPG _must_ write one (or fail completely) if it does not exist. – Jens Erat Mar 27 '17 at 18:23

0 Answers0