Long Term Key Management With Hardware Tokens

[Ingo Klöcker]

On Dienstag, 22. Juni 2021 20:47:45 CEST Brandon Anderson via Gnupg-users 
wrote:
> I agree that for most people having a paper backup stolen is unlikely,
> but then again, most people are not using GPG, to begin with, let alone
> GPG with smartcards or security tokens. There are several security
> concerns which having retirement keyslots can address. They can also
> improve the user experience as you won't have to air-gap a machine to
> view old records with revoked keys. All in all, it's about providing the
> option of having only security token access, not requiring it. I would
> expect any smartcard stored in a safe and only used infrequently during
> key changes and the occasional old record decryptions to last well over
> a decade.

I really fail to see your point. I can accept that you do not want to have a 
not-hardware-token-secured copy of your encryption keys. But what is the 
problem with having one OpenPGP smartcard for each retired key? Why do you 
want to cram all retired keys on a single OpenPGP card?

Is your motivation the environment (less retired still functional hardware 
tokens -> less wasted resources)? I'd applaud that, but I also question it. 
Deleting all those old and probably mostly useless encrypted emails might be 
better for the environment than keeping them in an archive (with several 
backups), which needs to be refreshed/copied to new archive storage every few 
years.

Or is it money? Something else?

If this single OpenPGP smartcard which holds all of your keys of the last 
decade breaks, what then? Then you have lost access to all encrypted documents 
of the last decade. If you'd  use separate OpenPGP smartcards instead, then 
you'd lose access to only one key rotation interval worth of old encrypted 
documents.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210622/a1d4210b/attachment.sig>