3

I've been reading some articles about using an offline master key for gnupg, and I'm confused about the key usage. It seems every article has a different opinion about it. I've seen the following usages on the master key:

  • C: Certify only
  • S: Sign only
  • CS: Certify and sign only

What's the correct usage for the master key these days? I have a different subkey for signing, encryption and authentication.

At the moment, I only specified (C)ertify on my offline master key, but I want to be sure this is enough and I will not run into any surprises when one of my subkeys expire (and I need to extend them).

Jeroen Jacobs
  • 189
  • 1
  • 5

2 Answers2

2

The "master" is the key that can certify other subkeys, so the only relevant usage for your master key is (C). When GnuPG creates a brand new set of keys, the default behaviour is to create a master key that can also act as signing key, so it assigns it (CS) capabilities, which is why you frequently see that combination. However only the (C) capability is relevant to your offline master.

In other words, what you have is correct.

mricon
  • 6,238
  • 22
  • 27
1

From my understanding of public key infrastructures (PKI) a "root certificate authority" must be self-signed and capable of signing other certificates below itself. In a similar capacity, the offline master key described would also need these same privileges.

  1. Certify (C) - the primary key "master key" MUST be a key capable of certification (so for subkey sets).
  2. Signing (S) - will be required for the "master key" to encrypt data (or keys) with its private key.

From what I have derived about CS it will be required for the master key to operate in a capacity of an offline master key (PKI). However, further reading led me to a GnuPG article Signing Subkey Cross-Certification. Which outlines the "master key" does not self-sign itself (like our PKI), which creates a weakness "the signing subkey does not sign the primary to show that it is owned by the primary. This allows an attacker to take a signing subkey and attach it to their own key". This is further discussed "GPG why is my trusted key not certified with a trusted signature?"

Also see, "Which actions does the GnuPG certify capability permit" and "Anatomy of a GPG key"

Which outlines: "Certification vs. signing - ‘Signing’ is an action against arbitrary data. ‘Certification’ is the signing of another key. Ironically, the act of certifying a key is universally called “key signing”. Just embrace the contradiction."

Hence, I would advise CS for your usage.

safesploit
  • 1,827
  • 8
  • 18
  • You misunderstand the articles you link to. It is absolutely not necessary for the certify key to have the signing capability -- it offers absolutely no security benefits over having a standalone (C) key. – mricon Jul 14 '18 at 01:27
  • I appreciate now that "certify (C)" and "cross-certification" are two different things. I will leave the post up, as it makes a valid point about cross-certification for an offline master key, which would be for long-term use. – safesploit Jul 15 '18 at 19:10
  • Apologies for reviving my old post, but how about signing someone else's key? Does it require (S) or (C)? If the answer is (C), how do pgp key-signing parties handle this? – Jeroen Jacobs Mar 16 '21 at 07:37
  • @Jeroen Jacobs signing someone else public key with your private key to produce a signed certificated will be (S) for the master key/certificate authority. A certificate authority should only be able to sign, which then creates a trust-chain -- while I understand this is off-topic, consider the idea of an X509v3 RootCA [Create the root pair](https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html), as this involves a strict rule sets. – safesploit Mar 27 '21 at 12:21