[SOLVED-ish] Re: Cannot sign (but can decrypt) after importing stub-keys from smart-card
shtrom at ssji.net
Wed Dec 10 02:06:35 CET 2014
As it appears, I had the problem before, and even documented it  for
memory's sake, then completely forgot about it. So here's an update for
that, so I can find the solution better next time (:
tldr; GnuPG looks (apparently) for the most recent signing subkey
listed in the (public/secret?) keyring. Deleting those from the local
keyring, until GPG picks the one present on the card, seems to be a
working option. Is there any other?
On 2014-12-04, Olivier Mehani <shtrom at ssji.net> wrote:
> I am using
> * gpg (GnuPG) 2.0.26 (2.0.26-1 [ArchLinux]),
> * the card reader integrated with the Broadcom BCM5880 subsystem on my
> * pcsclite 1.8.13-1 and ccid 1.4.18-1 (ArchLinux),
> * an already initialised OpenPGP card (from Kernel Concepts),
> * a fresh user account.
> I had to downgrade from GPG 2.1 to 2.0 to be able to create the stubs, as
> suggested on this ML to work around  (In short: --card-edit/fetch;
> --edit-key/trust; --refresh-keys; --card-status).
> I can now decrypt messages
> $ gpg -er shtrom at ssji.net | gpg -d
> Unfortunately I don't seem to be able to sign
> What am I doing wrong?
A better way to understand what's happenning is to ask GnuPG to be
$ gpg -sv
gpg: using subkey 0xF9EB425E6D1886A7 instead of primary key 0xF012A6E298C66655
gpg: secret key parts are not available
gpg: no default secret key: Unusable secret key
gpg: signing failed: Unusable secret key
Here, 0xF9EB425E6D1886A7 is (one of) the key(s) to be removed from the
$ gpg --edit-key 98c66655
gpg> key 10
Once all mentions of other (more recent?) signing subkeys have been
removed from the keyring, GnuPG has no other choice but to use the
signing subkey present on the smartcard.
$ gpg -sv
gpg: NOTE: signature key 0x6CDA813213912971 expired Fri 26 Oct 2012 23:17:20 AEDT
gpg: NOTE: signature key 0x9CA49F44ABCF4EFA expired Mon 21 Jan 2013 14:11:29 AEDT
gpg: no secret subkey for public subkey 0x6CDA813213912971 - ignoring
gpg: no secret subkey for public subkey 0x9CA49F44ABCF4EFA - ignoring
gpg: no secret subkey for public subkey 0xADCF72E06DBC3057 - ignoring
gpg: no secret subkey for public subkey 0xF9EB425E6D1886A7 - ignoring
gpg: using subkey 0xE9566B9D0957D2D3 instead of primary key 0xF012A6E298C66655
gpg: writing to stdout
What is still not clear to me is that now GnuPG does recognise that the
other secret subkeys are not available and ignores them. AFAIK
they were already unavailable before (or, at least, unusable, as
confirmed by the fact that they were suffixed with '#').
Could this be a bug, or just a misunderstanding on my part?
Additionally, is there any better way to deal with this issue?
Olivier Mehani <shtrom at ssji.net>
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.
More information about the Gnupg-users