[PATCH] gpg: enable key-to-card upload for cert-only keys

[Dominik Heidler]

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
> 1549).
> 
> 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
> theoretical?
> 
> 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.
>