Long Term Key Management With Hardware Tokens

[Brandon Anderson]

> For the benefit of the archives, it is possible to encrypt outgoing 
> emails to your own key as well as the recipient's key, which ensures 
> that the sent-mail folder is readable by the sender. Most email 
> clients will do so by default (e.g. mutt, thunderbird/enigmail), and 
> in most such clients all you need to do to re-encrypt to the 
> recipient's new subkey is "Edit" -> "Send" or similar. So in the 
> general case this is a reasonable request, although it cannot be 
> relied upon (of course).
Good to know; I will look into my settings.

>> the PIV functions only support 2048 RSA and NIST curves. The only card
> That's per PIV specs.

I assumed as much; otherwise, there would be more offerings. There are 
x509 certificate cards/HSM smartcards like the one I posted that offer 
more than the PIV spec, but again it's a question of how compatible they 
are to work with GPG; my initial guess is it would be a lot of work.

> Frankly, I am not convinced about the retirement slots on the card.
> They are of course useful if you rotate you key.  But the question is
> why you want to do this given that the keys are anyway securely stored
> on a card.
If a key truly lived and died on a single secure device, and that was 
your only concern, then yes, it would not be helpful. I am thinking 
about my situation: I have two Yubikeys in everyday use and a GPG 
smartcard in a safe. I imagine a scenario where one of the Yubikeys 
dies, is lost or is stolen. In all of those situations, the encryption 
key and the other device-specific keys would need to be revoked and a 
new one issued. The GPG card in the safe would store the old encryption 
key in a retired key slot so I can decrypt old emails. If I did, for 
example, annual key rotations and only stored the retired keys on the 
card in the safe, then in the event one of my Yubikey's was stolen, and 
the thief could guess or know the pin, the only data at risk would be 
what was encrypted since the last key rotation. Whether it is reasonable 
to assume that a thief could know your pin or not is purely a matter of 
your risk tolerance (a keylogger on one of the computers you used, 
etc.). Another reason the encryption key might want to be rolled is if 
you are adding another new secure device to your existing set and you 
want it to be able to decrypt messages. Since ideally, the encryption 
key would only exist on the secure hardware, and there would be no way 
to give a new token the existing encryption key so that you would roll a 
new encryption key on all the devices.
Many tutorials, examples, and articles that are talking about using 
Yubikeys and smartcards currently suggest making paper backups of the 
encryption key so you can add it to new devices if needed. But this, at 
least to me, feels like it's significantly reducing the value of using 
secure hardware like smartcards in the first place. Having the keys only 
ever exist on secure hardware, including the backups, would make this 
unnecessary.

Sincerely,

Brandon Anderson

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x255837AEF812E87E.asc
Type: application/pgp-keys
Size: 9076 bytes
Desc: OpenPGP public key
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210622/aed109eb/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210622/aed109eb/attachment.sig>