Private key transfer format

[NIIBE Yutaka]

On 04/09/2015 09:06 PM, Werner Koch wrote:
> 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.

I thought it was a regression.  In GnuPG 1.4 and 2.0, some people did
--export-secret-keys for smartcard.  Well, I naively tried to "fix"
as a response to the bug report.

Yes, I think that we can just drop the support of --export-secret-keys
for smartcard, and fix documentations.

Well, in my opinion, it is unlikely there are some smartcard users who
expect serial number exact check by GnuPG with --export-secret-keys in
a machine and --import on another machine.
--