Suggestion needed: fix T3416 gpg should select available signing key on card (even with -u option)

[Frederick Zhang]

The problem I had was rather similar as T3416. I've got 2 YubiKeys
loaded with two sets of signing/authentication subkeys. One of them is
supposed to be a backup key and they should be able to be used
interchangeably without any hiccup.

For example, here I've listed the subkeys I have, and the two YubiKeys,
i.e.  #1 and #2, store different keys respectively:

sec#  rsa4096/0x0D8BC11D 2019-01-23 [SC] [expires: 2020-01-23]
ssb>  rsa4096/0x716B1FC5 2019-01-23 [E] [expires: 2020-01-23]
      Card serial no. = 0006 00000001
ssb>  rsa4096/0x361BE1AE 2019-01-23 [S] [expires: 2020-01-23]
      Card serial no. = 0006 00000001
ssb>  rsa4096/0x964E63BD 2019-03-26 [A] [expires: 2020-01-23]
      Card serial no. = 0006 00000001
ssb>  rsa4096/0x5FF72AA3 2019-03-27 [S] [expires: 2020-01-23]
      Card serial no. = 0006 00000002
ssb>  rsa4096/0x16A376D9 2019-03-27 [A] [expires: 2020-01-23]
      Card serial no. = 0006 00000002

Now the problem is, when I'm using #1 and trying to sign something, e.g.
git commit, because git specifies `-u` and the signing key 0x5FF72AA3 in
#2 is newer, GPG asks me to plug in #2 although it should be able to
sign the commit using 0x361BE1AE in #1 just fine.

So basically I'd expect the same behaviour as what GPG currently does
when no `-u` option is specified, where it prefers the key that's
currently available either locally on disk or from a smart card (oops,
just realised that I didn't take the on-disk keys into account in my
patch). And only when none of those private keys are available, it asks
the user to plug in the smart card which holds the latest subkey.

But even with this logic implemented, it still does not fully resolve my
problem, because I don't want to have different encryption subkeys on my
YubiKeys, which would confuse others and require me to always have both
cards to decrypt my files. Currently "keytocard" replaces the keygrip
with a shadow key (which I don't think works pretty intuitively in case
of multiple smart cards, as it requires users to manually back up the
subkey beforehand to transfer the same key to multiple cards) that
associates the subkey with a smart card, e.g. #1 above. So now every
time I plug in #2 I have to manually delete the shadow key and somehow
trigger "agent_card_learn" to use the same encryption subkey on #2,
otherwise GPG would ask me to plug in #1, and vice versa.

I can somewhat live with this problem as I've got only 2 cards. But
consider the scenario that vsrinu26f mentioned in T3416 where an admin
distributes a bunch of smart cards with the same subkey to users, things
could really get out of hand.

A quick solution I've got in mind would be allowing agent_card_learn to
overwrite existing shadow keys, but modifying files silently in the
background doesn't sound quite safe.

Another solution, which I don't know whether is actually feasible or
not, is:

    1. storing different shadow keys for different smart cards, e.g.
    using HEX_KEYGRIP-HEX_SMART_CART_SERIALNO.key as the file name
    2. leaving the original keygrip untouched after "keytocard"

If this is possible, not only it would allow users to track which key is
stored in multiple smart cards and use whichever card they want, but
also make the process of duplicating smart cards much smoother.


On 10/4/19 9:58 am, NIIBE Yutaka wrote:
> Frederick Zhang via Gnupg-devel <gnupg-devel at gnupg.org> wrote:
>> I encountered the issue of T3416 gpg should select available signing key
>> on card (even with -u option) <https://dev.gnupg.org/T3416> recently and
>> I've been working on a fix for it. But since I've got little knowledge
>> about GPG internals, it'd be nice if I can have some feedback and
>> suggestions from you and maybe get the changes merged if they do make
>> sense :)
> 
> Please describe your problem, what you need/want, what to be achieved,
> etc., at first.  It is more helpful than a patch.
> 
> In my opinion, your approach of changing key search algorithm
> (finish_lookup) looks not good, because the impact is larger.
> 

-- 
Best Regards,
Frederick Zhang

Email:      frederick888 at tsundere.moe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190410/6ffe3015/attachment.sig>