Issues with primary key & subkeys on different smartcards

[Pete Stephenson]

Hi everyone,

I'm writing in regards to an issue I've run into using GnuPG 2.0.21 on
Windows (the same issue occurs with 2.0.19 in Debian 7 and Ubuntu
Linux 13.04, and I performed the same steps on all three systems to
verify that this wasn't an OS-specific issue). I apologize in advance
for the length of this message, but I thought it better to be more
detailed than less.

Brief background:
I have loaded a primary RSA signing key onto a smartcard ("smartcard
#1"). I have created two RSA subkeys, one for signing and the other
for encrypting, and loaded them onto a second smartcard ("smartcard
#2"). The primary key and its subkeys were generated on the computer
and were later loaded onto the card; they were not generated
internally on the card (I keep a secure, offline backup of the private
keys in case the cards are damaged or lost.).

I wish to have a single private key file in my GnuPG keyring that
includes stubs to the primary key on smartcard #1 and the subkeys on
smartcard #2. This way, if I need to certify a public key belonging to
someone else I will be prompted to insert smartcard #1. If I wish to
sign a message or decrypt an encrypted message sent to me I will be
prompted to insert smartcard #2.

==========

First attempt:

Initial conditions:
1. The public key that contains details about my primary and subkeys
is present in my GnuPG keyring. The private keys are not present in
the GnuPG keyring; they exist only in the offline backup and on the
smartcards.
2. Primary key is on smartcard #1, both subkeys (encryption and
signing) are on smartcard #2.

Expected behavior:
1. I insert smartcard #1, then run "gpg2 --card-status".
2. The details of smartcard #1 is displayed.
3. GnuPG adds a private key stub pointing to smartcard #1.
4. I remove smartcard #1 and insert smartcard #2, then run "gpg2 --card-status".
5. The details of smartcard #2 is displayed.
6. GnuPG adds private key stubs pointing to smartcard #2.
7. Certifying ("signing") someone else's public key requires that I
insert smartcard #1. Signing a message or decrypting an encrypted
message requires that I insert smartcard #2.

Observed behavior:
1. Same as above.
2. Same as above.
3. Same as above.
4. Same as above.
5. Same as above.
6. GnuPG does *not* add private key stubs pointing to smartcard #2.
7. Certifying someone else's public key requires that I insert
smartcard #1, as expected. Signing a message or decrypting an
encrypted message does not prompt for smartcard #2, but instead
results in the following error message:

gpg: secret key parts are not available
gpg: skipped "KEYID": Unusable secret key
gpg: [stdin]: clearsign failed: Unusable secret key

If I start over from the initial conditions and reverse the order of
the cards (i.e. insert smartcard #2 first and run "gpg2
--card-status"), then the stubs for the subkeys get generated but when
I later insert smartcard #1 and run "gpg2 --card-status" then the stub
for the primary key is not created.

==========

Second attempt:

Expected behavior:
1. Add the primary key stub (steps 1-3 from above). This successfully
adds the primary key stub.
2. Run "gpg2 --export-secret-keys KEYID > primary-stub.key"
3. Run "gpg2 --delete-secret-keys KEYID" to delete the private key
component (that is, the stub) from the keyring.
4. Add the subkey stubs (steps 4-6 as above). This successfully adds
the subkey stubs.
5. Run "gpg2 --import primary-stub.key".
6. GnuPG imports the primary key stub, resulting in a private key
containing stubs to the primary and subkeys on their respective cards.

Observed behavior.
1. Same as above.
2. Same as above.
3. Same as above.
4. Same as above.
5. Same as above.
6. GnuPG does *not* import the primary key stub. Rather it says:

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

Starting over and reversing the order (creating the subkey stubs,
exporting them to a file, deleting the subkey stubs from the keyring,
adding the primary key stub, and trying to import the subkey stubs)
produces the same, unsuccessful result.

==========

Is this intentional or a bug?

If it is intentional, how can one easily add stubs pointing to
different smartcards for different private key components?

==========

Addendum:

I was able to successfully create a private key with stubs pointing to
both cards as follows (since Gpg4Win does not include the gpgsplit
utility but Debian's gnupg2 package does, I performed these steps in
Debian. I presume they'd also work in Debian derivatives like
Ubuntu.):
1. Insert smartcard #1, run "gpg2 --card-status". This creates a stub
for the primary key.
2. Run "gpg2 --export-secret-keys KEYID > primary-stub.key" to export
a private key file containing the stub of the primary key.
3. Run "gpg2 --delete-secret-keys KEYID" to delete the private key
stub from the keyring. Only the public key remains in the keyring.
4. Insert smartcard #2, run "gpg2 --card-status". This creates a stub
for the subkeys.
5. Run "gpg2 --export-secret-keys KEYID > subkeys-stub.key" to export
a private key file containing the stubs of the subkey.
6. Run "gpg2 --delete-secret-keys KEYID" to delete the subkey stubs
from the keyring. Only the public key remains in the keyring.
7. Put each exported key file into a separate directory, then run "cat
primary-stub.key | gpgsplit" and "cat subkeys-stub.key | gpgsplit" in
the respective directories to separate the keys into packets.
8. Move the subkey stub packets from their directory into the primary
key directory, overwriting the subkey packets in the primary key
directory.
9. Run "cat * > complete.key" in the primary key directory to
reassemble the key file.
10. Run "gpg2 --import complete.key" to import the reassembled key file.
11. Success! Everything works as expected: running "gpg2 --edit-key
KEYID", then "toggle" shows that the primary key and the subkey stubs
exist and point at their respective cards. Certifying a key requires
smartcard #1 and signing/decrypting messages requires smartcard #2.

Although this was successful, I think that it's something that should
be doable within GnuPG itself rather than by splitting keys and
working manually on packets.

Cheers!
-Pete

-- 
Pete Stephenson