Strategies for offline PGP key storage

Posted Oct 3, 2017 9:43 UTC (Tue) by merge (subscriber, #65339)
Parent article: Strategies for offline PGP key storage

Why isn't there the concept of a temporary signing key (and certificate), derived from a master key? I'd happily re-upload a new signing key every X months and have it on all my devices when I know it expires. My master identity key could stay super safe and would never have to change. The one extra step of verifying that a current signing (public) key is derived from the one master (public) key doesn't seem too heavy. ...but that's easily said without thinking it all through :)

to post comments

Strategies for offline PGP key storage

Posted Oct 3, 2017 10:32 UTC (Tue) by grawity (subscriber, #80596) [Link] (5 responses)

…There is?

You can already have a separate subkey for signing files/messages, which expires in a month or two.

The master key is only required for certifying other keys and updates to your own subkeys, e.g. when you need to add a subkey or update the expiry time.

Strategies for offline PGP key storage

Posted Oct 3, 2017 12:10 UTC (Tue) by ms (subscriber, #41272) [Link] (4 responses)

Yeah, I have all my subkeys expire every 90 days which lines up with my letsencrypt certs expiring. So once every 80 days I get a reminder to renew everything.

Strategies for offline PGP key storage

Posted Oct 3, 2017 13:28 UTC (Tue) by merge (subscriber, #65339) [Link] (3 responses)

That's nice, making use of letsencrypt that way!

So, why use key cards? Creating known-good keys that in turn *can* get compromised until they expire seems more cheap, more safe, and more easy to use, especially when you're at it anyways, regularly finding a place to unlock your most secured files for a very short period of time.

Strategies for offline PGP key storage

Posted Oct 5, 2017 6:48 UTC (Thu) by madhatter (subscriber, #4665) [Link] (2 responses)

Because you're probably not the only person that uses your public key. If you're only using gpg to secure your files on your hardware, your point is valid. But if others use your key to correspond with you, and you change it every 80 days, they have a big key validity problem every 80 days.

If instead you have one highly-secure long-lived key that's on a HSM, and you use it to sign your ephemeral encryption keys, then any correspondent who has the public part of your long-lived signing key can get your current public key off any old keyserver and immediately know whether to trust it or not.

Strategies for offline PGP key storage

Posted Oct 5, 2017 7:00 UTC (Thu) by merge (subscriber, #65339) [Link] (1 responses)

That's true. But for example Debian encourages to use signing subkeys, see https://wiki.debian.org/Subkeys (although not explicitely short-term keys). But in the end I guess you'd only have to wait until your new signing subkey has landed in all keyrings and let your current one expire, which is solved by overlapping the key validity intervals by a few weeks and always using the oldest.

Strategies for offline PGP key storage

Posted Oct 5, 2017 12:53 UTC (Thu) by anarcat (subscriber, #66354) [Link]

One of the problem I've encountered with having multiple signing keys is that not all programs using GPG make it easy to choose which key to use for signing. Last month, for example, I added that signing key and that key took well... about a month to propagate through Debian's infrastructure. That gave me time to notice that:

1. gpg chooses the latest signing subkey (I would have expected it would sign with all available signing subkeys)
2. notmuch-emacs and mutt do not allow you to choose which subkey to use to sign outgoing messages
3. debsign *does* allow you to choose the signing subkey, but that's about the only thing

I had to go back to inline signing to send email... And I had to specify the signing key with a bang ("!") at the end, which was weird and unusual (I would have expected the keygrip to work here for example).

So in short, it's a pain in the back to rotate signing keys, I wouldn't recommend having a workflow based on doing that on a regular basis, unless you control key propagation.