Why do PGP master keys only have a single subkey, and tie certification with signing by default?

Question

After learning more about PGP subkeys and how to split apart the roles of (S)igning, (E)ncryption, (A)uthentication and (C)ertification, I discovered that in most cases(?) a default master key has a subkey to separate out the job of encryption:

pub  2048R/AAAAAAAA  usage: SC
sub  2048R/BBBBBBBB  usage: E

Here, AAAAAAAA is the master key. S allows signing content, C allows creating new subkeys. (One benefit of this being that you can give AAAAAAAA a longer expiration time than BBBBBBBB and then create a new encryption key with AAAAAAAA because it has C usage permission.)

However, it seems to me that the following would be no less secure for users working off a single machine, yet provide more security for users who wish to receive encrypted mail from, e.g., work and home:

pub  2048R/AAAAAAAA  usage: C
sub  2048R/BBBBBBBB  usage: E
sub  2048R/CCCCCCCC  usage: S

With this setup, the master key AAAAAAAA cannot sign/verify or encrypt/decrypt, yet can collect trust. Thus, you can give the master AAAAAAAA key a longer expiration time and use it to add new subkeys. By then exporting BBBBBBBB and CCCCCCCC to, say, a separate work computer that is moved around a lot more and is less secure, without the master key, if the work computer is compromised, subkeys can be revoked and new keys added, without losing any reputation.

(You can even go as far as to keep the secret part of the master certification key in a Super Secure Secret Bunker, of course.)

I know that setting this up seemed to be impossible through a GUI (they don't seem keen on subkeys, either viewing or editing, let alone controlling what the master key can and can't do), but my question is:

Is there a specific reason this isn't done with existing PGP implementations? Exporting secret keys to other machines without certification privileges seems like it would be a big security win. (If only GUIs made it easier.) My only possible thought is that importing secret subkeys with a crippled master secret key is maybe not widely supported, as --export-secret-subkeys (in the gpg(1) man page) hints at:

--export-secret-keys

--export-secret-subkeys
       Same  as --export, but exports the secret keys instead.  This is
       normally not very useful and a security risk.  The  second  form
       of  the  command  has  the special property to render the secret
       part of the primary key useless; this  is  a  GNU  extension  to
       OpenPGP  and  other  implementations can not be expected to suc‐
       cessfully import such a key.  See the option  --simple-sk-check‐
       sum  if  you  want  to import such an exported key with an older
       OpenPGP implementation.

---

Edit: It looks like Debian follows this same practice? https://wiki.debian.org/subkeys

Answer 1

I have two viewpoints on this issue: one is based on historical facts (and is a bit technical), while the other is purely my own, original opinion.

Regardless, it seems indeed more secure, or at the very least more convenient, to use a separate key for signatures; that way, you only use your master key for certifications (and can store it away), and you don't have to go over all the certification process again (IRL meetings) if your key is compromised.

Historical facts

After carefully reviewing the C source code of stable GnuPG versions (1.4 and 2.0), I found the function responsible for setting the default capabilities of public keys; the code (in file g10/misc.c) looks like this:

476 int
477 openpgp_pk_algo_usage ( int algo )
478 {
479     int use = 0;
480
481     /* They are hardwired in gpg 1.0. */
482     switch ( algo ) {
483       case PUBKEY_ALGO_RSA:
484           use = (PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG
485                  | PUBKEY_USAGE_ENC | PUBKEY_USAGE_AUTH);
486           break;
487       case PUBKEY_ALGO_RSA_E:
488           use = PUBKEY_USAGE_ENC;
489           break;
490       case PUBKEY_ALGO_RSA_S:
491           use = PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG;
492           break;
...
509       default:
510           break;
511     }
512     return use;
513 }

I found this function because I first looked at how key generation was done (g10/keygen.c); it is indeed during (sub)key generation that GnuPG may give the "roles" for the keys. Once a master key is created, you cannot change its abilities.

The source code didn't tell much (except that a RSA key for signing also comes with the ability for certifying), but running a web search for the comment (line 481 above) led me to message a posted on 2005-08-03 in the gnupg-users mailing-list, saying:

GnuPG does not yet distinguish between C and S. So it does not make much sense to have a way of selecting this.

So, it seems that those default settings exist just because GnuPG used to make no distinction between the signature keys and the certification keys.

Additionally, these default settings may be in place because of DSA, as Simon Richter pointed:

For quite some time, gpg used DSA keys by default, which can only be used for signing, and then had to attach an elGamal subkey (which can be used for encryption only) to get a fully functional key.

For RSA, that isn't necessary, but it was kept for some reason.

The "sign only" or "encrypt only" RSA subtypes are not technical limitations on the algorithm.

Original facts

Nowadays, I believe the only reason of that (default primary key capabilities set to SC and not C alone) is to help regular users with verifying signatures.

Let's say you have those two keys in your keyring:

pub  4096R/00000001  1970-01-01       usage: C
uid                  Alice Owl
sub  4096R/AE687A0C  1970-01-01       usage: S
sub  4096R/F77A9AF1  1970-01-01       usage: E

pub  4096R/FFFFFFFE  1970-01-01       usage: CS
uid                  Bob Penguin
sub  4096R/00FF42CD  1970-01-01       usage: E

• Alice Owl is a regular GnuPG user, she is confident with OpenPGP and generated a keypair with GnuPG's --expert flag, so she could set her own key abilities. The primary key has the C flag of course, but she signs documents with a subkey.
• Bob Penguin knows barely anything about cryptography. The only thing he wants is a bit of privacy/intimacy. He generated his key like any regular user would (without touching any setting he doesn't understand).

Now, let's pretend you – the reader – are a beginner too. You receive signed documents from both Alice and Bob. You know the basics of gnupg, and in particular:

• Users are identified with their primary keys:
  • So I know that Alice is 00000001, and I also know that Bob is FFFFFFFE.
• One can verify messages with GnuPG's --verify or --verify-files options.

Now, let's verify the documents they sent to you.

$ gpg --verify from-bob.txt.asc
gpg: Signature made <date> using RSA key ID FFFFFFFE
gpg: Good signature from "Bob Penguin"

$ gpg --verify from-alice.txt.asc
gpg: Signature made <date> using RSA key ID AE687A0C
gpg: Good signature from "Alice Owl"

Wait, what? I thought Alice's key was 00000001?

Indeed, signatures on documents are not necessarily made with the master key; they are made with the key which has the signature capability (S). It is unlikely a beginner would know about that.

---

Maybe the actual explanation has nothing to do with this assumption ("the more beginners using SC keys, the better it is for other beginners"), but that's the only explanation I can come up with without bothering the GnuPG contributors.

Answer 2

Diti is almost right about the historical context, but the real historical reason is in the part he/she omitted.

For quite some time, gpg used DSA keys by default, which can only be used for signing, and then had to attach an elGamal subkey (which can be used for encryption only) to get a fully functional key.

For RSA, that isn't necessary, but it was kept for some reason.

The "sign only" or "encrypt only" RSA subtypes are not technical limitations on the algorithm.

Answer 3

When you make different keys for signing data and for signing certificates, then people who "sign your key" must actually sign your certification key, not your data-signing key; otherwise, the Web of Trust won't web past your key. However, when you sign an email, you do it with your data-signing key, not your certification key, and that's your data-signing public key which gets copied in the email.

So separating signature and certification keys is doable, but requires involved people and/or software implementations to be more careful about what they sign and distribute. I can imagine that you might encounter usability issues.