Can a PGP subordinate key be used as a web of trust signing key?

Question

I already understand the desire to segregate a PGP master key from subkeys, allowing me to keep the master key in some off-site non-networked location while making use of the subkeys to do things like encryption and authentication. I also understand that I can then revoke the subkeys later if they are lost or compromised, allowing me to maintain my identity within the web of trust while being forced to shift to new keys.

The model I've seen employed so far looks like the master key is used to sign others' keys. This has the unfortunate side effect of necessitating that I take the master key out of cold storage any time I choose to sign a key. While I do not think this will be a frequent activity, I would like to minimize my interaction with the master key as much as possible.

Can a subordinate key be used to sign others' keys instead? I know I can create the signing key, but specifically the two important points to this are:

1. Others that trust my master key's signatures will trust these signatures that were created from the subordinate key
2. If the subordinate key is lost or compromised, can I revoke the subordinate key in a way that either (a) invalidates all signatures it has ever made or (b) invalidates all signatures made after a certain date. While (b) would be preferable, it's fairly trivial to let (a) happen and then just re-sign the keys I still want with a new subordinate signing key.

I think #2 is a given. The #1 is primarily what I'm not sure about. When computing the trust path to a target, are my subordinate signatures taken into account? And furthermore, does this model even make sense?

Answer 1

Can a subordinate key be used to sign others' keys instead?

No, not according to the OpenPGP Proposed Standard. A subordinate key (a subkey) cannot sign (certify) others' keys instead of the master key (the primary key).

I know I can create the signing key...

Yes, you can create a signing key (a subkey), but it is just for that, signing, and not for certifying or key revocation. You can revoke a subkey with the --edit command, and having created a revocation certificate, it can be merged with the master key (the primary key) to revoke the entire group of primary key and subkey(s), and there are good reasons for this setup.

Perhaps think of the unique value of the primary key in this way: a primary key is like a birth certificate. A birth certificate enables one to perform tasks and have certain privileges by getting a driver's license, a passport, or something like a Social Security Number. It is too valuable to carry around or leave unprotected. The license, passport, and SSN have the same User ID, if you will. It is your identity, and there can only be one.

If you lose the passport, you can get a new one with your primary identification document, which you keep in a safe place. You use it to certify information about yourself.

The primary key certifies [C] that a subkey(s) exists for the tasks of authentication [A], encryption [E], or signing [S]. It can also certify the primary key of another person; that is, their identity. The digital signature of the primary key onto a subkey(s) assures that a fake subkey does not exist. Leaving the primary key unprotected or always carrying it around (e.g., in a USB) is probably a bad idea that defeats the purpose of a primary key, which is not convenience but security.

A subkey cannot certify, except during cross-certification with its primary key.

It is no wonder that users are often mystified by GPG: the GnuPG manual is not always explicit. It is clear that one can only add a signing subkey or an encryption subkey when using the --quick-add-key *fpr* [algo [usage [expire]]] command, which is described on p. 46 of Using the GNU Privacy Guard, but the manual never directly tell us that there is not a way to add a [C] subkey. Knowing the capabilities of GPG sometimes boils down to trial and error.

One can create a stand-one [C] primary key with --expert --full-gen key and then select (8) RSA (set your own capabilities), but this primary key cannot be added as a subkey to another primary key, for obvious reasons.

Under --edit-key with addkey, one cannot add a [C] subkey. Using the approved methods of key generation, subkeys with a [C] usage tag cannot be made--[C] is for primary keys only.