Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 7 down vote accepted

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.
share|improve this answer
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
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 1 '14 at 11:52

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.