Private key transfer format
gniibe at fsij.org
Thu Apr 9 16:00:13 CEST 2015
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:
>> (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
> 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.
More information about the Gnupg-devel