Different subkeys and the use of a SmartCard

[Christopher Beck]

Hi,

My question concerns the use of different signing sub keys and a smart card.

The current setup are two valid signing sub keys. One of them resides on the 
smart card, the other on one of my computers. The key on the smart card is 
older than the other one.

As described, gpg wants to use the newest sub key only. In my case it means, i 
cannot sign anything and the message

"gpg: signing failed: No secret key"

appears. I can also see all of the sub keys assigned to the key by typing "gpg 
-K" and "gpg --card-status". However, I tried the following on two different 
hosts:

First, I used a Windows PC and gnupg version 2.0.26, imported my public key 
and then deleted all of the sub keys except the ones on my smart card. I run 
"gpg --card-status", and then updated the keys by using "gpg --refresh-keys". 
"gpg -K" still shows every sub key and if they are available, but "gpg --card-
status" only shows the main key and the sub keys on the card. Finally, signing 
works well as expected.

Second, on a Linux PC using gnupg version 2.1.1 I did the very same thing as 
is did on the Windows PC before. But here, "gpg --card-status" still tells me 
about my other sub keys and therefore singing is not possible after running 
"gpg --refresh-keys".

Now I have a few questions.

First, why do these two versions of gnupg differ in their behavior this way? 
Why does one update the sub key information on "gpg --card-status" and the 
other one doesn't?

Second, is there a simple solution for my problem? I cannot rule out the 
possibility of having newer signing sub keys than the one on the smart card 
and I want gpg to use that key, which is available even if there exists a 
newer one.

Third and last, thought it makes sense for gpg to use the newest sub key only 
(especially for the signing sub key), is there a possibility to force gpg to 
use a specific sub key? This question could manually solve question number two 
and could be useful for me on educational purposes (for example to show, what 
happens, if an older, perhaps revoked or expired, sub key is being used).

Thank you in advance and sorry for the long e mail.

Kind regards

Christopher Beck

-- 
Christopher Beck

Gerhart-Hauptmann-Str. 1
91058 Erlangen
Tel.: 09131 / 9245437
Fax.: 09131 / 8148708
Jabber: beckus at jabber.org
EPVPN: (+49 221 59619) - 5232
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20141220/cca1f35f/attachment.sig>