stub-key migration from gpg 1.4/2.0 to 2.1

Werner Koch wk at
Wed Feb 24 10:08:18 CET 2016

On Wed, 24 Feb 2016 09:35, kristian.fiskerstrand at

>> 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?

Well it would work or we can make it work.  You won't have a prompt with
the serial number of the smartcard to be inserted then.  I actually like
that prompt ("Please insert the card with S/N xyz").

> 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

Yes, with the above mentioned exception.  We could of course keep a
cache of seen cards which works as long as you don't restart the agent.

There is another use case I forgot to tell: OpenSSH supports
certificates for the public keys to ease administration tasks.  These
are special ssh certificates and not any complicated stuff like X.509 or
OpenPGP.  Meanwhile gpg-agent can take the keys from the certificates
but gpg-agent is not yet able to return the certificate on request from
ssh.  To fix this within the model we use in our ssh-agent protocol
implementation, we need to persistently store those certificates along
with the private key (or stub key). A field "Ssh-cert:" in the proposed
meta data format could be used for that.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-devel mailing list