[Gnuk-users] Multiple retired encryption keys

[Gary]

On 23/09/17 03:51, Duncan wrote:
> 
> 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.
> 

Hi Duncan,

I may caused a little confusion with my original email, I don't need to
get my private keys off of the gnuk and I'd be worried if that was
possible (without physically destroying the gnuk anyway).

I have offline copies of my private sub-keys along with my master key
just in case of gnuk hardware failure and the need to configure a new token.

My "problem" is that once my keys expire, I can modify the expiry date
and keep using them for another 5-10 years, however should they ever get
compromised, that compromises all your data you've ever encrypted with
that key. So I'd like to rotate my encryption key every few years.

Prior to using a token like the gnuk, this was simple, you just made a
new encryption sub-key and gnupg would always use that one for new
encryption but would still have all the old expired encryption keys
still on the keyring in case you need to access old encrypted data (but
obviously that suffers from the risks that tokens are there to solve)

With the gnuk and I expect many smart-card/tokens at the moment
supporting a limited number of keys, there's not really an equivalent
method to support rotating encryption keys.

The workarounds are not too appealing either:-

1) you could move (from off-line storage) private keys for old
encryption sub-keys back to gnupg keyring. Losing the advantage tokens
offer as your key becomes more easily accessible in the case of a
machine compromise. Although, at least your active encryption key is
still safe on a token. Can gnupg work with a some of your sub-keys on
the gnuk and the rest in the regular .gnupg/ keyring though?
2) keep the old encryption keys on an off-line machine, but that is
quite inconvenient when you have the need to access archived data/emails etc
3) Buy a new token every time you generate a new encryption subkey and
retain old tokens. This isn't too bad, but for people who renew subkeys
every year or so, it would eventually become frustrating to manage not
to mention the cost of buying a token each year. How frustrating would
depend on how frequently old data would need to be decrypted though.
4) Keep extending the expiry date (see below)

> 
> 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.

Extending the expiry date is what I'll likely do. However, it feels like
a compromise to work around limitations of smartcards/tokens that is
less than ideal. Obviously whilst tokens have that limitation there's no
other real choice but I could see some people opting not to use tokens
due to this limitation, if they place a higher security priority on
cycling keys and this might be something the OpenPGP standard could take
into account for tokens that have the space to store extra keys.

Reason I say that is, over the years the amount of data protected by the
exact same encryption key grows and as PGP has no perfect forward
secrecy, if the day comes that the key is ever compromised, that's a lot
of data now at risk of decryption.

It'd be great if there was a way to have an optional addition to the
standard for smart-cards that have the space to store additional expired
keys but I expect that would be quite a long and arduous process to
achieve? I have no idea what the OpenPGP standards process is like, but
having seen other standards in action, if it's anything similar I expect
it'd be quite a task to get anything changed.

What are peoples thoughts on the gnuk supporting something like that
even if the standard does not? Would gnupg devs be willing to accept
patches to support that if needed? Or would they turn them down due to
lack of standard compliance?

Regards,

Gary