stub-key migration from gpg 1.4/2.0 to 2.1

Kristian Fiskerstrand kristian.fiskerstrand at
Wed Feb 24 09:35:23 CET 2016

Hash: SHA512

On 02/24/2016 09:08 AM, Werner Koch wrote:
> On Wed, 24 Feb 2016 02:25, gniibe at said:
>> I'd understand that extending gpg-agent to support importing stub
>> doesn't sound good.  Even so, I think that it's a developers'
>> view point.  For users, it's better not to be requested any user
> Coincidentally I thought about this yesterday and I am pondering 
> with the idea of not requiring a stub key at all for a currently 
> inserted card.  That is actually the same thing we do in 
> command-ssh.c - the currently inserted card is treated specially
> by always trying to use it.
> Sure this does not help if you need to juggle with a bunch of
> cards but the most common case is that there is just one card.

Are you sure about that?

> On a somewhat related issue:
> There is the request to handle the case where keys are stored on 
> several cards which we can't easily solve with the current system 
> at all (or well, only with a lot of nasty code).  I have two ideas 
> on how to handle this:

Isn't this case pretty much solved already if the first part is
implemented? At least if the stub data generated isn't stored
persistently but in a cache of some sort separate from the secret

At least the use case where you'd switch from smartcard with only
subkeys (for daily use) to smartcard with a primary key (to certify
some certificates using a smartcard stored more securely) seems to be
void if the keygrip and cardno isn't stored as regular stub to begin

- -- 
- ----------------------------
Kristian Fiskerstrand
Twitter: @krifisk
- ----------------------------
Public OpenPGP key at hkp://
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Aquila non capit muscas
The eagle does not hunt flies


More information about the Gnupg-devel mailing list