Approval of GPG key strategy

Question

I am a beginner in anything related to GPG and I have now read quite some stuff about it to get a better idea. I think i grasped most of the concepts by now.

I've worked out a GPG key strategy and i would like to hear your opinions and criticism. This should not be about the commands how to achieve the mentioned strategy but rather give me an idea if the plan is a good idea or not and/or to know if I understood the concepts correctly. It seems there is a lot of bad information around where people did not really think through the whole thing and/or tutorials with just a few commands without a good explanation why things should be done that way.

General key strategy:

• Primary key is used for certification (C) only, which means we only use it only to sign other keys.
  • Remove primary key (C) from all machines and only keep subkeys
    • Primary key stored offline only. In case subkeys get compromised we can revoke (revkey) them without losing reputation.
      • Other peoples keys signed by our primary key will still be valid
    • Keep only subkeys on computers.
  • No expiration date required since someone who has to access to this key can change expiration dates anyways
• One subkey is used for encryption (E)
  • Only one encryption key because otherwise it's not clear which public encryption key other people should use.
    • If someone encrypts with a certain public key we then might not have the corresponding private key at hand (maybe on another computer)
  • This subkey can be revoked with revkey command. This will immediately revoke it (no separate cert exported).
  • Set expiration date.
    • If private E key gets stolen and and primary key as well as revocation certificate is lost (no revocation possible), others will not use the corresponding public key for encryption anymore as soon as it's expired.
• One or more subkeys for signing (S)
  • This subkey can be revoked with revkey command. This will immediately revoke it (no separate cert exported).
  • Set expiration date
    • If private S key gets stolen and and primary key is as well as revocation certificate is lost (no revocation possible), others will not use the corresponding public key for signature verification anymore as soon as it's expired.

Backup strategy:

• Revocation certificate for primary key stored on cold storage (e.g. encrypted USB stick)
  • Possibly backup also on paper
  • In case primary key gets lost we can still revoke it
  • (An exported revoc certificate is only available for the primary key. We have to use the revkey command and be in possesion of the primary secret key in order to revoke a subkey only).
• Backup of .gnupg directory to cold storage (e.g. encrypted USB stick). Store on a different USB stick and in a different physical place than revocation cert.
  • Convenient way for creating new keys, signing keys, creating new keys, modifying keys or revoking them
    • Mount USB stick, set GNUPGHOME env var to point to gnupg dir on USB stick and execute commands
• Backup of primary key (C) and encrpytion subkey (E) on paper. Store in a different physical place from revocation cert.
  • Useful in case USB stick gets unusable
  • Also backup encryption key (E) since in case of loss we wouldn't be able to decrypt our data anymore
  • Backup of signing key(s) (S) not absolutely needed. We can just generate different ones and revoke the old ones in case of loss.
  • Using paperkey tool

Thanks for your comments. Cheers!

Edit: I am now using the yubikey in conjunction with GPG. The guide at https://github.com/drduh/YubiKey-Guide uses pretty much the same concepts as i proposed above. The primary key is stored offline and only the subkeys are loaded to the yubikey.

Answer 1

Separation of concerns is generally a good strategy and can be implemented with GPG subkeys. The main key, which is signed by others, is responsible for the reputation. It has to be kept very secure. One key is for signing and one for encryption/decryption. Those are more exposed, since you need access to them on many occasions.

Big Open Source projects like Debian GNU/Linux encourage to use subkeys in the same way, you proposed: https://wiki.debian.org/Subkeys

Your thoughts about the expiration date and backup seem also valid.

So I think this is a good idea, if you want to use GPG.