Prefer a currently available signing subkey?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Prefer a currently available signing subkey?

GnuPG - User mailing list
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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Prefer a currently available signing subkey?

Arthur Ulfeldt

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 <[hidden email]> 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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Prefer a currently available signing subkey?

Daniel Kahn Gillmor-7
On Tue 2017-04-18 15:41:08 +0000, Arthur Ulfeldt wrote:
> I had exactly the same problem, and there is an open bug about this (wanna
> fix it?) I forgot the number.

The open report is https://dev.gnupg.org/T1983

I've just moved this to priority "high" since it seems to continue to
affect people.

       --dkg

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Prefer a currently available signing subkey?

GnuPG - User mailing list
Yes, this affects me too - sorry for the "me too" email!

It has actually prevented me from registering my key on keybase.io (if that's a "thing") --- I suppose I could go through the rigmarole of building the Faraday cage, getting the offline key out and revoking the offending signing keys, as if it wasn't fiddly and generally inconvenient enough already... but I really would like to have different signing and authentication keys on each smart card I use, even if the encryption key is the same. And of course the latest key I created is actually my "weakest" key (for an experiment with a Yubikey NEO). Sigh.

I wish it would make a decision more along the lines of "of the keys I have available, I'll pick the newest or 'strongest'", rather than "I don't care what keys I have available, I just want the newest". Sadly I don't think I have even the skills to find where this decision is made in the code, let alone change it. I really hope it gets some attention soon though! Thankyou for bumping the priority.

Apart from that bugbear, love the software.

Andy

On 19 April 2017 at 16:46, Daniel Kahn Gillmor <[hidden email]> wrote:
On Tue 2017-04-18 15:41:08 +0000, Arthur Ulfeldt wrote:
> I had exactly the same problem, and there is an open bug about this (wanna
> fix it?) I forgot the number.

The open report is https://dev.gnupg.org/T1983

I've just moved this to priority "high" since it seems to continue to
affect people.

       --dkg

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Prefer a currently available signing subkey?

Juan Miguel Navarro Martínez
In reply to this post by Daniel Kahn Gillmor-7
On 2017-04-19 at 17:46, Daniel Kahn Gillmor wrote:
> The open report is https://dev.gnupg.org/T1983

Is it possible that is a duplicate of this report too?
https://dev.gnupg.org/T1967

Both are about a capable subkey not being used on GnuPG Modern branch
because it prefers a subkey with its missing secret part. Plus there was
a patch which seemed to work for 2.1.18.

It would be nice for that bug or regression from 1.4/2.0 due to the
change of secret keyring to finally be fixed or, if it was not a bug, a
feature to be added, as the only workarounds are:

- Using `-u $SubkeyFingerprint!` which works if you only use GnuPG CLI.
  Git, Enigmail or other tools are a no-go.

- Using `default-key $SubkeyFingerprint!` which is a pain if you have
  two master keys.

- Delete the subkey public parts for the missing subkeys which is
  boring to do after each `gpg --refresh`.

- Forget about having multiple subkeys with the same capabilities cause
  that's a no-go if you don't like the previous workarounds.

--
Juan Miguel Navarro Martínez

GPG Keyfingerprint:
5A91 90D4 CF27 9D52 D62A
BC58 88E2 947F 9BC6 B3CF


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Prefer a currently available signing subkey?

GnuPG - User mailing list
In reply to this post by GnuPG - User mailing list
On 4/20/17 5:00 AM, Andrew Stubbs via Gnupg-users wrote:
> even if the encryption key is the same.
Oh, this brings up a related issue, actually! GnuPG doesn't cope very
well if you put the same subkey on *multiple* smartcards - it remembers
the first smartcard it saw that contained the subkey and always asks for
that smartcard to be reinserted, even if you've later done gpg
--card-status with another smartcard that contains the same key. You can
get it to forget the first card by deleting the subkey's
~/.gnupg/private-keys-v1.d/$KEYGRIP.key file, but that's terribly fiddly
and potentially dangerous. (Before figuring out that those files are
named by keygrip, I was just deleting ~/.gnupg/private-keys-v1.d
entirely, which would've be extremely bad once I'd gotten actual private
keys into my keyring!)

I would assume this issue occurs with all kinds of subkeys, although it
only particularly hurts for encryption subkeys - since unlike the other
key usages, it only really makes sense to have one "live" encryption
subkey and so it's the most likely subkey to be shared across several cards.

To remedy this, GnuPG should either track multiple smartcards for each
key - and do something like "please insert any of the following
smartcards: <list of serial numbers>" - or simply overwrite the card-no
when you insert a second smartcard containing the same key. The latter
probably involves fewer changes.


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Prefer a currently available signing subkey?

Daniel Kahn Gillmor-7
In reply to this post by Juan Miguel Navarro Martínez
On Thu 2017-04-20 02:36:16 +0200, Juan Miguel Navarro Martínez wrote:
> On 2017-04-19 at 17:46, Daniel Kahn Gillmor wrote:
>> The open report is https://dev.gnupg.org/T1983
>
> Is it possible that is a duplicate of this report too?
> https://dev.gnupg.org/T1967
>
> Both are about a capable subkey not being used on GnuPG Modern branch
> because it prefers a subkey with its missing secret part. Plus there was
> a patch which seemed to work for 2.1.18.

I agree that these seem related, though T1983 has smartcard-specific
concerns.  I've tested the patch for T1967 in a non-smartcard situation,
but haven't tested it with a smartcard yet.  I'd be happy to hear the
results of such a test, if anyone has a smartcard handy for testing.

    --dkg

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Loading...