Prefer a currently available signing subkey?

Arthur Ulfeldt arthur at
Tue Apr 18 17:41:08 CEST 2017

I had exactly the same problem, and there is an open bug about this (wanna
fix it?) I forgot the number.

I tried to solve it first by creating three copies of the master key. One
that knew about both signing keys, and one independent copy that knew about
each of the signing keys. So I could switch signing keys by switching which
copy of the master key I had in the current .gnupg directory. This was very
much too cumbersome.

Then I expired one of the keys and put the same signing key on both cards.
Juggling them got old fast.

On Tue, Apr 18, 2017, 2:47 AM Danielle McLean via Gnupg-users <
gnupg-users at> wrote:

> Hi, I've set up two smartcards - a YubiKey NEO and a YubiKey 4,
> specifically - with different subkeys of the same master key:
> sec#  rsa4096/ACA7BABE 2017-04-03 [C] # in cold storage
> ssb>  rsa4096/FF12EEC5 2017-04-04 [S] # on 4
> ssb>  rsa4096/136A2F3E 2017-04-04 [A] # on 4
> ssb>  rsa2048/3C6058F1 2017-04-05 [S] # on NEO
> ssb>  rsa2048/336B08C1 2017-04-05 [E] # on 4 and NEO
> ssb>  rsa2048/4F33D648 2017-04-05 [A] # on NEO
> However with the YubiKey 4 connected, GnuPG still attempts to sign data
> using 3C6058F1, which isn't currently available, rather than FF12EEC5,
> which is. I'm aware I can manually select the subkey with -u FF12EEC5!,
> but I can't easily sneak that switch in when I commit with Git, and I
> still want to be able to sign with 3C6058F1 when the NEO is actually
> connected.
> So: Is there a way to reconfigure GnuPG so that it uses the currently
> available subkey for signing, rather than always preferring the newest
> one even when it's *not* available?
> Thanks!
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170418/b85c1b4f/attachment.html>

More information about the Gnupg-users mailing list