9

Of the following three actions:

  1. Certifying / signing other people's public keys.
  2. Generating a revocation certificate.
  3. Adding & revoking subkeys.

... which ones does the Certify capability on a key allow?

As I understand it, Certify permits 1) but I don't understand what permits 2) and 3).

If I remove the primary key (with its Certify capability) from a keyring I can see that I am no longer able to generate a revocation certificate: Secret parts of primary key are not available.

Is that because I no longer have the Certify capability, or because I no longer have the primary key (does the primary key itself have special powers for revocation?)

Paul M Furley
  • 368
  • 3
  • 9

1 Answers1

5

Certification Capability

RFC 4880, Key Structures defines the certification flag as mandatory:

In a V4 key, the primary key MUST be a key capable of certification. The subkeys may be keys of any other type.

It hints that operations manipulating subkeys are to be considered certifications:

It is also possible to have a signature-only subkey. This permits a primary key that collects certifications (key signatures), but is used only for certifying subkeys that are used for encryption and signatures.

Signature Types

Which (signing) operations are now to be considered certifications and depend on this capability?

"Signing other keys" obviously means issuing certifications, being already contained in the naming. As defined in RFC 4880, Signature Types:

0x10: Generic certification of a User ID and Public-Key packet.
0x11: Persona certification of a User ID and Public-Key packet.
0x12: Casual certification of a User ID and Public-Key packet.
0x13: Positive certification of a User ID and Public-Key packet.

The operations for manipulating subkeys also explicitely defined as certifications are:

0x18: Subkey Binding Signature
0x19: Primary Key Binding Signature
0x28: Subkey revocation signature

Yet undecided signature types (which belong to the area of "key management") are:

0x1F: Signature directly on a key
0x20: Key revocation signature
0x30: Certification revocation signature

0x30, certification revocation also should be considered a certification operation. 0x1F is also used for "statements that non-self certifiers want to make about the key itself". The only left operation is 0x20, key revocation signatures:

0x20: Key revocation signature
   The signature is calculated directly on the key being revoked.  A
   revoked key is not to be used.  Only revocation signatures by the
   key being revoked, or by an authorized revocation key, should be
   considered valid revocation signatures.

I cannot find any explicit restriction that disallows subkeys to act as revocation keys. [RFC 4880, Revocation Key)(https://www.rfc-editor.org/rfc/rfc4880#section-5.2.3.15) does not limit the target to primary keys, but also not explicitly allows subkeys. This might the only one not requiring certification capabilities. Yet GnuPG only creates revocation key signatures for primary keys. Another hint only primary keys should be allowed is that subkeys are always named as such if they apply in that section, so I'd assume only primary keys should be allowed.

Meaning of Certification Privilege

If I remove the primary key (with its Certify capability) from a keyring I can see that I am no longer able to generate a revocation certificate: Secret parts of primary key are not available.

Is that because I no longer have the Certify capability, or because I no longer have the primary key (does the primary key itself have special powers for revocation?)

In the end, there is no difference between a primary key and a key with certification capability, only primary keys may have it, but those also must.

Community
  • 1
Jens Erat
  • 23,446
  • 12
  • 72
  • 96
  • Jens-if I understand you, the RFC is saying that subkeys can not be used to "sign" (eg certify) other keys. This strikes me as basically contradictory, given that the subkey does certify [*at least one* key](https://gnupg.org/faq/subkey-cross-certify.html): the master key. "Subkey cross-certification (sometimes called "back signing") involves the subkey issuing a signature on the primary key, just like the primary key signature on the subkey." This [is not the only reason](https://lists.gnupg.org/pipermail/gnupg-users/2017-August/058916.html) we might want subkeys to have certifying authority. – Diagon Jul 10 '20 at 13:48
  • If you have a chance, perhaps you'll also look at my question, [here](https://security.stackexchange.com/questions/234478/a-solution-for-the-absence-of-certifying-subkeys-in-openpgp-certs). – Diagon Jul 10 '20 at 13:59