stub-key migration from gpg 1.4/2.0 to 2.1
wk at gnupg.org
Wed Feb 24 09:08:25 CET 2016
On Wed, 24 Feb 2016 02:25, gniibe at fsij.org 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
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