gpg is trying to sign with an old signing sub-key I no longer have

Question

I got a new smartcard (yubikey neo) and generated a new signing key on it. so now my public key mentions both the old one and the new one:

pub   rsa3072/B50A93EA 2015-08-13 [expires: 2018-08-12]
uid         [ unknown] Arthur Ulfeldt <[email protected]>
sub   rsa2048/6EE4E07A 2015-08-13 [expires: 2018-08-12]
sub   rsa2048/BC4C4B6C 2015-08-13 [expires: 2018-08-12] # <-- new key
sub   rsa2048/67E40B89 2015-08-13 [expires: 2018-08-12]
sub   rsa2048/91FF2F99 2015-08-16 [expires: 2018-08-15] # <-- old key
sub   rsa2048/3157DA5D 2015-08-16 [expires: 2018-08-15]

and gpg -K shows which ones I have the private keys for:

sec#  rsa3072/B50A93EA 2015-08-13 [expires: 2018-08-12]
uid         [ unknown] Arthur Ulfeldt <[email protected]>
ssb>  rsa2048/6EE4E07A 2015-08-13 [expires: 2018-08-12]
ssb>  rsa2048/BC4C4B6C 2015-08-13 [expires: 2018-08-12]  # <-- new key
ssb>  rsa2048/67E40B89 2015-08-13 [expires: 2018-08-12]
ssb#  rsa2048/91FF2F99 2015-08-16 [expires: 2018-08-15]  # <-- old key
ssb#  rsa2048/3157DA5D 2015-08-16 [expires: 2018-08-15]

running gpg --clearsign -u B50A93EA --status-fd 1 --debug-all prints this:

....
gpg: DBG: chan_5 -> KEYINFO F5B5D673F6FFFA999162D7F2F4F91750FF756F2F
gpg: DBG: chan_5 <- ERR 67108891 Not found <GPG Agent>
gpg: DBG: md debug: can't open dbgmd-00001.clearsign
...
gpg: DBG: chan_5 -> SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Arthur+Ulfeldt+<[email protected]>%22%0A2048-bit+RSA+key,+ID+91FF2F99,%0Acreated+2015-08-16+(main+key+ID+B50A93EA).%0A
gpg: DBG: chan_5 <- OK
gpg: DBG: chan_5 -> SETHASH 8 5B6489E68D...A9780A91BB6526C
gpg: DBG: chan_5 <- OK
gpg: DBG: chan_5 -> PKSIGN
gpg: DBG: chan_5 <- ERR 67108881 No secret key <GPG Agent>
gpg: signing failed: No secret key

which looks like it is using subkey 91FF2F99 to try and sign with.

gpg --card-info shows the correct keys on the card.

How can I verify that it is indeed trying to sign with the old key?

is there a way to cause it to use whatever key is actualy avalable on the smartcard that's plugged in at the moment?

PS: I'm using gpg (GnuPG) 2.1.7

Answer 1

I had similar issues, only specific to Enigmail after upgrading to GnuPG2.1 on Debian via dist-upgrade (Sid user).

I could not send emails that I intended to sign. Enigmail reported:

Error - encryption command failed `

Debugging GnuPG resulted in several errors:

ERR 67109139 Unknown IPC command <GPG Agent>
ERR 67108949 No pinentry <GPG Agent>
command 'PKSIGN' failed: No secret key

After a bit of reading (answer from Jens Erat as well), turns out indeed that enigmail/gpg-agent were selecting the signing subkey with the newest creation date.

To clarify, I originally created GnuPG keys following a Debian guide for developers, which recommended creating sub-keys for each different machine. However I did away with that practice almost immediately for various reasons, and deleted the signing subkey in question.

Both subkeys; the older that I kept, and the newer I thought I had deleted, were displaying when I'd run gpg --list-keys xxxxx in terminal.

Another hint for me was the 'No secret key bit', indeed there was no matching secret subkey for the public signing subkey that was being selected, perhaps I only deleted that one -- not sure.

So I deleted the public signing subkey that Enigmail kept trying to use:

gpg --edit-key xxxxx
$ key 2
$ delkey

Magically I could send signed emails again.

Not sure if the GnuPG upgrade reloaded the old key keys, if I somehow didn't delete the key right previously or had somehow restored it, or if Enigmail is simply working differently with GnuPG 2.1 (or even just differently in latest Enigmail update for Icedove).

Answer 2

There seems to be some confusion on "new" and "old" signing keys, as the one you describe as "new" has actually been generated three days before the "old" one. Furthermore, the key listing provided indicates the "old" key is the card key (as for the hash # in the subkey line). So GnuPG is doing what is expected to do here: use the newest available subkey to perform an operation. The subkey on the card is considered available, as you're able to make it available.

There is no way to tell GnuPG to automatically use the card key if the card is plugged into your computer, and otherwise fall back to another key instead. You could create some kind of wrapper, which tests for the card and subsequently chooses the subkey of your choice, which is possible by adding ! after the key ID, for example using -u BC4C4B6C! for the non-card signing key.