[Gnuk-users] Multiple retired encryption keys

[Duncan]

Hi Gary,

Gary:
> Hi all,
> 
> I've been wondering what to do when my current sub-keys expire. Modify
> the expiry date to keep them active for another few years, or generate a
> new encryption sub-key.
> 
> The latter option would be preferable but then it raises the question of
> what to do about the old encryption key(s) given that the gnuk only
> supports 3 slots for E,S,A and I'd want to retain access to old
> encrypted data.
> 
> Is there any way to add extra keys beyond the 3 slots for E,S,A the gnuk
> provides?
> 
> If not, what level of work would be involved to get gnupg+gnuk to
> support the addition of multiple expired/old encryption keys? Is this
> something that's likely to happen?
> 
> 
> Regards,
> 
> Gary
> 

This appears to be less of a question of "what can Gnuk do", and more of
backing up the private key material before exporting it to the
smartcard/token.

For future reference, if you have an offline computer where your master
key material is stored, where you generate subkeys and then export them
to smartcards/tokens, you can choose not to save that they have been
exported from the master key after running the keytocard option. This
means you can still have access to private key material of the subkeys
after exporting the key to the card/token.

Unfortunately, the OpenPGP card standard does not allow more keys to be
added. I do not think it makes much sense to extend the standard, due to
the design of smartcards. In any case, when we update Gnuk, you would
lose access to the private key on the token anyway. However, Gnuk token
is not completely standards-compliant, so maybe it would be possible, at
a push.

I think your best option, since it is not possible (without invasive
methods, and even then quite difficult) to extract private key material
from the Gnuk token, is to keep the old tokens if you wish to keep
access to these, and use new tokens for your new keys (while following
the practice above).

If your subkeys have not been compromised (I think in most cases this
would mean that the token did not get stolen - something that's implicit
from what you've said), and there is no reason to regenerate keys for
security reasons, then I don't see what's wrong with extending the
expiry date of your old keys and then creating keys marked 'new', e.g.
write "new long-term signing key" in the comment for the new signing
subkey, and "old long-term signing key" in the comment for the old key.

Best,
Duncan