Feature request: handle multiple encryption subkeys on different smart cards intelligently

[NIIBE Yutaka]

Hello,

Thank you for detailed report.  It helps me a lot to understand your
situation.

Let me explain current GnuPG implementation.

Basically, current implementation processes OpenPGP packets one by
one.

On 06/09/2015 07:16 AM, Naftuli Tzvi Kay wrote:
> The process it seems to use is like this:
> 
>  1. Check if $ENC_SUBKEY_A's secret key is present: it's not.
>  2. Complain about the card not being present:
>     Please remove the current card and insert the one with serial number:
>         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>     Hit return when ready or enter 'c' to cancel
>  3. Hit c until it gets to the right key and prompts for the smart
>     card PIN. This can take a while, as I have 3 cards per identity.

Correct.  Note that this behavior is not for smartcard only, it also
applies to private keys on file system.

> What it /should/ do is this:
> 
>  1. Examine the file and determine which keys can decrypt it. _If_ a
>     smart card is present _and_ the smart card's secret key stub in
>     secring.gpg can decrypt the file, immediately defer to using that
>     card.
>  2. If no card is present or the file is --hidden-recipient, try
>     decrypting with any present keys in the keyring whose smart card is
>     present.
>  3. If there are no present keys, the present key can't decrypt the
>     file, or the present key failed to decrypt the file, then start
>     prompting to "insert the key known as ...".

Yes, I agree.

>From the implementation viewpoint, it will be something like:

   (1) gpg frontend parses all packets for ESK (Encrypted Session Key)
       sequence.

   (2) Then, talks to gpg-agent for available private keys to decide
       which private key to decrypt.

   (3) Asks gpg-agent to decrypt.
--