OpenPGP fundamentally hinges on the concept of “OpenPGP certificates,” also known as “OpenPGP public keys.” These certificates are complex data structures essential for identity verification, data encryption, and digital signatures. Understanding their structure and function is pivotal to effectively applying the OpenPGP standard.
An OpenPGP certificate, by definition, does not contain private key material.
Fundamentally, the effective management of certificates and a thorough grasp of their authentication and trust models are crucial for proficient OpenPGP usage. Although this document offers just a brief overview of these aspects, they form a fundamental part of the broader OpenPGP framework and warrant further study.
For an in-depth exploration of OpenPGP’s private key material, refer to Managing private key material in OpenPGP. This chapter provides essential insights into private key management and security practices.
The bindings that link the components of a certificate are comprehensively discussed in Signatures on components, offering a deeper understanding of certificate structure and integrity.
Finally, our chapter Zooming in: Packet structure of certificates discusses the internal structure of certificates in detail.
The term “(cryptographic) keys” is central to grasping the concept of OpenPGP certificates. However, it can refer to different entities, making it a potentially confusing term. Let’s clarify those differences.
The term “key,” without additional context, can refer to either public or private asymmetric key material. Additionally, symmetric keys may be used in OpenPGP to encrypt private key material, adding a layer of security and complexity.
In OpenPGP, the term “key” may refer to three distinct layers, each serving a unique purpose:
A (bare) “cryptographic key” comprises the private and/or public parameters forming a key. For instance, in the case of an RSA private key, the key consists of the exponent d along with the prime numbers p and q.
An OpenPGP component key includes either an “OpenPGP primary key” or an “OpenPGP subkey.” It is a building block of an OpenPGP certificate, consisting of a cryptographic keypair coupled with some invariant metadata, such as key creation time.
An “OpenPGP certificate” (or “OpenPGP key”) consists of several component keys, identity components, and other elements. These certificates are dynamic, evolving over time as components are added, expire, or are marked as invalid.
The following section will delve into the OpenPGP-specific layers (2 and 3) to provide a clearer understanding of their roles within OpenPGP certificates.
An OpenPGP certificate (or “OpenPGP key”) is a collection of an arbitrary number of elements[1]:
Additional metadata, including connections between the certificate’s components
This documentation collectively refers to component keys and identity components as “the components of a certificate.”
Fig. 4 Typical components in an OpenPGP certificate¶
Every element in an OpenPGP certificate revolves around a central component: the OpenPGP primary key. The primary key acts as a personal certification authority (CA) for the certificate’s owner, enabling cryptographic statements regarding subkeys, identities, expiration, revocation, and more.
Note
OpenPGP certificates tend to have a long lifespan, with the potential for modifications (typically by their owner) over time. Components may be added or invalidated throughout a certificate’s lifetime. However, once published, components cannot be removed from certificates.
An OpenPGP certificate usually contains multiple component keys. Component keys serve in one of two roles: either as an “OpenPGP primary key” or as an “OpenPGP subkey.”
OpenPGP component keys logically consist of an asymmetric cryptographic keypair and a creation timestamp. Once created, these attributes of a component key remain fixed (for ECDH keys, two additional parameters are part of a component key’s constitutive data[2]).
Fig. 5 An OpenPGP component key¶
Component keys containing private key material also include metadata specifying the password protection scheme. This is another facet of metadata, akin to the aforementioned creation timestamp and additional parameters for certain algorithms. However, this discussion focuses on OpenPGP certificates, in which the component keys contain only the public part of its cryptographic key data. For information on private keys in OpenPGP, see Managing private key material in OpenPGP.
Each OpenPGP component key possesses an OpenPGP fingerprint. This fingerprint is derived from the public key material, the creation timestamp, and, when relevant, the ECDH parameters.
Fig. 6 Every OpenPGP component key is identifiable by a fingerprint.¶
The fingerprint of our example OpenPGP component key is C0A5 8384 A438 E5A1 4F73 7124 26A4 D45D BAEE F4A3 9E6B 30B0 9D55 13F9 78AC CA94[3].
Note
In practice, the fingerprint of a component key, while not theoretically unique, functions effectively as a unique identifier. The use of a cryptographic hash algorithm in generating fingerprints makes the occurrence of two different component keys with the same fingerprint extremely unlikely[4].
The OpenPGP primary key is a component key that serves a distinct, central role in an OpenPGP certificate:
Its fingerprint acts as an identifier for the entire OpenPGP certificate.
It facilitates lifecycle operations, such as adding or invalidating subkeys or identities within a certificate.
Terminology
In the RFC, the OpenPGP primary key is occasionally referred to as “top-level key.” Informally, it has also been termed the “master key.”
Modern OpenPGP certificates typically include several subkeys in addition to the primary key, although these subkeys are optional.
While subkeys have the same structural attributes as the primary key, they fulfill different roles. Subkeys are cryptographically linked with the primary key, a relationship further discussed in Section 8.2.1.
Fig. 7 OpenPGP certificates can contain multiple subkeys.¶
Identity components in an OpenPGP certificate are used by the certificate holder to state that they are known by a certain identifier (like a name, or an email address).
OpenPGP certificates can contain multiple User IDs. Each User ID associates the certificate with an identity.
Fig. 8 Relationship of User ID to primary component key in an OpenPGP certificate¶
A typical User ID identity is a UTF-8-encoded string composed of a name and an email address. By convention, User IDs align with the format described in RFC2822 as a name-addr.
For further conventions on User IDs, refer to the document draft-dkg-openpgp-userid-conventions-00, dated 25 August 2023.
Split User IDs
One proposed variant for encoding identities in User IDs is to use “split User IDs”. Although uncommon, there are currently no significant technical barriers to implementing this format[5].
The rationale for split User IDs lies in the distinction between a name and an email address, which represent two separate facets of an individual’s identity. Separating these elements simplifies the process for third parties tasked with certifying that an identity is legitimately connected to a certificate.
Consider this scenario: A third party is confident about the email-based identity of an individual (e.g.,<alice@example.org>) and is willing to certify it. However, they might not have sufficient knowledge about the person’s name-based identity (e.g., Alice Adams), so are unwilling to extend the same level of certification. Split User IDs address this dichotomy by allowing distinct certification processes for each type of identity.
Within a certificate, a specific User ID is designated as the Primary User ID.
Each User ID carries associated preference settings, such as preferred encryption algorithms, which is detailed in Section 26.4). When a certificate is used in the context of a specific identity, then the preferences associated with that identity component are used. When a certificate is used without reference to a specific identity, the preferences associated with the direct key signature, or the primary User ID take precedence by default.
The primary User ID was historically the main store for preferences that apply to the certificate as a whole. For more on this, see Adding global metadata to a certificate.
While user attributes are similar to User IDs, they are less commonly used.
Currently, the OpenPGP standard prescribes only one format to be stored in user attributes: an image in JPEG format. Typically, this image represents the key owner, although it is not required.
To form an OpenPGP certificate, individual components are interconnected by the certificate holder using their OpenPGP software. Within OpenPGP, this process is termed “binding”, as in “a subkey is bound to the primary key.” These bindings are realized using cryptographic signatures. An in-depth discussion of this topic can be found in Signatures on components.
In very abstract terms, the primary key of a certificate acts as a root of trust or “certification authority.” It is responsible for:
issuing signatures that express the certificate holder’s intent to use specific subkeys or identity components;
conducting other lifecycle operations, including setting expiration dates and marking components as invalidated or “revoked.”
By binding components using digital signatures, recipients of an OpenPGP certificate need only validate the authenticity of the primary key to use for their communication partner. Traditionally, this is done by manually verifying the fingerprint of the primary key. Once the validity of the primary key is confirmed, the validity of the remaining components can be automatically assessed by the user’s OpenPGP software. Generally, components are valid parts of a certificate if there is a statement signed by the certificate’s primary key endorsing this validity.
OpenPGP certificates, their component keys, and identities possess metadata that is not stored within the components it pertains to. Instead, this metadata is stored within signature packets, which are integral to the structure of an OpenPGP certificate.
Key attributes, such as capabilities (like signing or encryption) and expiration times, are examples of metadata not stored in the component key data. How this metadata is stored depends on the component:
Primary key metadata is defined either through a direct key signature on the primary key (preferred in OpenPGP version 6), or by associating the metadata with the Primary User ID.
Subkey metadata is defined within the subkey binding signature that links the subkey to the certificate.
Identity component metadata is associated via the certifying self-signature that links the identity (usually in the form of a User ID) to the certificate.
It is crucial to note that the components of an OpenPGP certificate remain static after their creation. The use of signatures to store metadata allows for subsequent modifications without altering the original component. For instance, a certificate holder can update the expiration time of a component by issuing a new, superseding signature.
Fig. 9 Metadata can be associated with the primary key using a direct key signature.¶
Each component key has a set of “key flags” that delineate the operations a key can perform.
Commonly used key flags include:
Certification: enables issuing third-party certifications
Signing: allows the key to sign data
Encryption: allows the key to encrypt data
Authentication: primarily used for SSH authentication[6]
Note
Distinct component keys handle specific operations. Only the primary key can be used for certification, although it can have additional capabilities. Subkeys can be used for signing, encryption, and authentication but cannot have the certification capability. A component key can technically have multiple capabilities. It is considered good practice, however, to use separate keys for each capability.
Notably, in many algorithms, encryption and signing-related functionalities (i.e., certification, signing, authentication) are mutually exclusive, because the algorithms only support one of those two families of operations[7].
OpenPGP incorporates significant “cryptographic agility”. It doesn’t rely on a single fixed set of algorithms. Instead, it defines a suite of cryptographic primitives from which users (or their applications) can choose.
This agility facilitates the easy adoption of new cryptographic primitives into the standard, allowing for a seamless transition. Users can gradually migrate to new cryptographic mechanisms without disruption.
However, this approach requires that OpenPGP software determine the cryptographic mechanisms that a set of communication partners can handle and prefer. OpenPGP employs several mechanisms for this purpose, which allow negotiation between sender and recipient. It’s important to note that OpenPGP is not an online scheme; thus, this negotiation is effectively one-way. The active party interprets the preferences expressed in the certificate of the passive party.
Negotiation mechanisms in OpenPGP include:
Beyond these explicitly expressed preferences, implementations also deduce capabilities of communication partners based on the version of the OpenPGP certificate they possess.
As a starting point, a certificate has a set of preferences that apply generally. These are defined either in a direct key signature, or via the primary User ID of the certificate.
Additionally, OpenPGP allows modeling User ID-specific preferences. The idea is that a user may prefer a different suite of algorithms on their private email account compared to their work email account. Such identity-specific preferences can be expressed on the certifying signatures that bind User IDs to a certificate.
Following our review of how keys and identity components are linked, let’s reexamine the OpenPGP certificate from Fig. 4. Our focus now extends to all of its binding signatures and the direct key signature that contains metadata for the full certificate:
Fig. 10 This shows a typical OpenPGP certificate, including binding signatures for all of its components, and a signature that associates metadata with the primary key.¶
When a certificate holder needs to invalidate certain components of their certificate, or even the entire certificate, they accomplish this through “revocation.” Revoking the primary key renders the entire certificate invalid.
Notably, revocations are not the only means by which components can become invalid. Other factors, such as the passing of a component’s expiration time, can also render components invalid.
For more detailed information on revoking specific components of a certificate, see the section on Revocation self-signatures: Invalidating certificate components.
Since its inception, third-party identity certifications have been a cornerstone of the OpenPGP ecosystem. The original PGP designers, starting with Phil Zimmermann, advocated for decentralized trust models over reliance on centralized authorities. This decentralized approach in OpenPGP is known as the “Web of Trust.”
Third-party certifications are statements by OpenPGP users confirming that a user with a specific identity is the owner of a particular OpenPGP certificate.
For example, Bob’s OpenPGP software may issue a certification that Bob has checked that the User ID Alice Adams <alice@example.org> and the certificate with the fingerprint AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3 are legitimately linked.
Take, for instance, a scenario where Bob’s OpenPGP software issues a certification confirming as legitimate the link between the User ID Alice Adams <alice@example.org> and the certificate bearing the fingerprint AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3.
This process assumes that Bob knows the person known as Alice Adams and is confident that alice@example.org is indeed Alice’s email address. Bob also verifies that the certificate his OpenPGP software associates with Alice matches the one Alice uses. In essence, both users must have a certificate for Alice with an identical fingerprint. In OpenPGP version 6, manual fingerprint comparison by end users is discouraged, with a replacement verification mechanism still under development. The verification process must occur over a sufficiently secure channel, such as an end-to-end encrypted video call or a face-to-face meeting.
For more on third-party certifications, see Authentication and delegation in third-party signatures.
