stub-key migration from gpg 1.4/2.0 to 2.1

Werner Koch wk at
Wed Feb 24 09:08:25 CET 2016

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.

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

A editable file <keygrip.meta> alongside the <keygrip>.key file to store
additional information like the set of card numbers, a human readable
description of the card or key, flags to replace the use of sshcontrol.

Or the same but but with one file where we change the <keygrip>.key file
to a format like:

  Name: Key used to ssh to Colossus
  Card: D276000124010200FFFE123450000000
  Ssh: yes
  Key: (private-key 
   (curve Ed25519)
   (flags eddsa)
   (q #403F098994BDD916ED4053197934E4A87C80733A1280D62F8010992E43EE3B2406#)
   (d #1A8B1FF05DED48E18BF50166C664AB023EA70003D78D9E41F5758A91D850F8D2#)))

Thus instead of using the canonical representation of the S-expression
(binary) as we do right now, we would use the advanced transport
representation which is plain ascii and fits nicely into the RFC-822
like name value format.  The advantage is that a simple text editor can
be used to change the fields.  Detecting the new format would be easy
because the canonical representation always starts with a '('.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-devel mailing list