21

I have a Master Identity key (which is detached from my daily-use keyring) and both encryption and signing subkeys (all are RSA).

I sign documents with the signing subkey: GnuPG selects this key automatically from my daily-use secret keyring (possibly) because the master key isn't present.

I'm not sure whether I should use the master key or the signing subkey when I want to certify someone else's public key.

It seems to me that I would increase the risk of compromising the master key if I use it for certification every time I obtain, import and verify the public key of a correspondent (although both master and daily-use private keys are only used on a non-networked machine, I feel that I should limit the exposure of the master key).

On the other hand, if I make certifications with the signing subkey and am later forced to revoke that key, those certifications will all need to be repeated with a new signing key (certainly those certifications which were made with --sign-key as opposed to --lsign-key).

Is this a trade-off that I must decide for myself or is it clear that I should use one or the other key?

jah
  • 400
  • 2
  • 10

3 Answers3

15

The four possible key "usages" are

  • Certification: signing other keys
  • Signing: signing data
  • Encryption: decrypting data
  • Authentication: signing authentication tokens

When you look at your key using --edit-key, you find the usage listed behind each key and subkey. By default, all that are supported by the key type are attached to the master key (so, RSA defaults to CSEA, DSA defaults to CSA as DSA keys should not be used for encryption). There are special key types that are more limited than their algorithm (e.g. "RSA (sign only)" that supports only CSA).

When creating a subkey, a key usage is assigned to it in the signature binding the subkey to the master key; this delegates this functionality to the subkey, which also becomes the default key for the respective operation, while the key usage is hidden from the master key.

Certification cannot be delegated to a subkey, so you will always need your master key to sign another key.

Signing can be delegated, and the newest valid key with a Signing delegation is automatically used for signing, unless another is forced by specifying the key to use with an exclamation mark in front.

Encryption can also be delegated, and the newest valid key with an Encryption delegation is automatically selected on the sender's side, unless another is forced with an exclamation mark.

Simon Richter
  • 1,492
  • 11
  • 8
11

The general practice is that the master key is used for signing other keys. See, for example, the exceptions under "Why?" for Using OpenPGP subkeys in Debian development. I'm not aware of any system that creates a subkey for this purpose, and in my experience public key software isn't all that flexible a beast.

As opinion only, I suggest the following two rationales:

  1. As you say, signing is an activity taken place on a trusted system and with minimal interaction with outside data. The risk level does not justify creation of a separate subkey which might have a shorter life and whose cycling would trigger a systemic re-trust exercise.
  2. The master key can be thought of as the corporation, the subkeys are the "doing business as" identities. The latter derive their authority from the former, but the master key is the authority. Signing other keys is by definition an authoritative action, and is most appropriate for the master key and not a subkey.
gowenfawr
  • 72,355
  • 17
  • 162
  • 199
  • Thank you @gowenfawr. May I suggest that your third sentence is somewhat superfluous and may detract from your otherwise excellent answer. – jah Dec 31 '13 at 10:55
  • 1
    I can see how the wording would put you off, but there's a nugget of truth to be considered there. Let me try again: Crypto software usually avoids the "Unix tools" philosophy of flexible input and simple chaining, preferring instead more rigidly defined interfaces. The reason is simple; the history of crypto is full of examples of cryptosystems being weakened by well-intentioned minor deviations from the default. Crypto software rarely encourages experimentation, and as a result is less flexible than you might find other software to be. Does that say it better? – gowenfawr Dec 31 '13 at 15:57
  • I think it does yes, but it seems to me to be at odds both with your answer and with the doc you linked to. I find it interesting that I had to use the exclamation mark when specifying the key id of the master identity for a `--sign-key` operation because GnuPG wanted to use the signing subkey instead. I think this answer (and the doc you linked to) make it clear that signing keys is to be done with a master signing key. – jah Jan 01 '14 at 11:52
2

As a practical matter, gpg does not allow the creation of subkeys with the 'C" (certification) ability. It is only the master/primary key that has that ability.

There are good reasons that we might want this ability in subkeys. While I don't have a diode (as discussed in that link), I don't want to have to keep going back and forth to my airgapped machine just to sign someone's key. It's both a security risk, and enough trouble that I might not want to do it.

It may be that the RFC is not entirely clear on whether this ability should be delegatable. (See again that link, but on the other hand, see this discussion, and note my comment afterward.) It is clear that as a practical matter, gpg developers have not always been clear what abilities which keys should be allowed to have. (See eg. this link that I happened to stumble across.)

There is a new RFC in discussion, and hopefully this issue will be clarified.

Community
  • 1
Diagon
  • 283
  • 1
  • 8