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

score 28 · Answer 1 · edited Oct 07 '21 at 08:14

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.

As a beginner who was confused by this *exact thing* at one point, I would like to ask: how *is* one expected to connect AE687A0C to 00000001? What's expected of the end-user in this case? — ELLIOTTCABLE, Oct 24 '14 at 09:30
Using `gpg -k AE687A0C` will show the whole keyset of the key. — Flow, Jun 14 '16 at 13:50
It's actually `gpg2 --verbose --list-keys ID` to see subkeys with theit IDs, and `gpg2 --edit ID` to see the subkey capacities, i.e. `SC` and `E`. — fbmd, Jan 04 '17 at 07:12
Where could one submit a feature request that gpg prints ", which is a subkey of RSA key ID 00000001"? The process on https://www.gnupg.org/faq/HACKING.html is too complicated for such a small contribution. — Joachim Wagner, May 18 '18 at 11:55

score 8 · Answer 2 · answered Apr 24 '15 at 09:10

8

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.

answered Apr 24 '15 at 09:10

Simon Richter

1,482
11
8

1

For RSA, wasn't it because using the same RSA key to sign and encrypt is insecure? – user1686 Apr 27 '15 at 09:30
Hey, good point! Should I edit my answer to include yours, or should I keep our answers separate? – Diti Apr 29 '15 at 11:46
1

It's probably a good idea to add it, so people can find it more easily. – Simon Richter Apr 29 '15 at 11:59
1

@grawity Do you have any reference to support this claim? Because I don’t think it is true. – kirelagin May 30 '17 at 07:28
IIRC that is the reason why it was split for DSA. – Simon Richter May 31 '17 at 06:11

score 6 · Answer 3 · answered Mar 10 '13 at 20:51

6

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.

answered Mar 10 '13 at 20:51

Tom Leek

168,808
28
337
475

3

Don't key signatures go on the uid associated with the public key, as a signature that the claimed owner is genuine? Or are you referring to trust levels for saying how much you trust another person's signature on another key? – Adam Prescott Mar 10 '13 at 21:02
Are you sure the "data-signing public key which gets copied in the email"? The signature is not the same thing as the public key itself. – Jonathan Cross Mar 22 '16 at 19:37
Normally, emails signed with PGP include some stuff that helps the recipient find out about the sender's key, either a copy of the key itself, or at least a reference to a key server. Recipient should still validate the key (with the WoT, or a phone-call-and-dictate-hash-value) but at least in some cases the signature public key itself is copied in the email. – Tom Leek Mar 22 '16 at 19:44
@TomLeek Thanks, but I've learned that what you describe is just the behavior of _some_ OpenPGP email tools like PEP. It would be more clear if the answer just focused on the signature that is appended to the email as key itself may or may not be (it is not in my case with GPGTools plugin for mac Mail) – Jonathan Cross Jun 15 '20 at 23:12
@AdamPrescott is correct, the certification signatures are on a particular UID, not on the primary key itself (despite what people say when casually talking about a "key signature"). The Web Of Trust will indicate the whole "key" is signed if it is a valid, unexpired UID with a valid cert signature and that UID is properly certified by the primary key. – Jonathan Cross Jun 15 '20 at 23:12

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

3 Answers3

Historical facts

Original facts

Linked