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

Attachment: OpenPGP_0x255837AEF812E87E.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Reply via email to