Multiple OpenPGP encryption keys signed by a single certificatation key?

Question

Say I have several different email accounts and I want to use a different encryption key for each of them but still have them all certified under one identity. Is this a good idea and how would I do it?

For example:

Jon Doe (identity; key stored on encrypted external drive) certifies

1. [email protected] (personal conversations only; key stored on trusted Linux machine)
2. [email protected] (conversations with random people; key stored on potentially unsafe Windows machine) and
3. [email protected] (business conversations; key stored on Windows machine that I have no control over)

The idea is to have a different encryption key on every device (which is also tied to an account), so if one gets compromised the other accounts are not affected, but my conversation partners would still only have to verify one public key and automatically have my other public keys certified (if, for example, someone would like to converse with me on both my personal and business address).

---

My first attempt was to add multiple UIDs (email addresses) and encryption subkeys to a keypair but I soon realized that UIDs belong to the public key and clients by default would only use the most recent encryption key (also see Debian article on how to use a subkey for signing).

My current idea would be to generate a sign-only public key (sign + certify), the root identity, and separate keypairs for each email account (sign + encrypt) and then either certify the keypairs (how?) or build a small web of trust (by setting the trust level "ultimate" "trusted" from the email account keypairs to the sign-only public key?). Is this the way to do it, how would you do it and how can your conversation partners import all of my email public keys by only publishing my master identity?

Also I like to point out this GPG tutorial which argues against using such a type of scheme. The argument being, if I understood it correctly, that you should be more careful with your private key in the first place because users never check revocations anyway. Okay, great, so if my private key is compromised once I'm pretty much screwed with the PGP system? And then again, what's the use of creating a new identity/reputation (Jon Doe the 2nd) if users don't get notified about the revocation of my first identity anyway? I might as well send them a revocation certificate and the new public keys, which are still certified by my old root identity.

Answer 1

You already seem to have realized that there is no way to attach user IDs to subkeys.

You cannot impose ultimate trust on others

The problem with your concept is that while you can issue ultimate trust on your own devices, you cannot impose this for other users. If they're able to validate your "master" primary key through the web of trust, the other keys are still to be validated again, with the effect depending on the kind of trust issued on your key and the trust settings of the validating user.

In the end, all you can do is handing over this kind of handling to the others. Sign your other keys with the "master" key (consider certifying them cross-wise) and hope that (if they care to validate keys) they realize this certification and put trust and certifications on the other keys as they require it, too.

Is it worth the effort?

Consider whether using one signing key for multiple devices is not acceptable, anyway and the gained additional benefits don't weigh up with the effort. If somebody gets hold of your encryption subkey, simply revoke it and create a new one; you will still be able to decrypt old messages, and an attacker can only decrypt what he got hold of (so the exposure will usually be the same compared to different encryption subkeys). Consider switching encryption keys more often.

Personally, I only use one encryption subkey on all devices but my mobile phone, which will get its own primary key in the future (which I will not exchange during signing, but only "loosely couple" through cross-certifications.