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@gnupg.org> 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@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users >
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
