[PATCH] gpg: enable key-to-card upload for cert-only keys
dominik at heidler.eu
Sat Feb 1 15:23:41 CET 2014
I'm using the card as you described it:
I applied the patch to my local gnupg to be able to upload my C-Only
primary-key to the card. Then I created some offline backup for that key
as well and deleted the primary key from my computer.
I have two subkeys: One for signing and one for encryption. I can
exchange them at any time without loosing my WOT as the WOT is bound to
the primary key.
So to make that clear: On this smartcard I have only one key: The
primary C-only key.
I'm running this setup now for some time and it's working quite well.
Am 01.02.2014 15:14, schrieb NIIBE Yutaka:
> Thank you for your report also sending to me. It required some time
> for me to understand the context (I misunderstood as it were bug
> On 2014-01-23 at 11:34 +0100, Dominik Heidler wrote:
>> From: Dominik Heidler <dominik at heidler.eu>
>> * g10/card-util.c (card_store_subkey): allow PUBKEY_USAGE_CERT
>> GnuPG-bug-id: 1548
>> Signed-off-by: Dominik Heidler <dominik at heidler.eu>
> Let me rephrase.
> I think that you have a primary key with C-flag only and want to
> import that key to smartcard. I guess that you have a subkey for
> signing only. Or you are considering such a use case. --- (*)
> I could understand this. Life cycle would be different between
> primary key and signing only key. I know some Debian developers who
> use signing only subkey.
> Currently, OpenPGP card specification doesn't fit the use case of (*)
> very well, if a person wants to import both of primary key (for
> signing only) and signing only subkey. It defines only a single key,
> which is used to both purposes.
> It would be good if OpenPGP card specification allows an optional
> signing key, so that it could support the use case of (*). Then,
> your patch will fully make sense.
> Do you claim the use case above? Or, is your patch just a
> In my opinion, we need to discuss enhancement of OpenPGP card
> specification at first, if the use case is really common or its
> support is needed.
More information about the Gnupg-devel