Private key transfer format

[Werner Koch]

On Wed,  8 Apr 2015 10:40, gniibe at fsij.org said:

> For private keys in smartcard, it can be something like following:
>
> (openpgp-private-key
>   (version V)
>   (algo PUBKEYALGO)
>   (curve CURVENAME)
>   (skey _ P1 _ P2 _ P3 ... _ PN_minus_1)  # ??? pkey???
>   (csum n)
>   (shadowed PROTOCOL (INFO)))
>
> How about this?

Why do we need it at all.  The smartcard has all the required
information.  Do you want to create a stub key (shadowed-private-key) in
private-keys-v1.d/ from some information provided by gpg?  I do not
think this will work: gpg does not know whether there is a
smartcard. Importing a secring.gpg with a smart card stub key might have
this information but it is not sure whether this smartcard is really
available.

Would't it be better to require insertion of the smartcard to attest
that a smartcard is really available?  As of now this required the use
of the LEARN Assuan command.  However, at least for OpenPGP cards we
could try to create a shadowed-private-key automatically after a card
has been inserted.  scdaemon emits an event and gpg-agent could at its
spare time (ticker thread) create this shadow key.

> Besides, I found that the description of "ti-v1" (token info version 1).
>
> In the current implementation, it is "t1-v1" (Tee-One Vee-One).  Shall we
> support "ti-v1" too?  Or just fix the description in keyformat.txt?

Ooops.  Better fix the documentation.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.