6. OpenPGP Signatures¶
Signatures are a fundamental mechanism within OpenPGP. They provide the syntax for forming and interpreting comprehensive statements about certificates and their components, as well as for ensuring the integrity and authenticity of data.
Without signatures, keys would remain unassociated with any certificate or owner. Signatures are crucial for binding component keys and identity components into hierarchical certificates and for establishing the authenticity of messages.
6.1. Terminology: “cryptographic signatures” and “signature packets”¶
Within OpenPGP, the term signature can have two different meanings:
Cryptographic signature: a sequence of bytes created by cryptographic keys, calculated according to a signature scheme.
Fig. 14 A cryptographic signature¶
OpenPGP signature packets: Defined in the OpenPGP standard, these packets combine a raw cryptographic signature along with a type designation and additional metadata.
Fig. 15 An “OpenPGP Signature Packet”¶
In this document, “signature” will refer to OpenPGP signature packets.
6.2. Signature types in OpenPGP¶
The OpenPGP standard defines a set of Signature types, each identified by a numerical signature type ID. Signature types define the purpose of a signature packet and how it should be interpreted.
Signature types can be predominantly classified in two ways:
Signatures over data: These signatures are denoted by type IDs
0x00for binary documents and0x01for canonical text documents. The signer uses these signatures to claim ownership, assert creation, or certify the immutability of the document.Signatures on components: These are signatures that are associated with component keys or identity components of a certificate.
Signatures on components are a complex topic, and we discuss them in depth in Signatures on components. They are grouped based on two criteria:
the origin of the signature, distinguishing between a self-signature and a third-party signature
the nature of the statement made by the signature, such as certifying an identity or binding component keys into a certificate
Fig. 16 An overview of signature types in OpenPGP¶
This chapter will cover the overarching principles applicable to all OpenPGP signature types.
For more detail about specific types of signatures, see the chapters on Signatures over data and Signatures on components, respectively.
6.3. Structure of an OpenPGP signature packet¶
As outlined above, an OpenPGP signature is a composite data structure, which combines:
Signature type ID: specifies the signature’s intended meaning, as detailed above
Metadata: varies based, in part, on the signature type ID; mostly encoded as “subpackets” (see Signature subpackets)
Fig. 17 Structure and context of an OpenPGP signature packet¶
The input data packets differ between specific signature types. Also see Fig. 16.
For example:
Binary data signature: The input data packet is a literal data packet.
Subkey binding signature: The input data packets consist of a primary and a subkey packet.
6.3.1. Creating an OpenPGP signature packet¶
Creating an OpenPGP signature packet involves encoding a statement about a specific set of data within the packet.
The input data of a signature packet includes:
Packets being signed: Typically one or more packets, though sometimes none, depending on the context. These are the packets to which the signature statement pertains.
Data within the signature packet: This includes information that specifies the intent of the signature.
The input data is determined by the signature type and consists of the exact content that the signature statement addresses.
The signature packet consists of two parts:
Statement definition: This part of the packet defines the meaning or intent of the signature.
Cryptographic signature: This is the formal endorsement by the signer, created as follows:
A hash digest is calculated from the input data.
The cryptographic signature is then calculated for this hash digest.
6.3.2. Verifying an OpenPGP signature packet¶
Verifying an OpenPGP signature packet is similar to its creation, with some crucial differences that facilitate the verification by entities other than the signer.
The main differences:
Access to public key: Unlike the creation process, which is exclusive to the signer, verification can be performed by anyone who has access to the public key of the signer.
Use of signature verification mechanism: After calculating the hash digest from the input data, a signature verification mechanism is employed. This mechanism uses the hash digest, the cryptographic signature from the signature packet, and the public key of the signer. Its purpose is to ascertain the cryptographic validity of the signature.
6.4. Signature subpackets¶
In the OpenPGP protocol, signature subpackets enhance the expressiveness of a signature beyond what is conveyed by just the bare cryptographic signature and the signature type ID. These subpackets, introduced in RFC 2440, are essential for embedding additional metadata within signature packets.
Signature subpackets serve as sub-elements within signature packets, providing extra context and meaning to a signature. They are formatted as key-value pairs, where the keys are defined as subpacket type IDs by the RFC. The RFC also provides the format and interpretation of the values.
6.4.1. Examples of signature subpackets¶
The issuer fingerprint subpacket encodes the fingerprint of the component key that issued the signature.
The key flags subpacket defines the capabilities that are assigned to a component key within a certificate.
6.4.2. Hashed and unhashed signature subpackets¶
Signature subpackets within OpenPGP can reside in one of two distinct areas of a signature packet, each serving a different purpose.
Hashed area: Hashed subpackets are included in the hash digest of the signature and are thus covered by its cryptographic signature. They reliably express the signer’s intent.
Unhashed area: Unhashed subpackets, conversely, are not included in the hash digest for the signature. They are thus not protected against tampering and can be used to retroactively add, change, or remove metadata in a signature packet without affecting its validity. They are primarily used for advisory purposes or in scenarios where the integrity of the subpacket content can be self-authenticated. An example is the issuer fingerprint subpacket, which can be validated through successful signature verification using the referenced issuer key.
The majority of signature subpackets are stored in the hashed area.
For detailed information and specifications, refer to Hashed vs. Unhashed Subpackets in the OpenPGP RFC.
6.4.3. Criticality of subpackets¶
In the OpenPGP protocol, each signature subpacket can be marked with a criticality flag. This flag plays a pivotal role in the interpretation and validation of the signature. When set, it instructs any receiving implementation encountering an unrecognized subpacket type to treat this as a significant error and to invalidate the signature.
This mechanism accounts for different OpenPGP implementations that may support only certain subsets of the standard. Moreover, it anticipates the evolution of the standard, including the addition of new subpacket types.
Consider a scenario where an implementation does not recognize a subpacket indicating signature expiration. Without understanding this concept, the implementation might erroneously accept an already expired signature. By marking the signature expiration time subpacket as critical, the creator of the signature ensures that any recipient who cannot process this subpacket will reject the signature as invalid.
For specific guidelines on which subpackets should be marked as critical, refer to the RFC sections 5.2.3.11 to 5.2.3.36.
