SPDX-FileCopyrightText: 2023 The "Notes on OpenPGP" project
SPDX-License-Identifier: CC-BY-SA-4.0
-->
# Certificates
OpenPGP fundamentally hinges on the concept of "{term}`OpenPGP certificates<OpenPGPCertificate>`," also known as "{term}`OpenPGP public keys<OpenPGPPublicKey>`." These {term}`certificates<OpenPGPCertificate>` are complex data structures essential for {term}`identity verification`, data encryption, and {term}`digital signatures<OpenPGPSignaturePacket>`. Understanding their structure and function is pivotal to effectively applying the OpenPGP standard.
An {term}`OpenPGP certificate`, by definition, does not contain {term}`private key material`.
Fundamentally, the effective management of {term}`certificates<OpenPGPCertificate>` and a thorough grasp of their {term}`authentication` and {term}`trust models<TrustModel>` 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 {term}`private key material`, refer to [](/private_keys). This chapter provides essential insights into {term}`private key<TransferableSecretKey>` management and security practices.
- The bindings that link the {term}`components<Component>` of a {term}`certificate<OpenPGPCertificate>` are comprehensively discussed in [](/signing_components), offering a deeper understanding of {term}`certificate<OpenPGPCertificate>` structure and integrity.
- Finally, our chapter [](zoom/certificates) discusses the internal structure of {term}`certificates<OpenPGPCertificate>` in detail.
## Terminology: Understanding "keys"
The term "{term}`(cryptographic) keys<CryptographicKey>`" is central to grasping the concept of {term}`OpenPGP certificates<OpenPGPcertificate>`. However, it can refer to different entities, making it a potentially confusing term. Let's clarify those differences.
### Public vs. private keys
The term "{term}`key`," without additional context, can refer to either public or private {term}`asymmetric<AsymmetricCryptography>` key material. Additionally, {term}`symmetric<SymmetricCryptography>` keys may be used in OpenPGP to encrypt {term}`private key material`, adding a layer of security and complexity.
(layers-of-keys-in-openpgp)=
### Layers of keys in OpenPGP
In OpenPGP, the term "{term}`key`" may refer to three distinct layers, each serving a unique purpose:
1. A (bare) ["cryptographic key"](asymmetric-key-pair) comprises the private and/or public parameters forming a key. For instance, in the case of an RSA {term}`private key<TransferableSecretKey>`, the key consists of the exponent `d` along with the prime numbers `p` and `q`.
2. An OpenPGP *{term}`component key<OpenPGP Component Key>`* includes either an "{term}`OpenPGP primary key`" or an "{term}`OpenPGP subkey`." It is a building block of an {term}`OpenPGP certificate`, consisting of a cryptographic keypair coupled with some invariant {term}`metadata`, such as key {term}`creation time`.
3. An "{term}`OpenPGP certificate`" (or "OpenPGP key") consists of several {term}`component keys<OpenPGPComponentKey>`, {term}`identity components<IdentityComponent>`, and other elements. These {term}`certificates<Certificate>` are dynamic, evolving over time as {term}`components<Component>` are added, {term}`expire<Expiration>`, or are marked as {term}`invalid<Validation>`.
The following section will delve into the OpenPGP-specific layers (2 and 3) to provide a clearer understanding of their roles within {term}`OpenPGP certificates<OpenPGPCertificate>`.
## Structure of OpenPGP certificates
An {term}`OpenPGP certificate` (or "{term}`OpenPGP key`") is a collection of an arbitrary number of elements[^packets]:
[^packets]: In technical terms, the elements of an {term}`OpenPGP certificate` are a collection of "{term}`packets<Packet>`." Each {term}`component key<OpenPGPComponentKey>` and {term}`identity component` is internally represented as a {term}`packet`. Another common type of {term}`packet` is the "{term}`signature`" {term}`packet`, which connect the {term}`components<Component>` of a {term}`certificate<OpenPGPCertificate>`.
- {term}`Component keys<OpenPGPComponentKey>`
- {term}`Identity components<IdentityComponent>`
- Additional {term}`metadata`, including connections between the {term}`certificate<OpenPGPCertificate>`'s {term}`components<Component>`
This documentation collectively refers to {term}`component keys<OpenPGPComponentKey>` and {term}`identity components<IdentityComponent>` as "the {term}`components<Component>` of a {term}`certificate<OpenPGPCertificate>`."
:alt: Depicts a box with white background and the title "OpenPGP certificate". In the box several other boxes and accompanying texts, representing component keys and User IDs, are shown. There are three component keys boxes with a green frame, each with a dotted lower-left section, that shows the text "key creation time" and the green public key symbol in the lower right area. All three have a title, a unique fingerprint below the box and a unique capability keyword, perpendicular to the box on the right side. The top-most component key box has a light-green background, with the title "Component Key (primary)" and capability keyword "certification". The second-to-top component key box has a white background, with the title "Component Key" and capability keyword "encryption". The lowest component key box has a white background, with the title "Component Key" and capability keyword "signing". There are two User ID boxes, each with a black frame, open to top left and lower right corner. Both boxes have a user icon on the top left side, the title "User ID" on the top right side and a User ID string at the bottom. The top box has "Alice Adams <alice@example.org>" and the lower box has "Alice" as User ID string.
Typical {term}`components<Component>` in an {term}`OpenPGP certificate`
```
Every element in an {term}`OpenPGP certificate` revolves around a central {term}`component`: the *{term}`OpenPGP primary key`*. The primary key acts as a personal *{term}`certification authority`* ({term}`CA<CertificationAuthority>`) for the {term}`certificate<OpenPGPCertificate>`'s owner, enabling cryptographic statements regarding {term}`subkeys<OpenPGPSubkey>`, {term}`identities<Identity>`, {term}`expiration`, {term}`revocation`, and more.
```{note}
{term}`OpenPGP certificates<OpenPGPCertificate>` tend to have a long lifespan, with the potential for modifications (typically by their owner) over time. {term}`Components<Component>` may be added or {term}`invalidated<Validation>` throughout a {term}`certificate<OpenPGPCertificate>`'s lifetime. However, once published, {term}`components<Component>` [cannot be removed](append-only) from {term}`certificates<OpenPGPCertificate>`.
```
(component-keys)=
## Component keys
An {term}`OpenPGP certificate` usually contains multiple {term}`component keys<OpenPGPComponentKey>`. {term}`Component keys<OpenPGPComponentKey>` serve in one of two roles: either as an "{term}`OpenPGP primary key`" or as an "{term}`OpenPGP subkey`."
{term}`OpenPGP component keys<OpenPGPComponentKey>` logically consist of an [asymmetric cryptographic keypair](asymmetric-key-pair) and a creation timestamp. Once created, these attributes of a {term}`component key<OpenPGPComponentKey>` remain fixed (for ECDH keys, two additional parameters are part of a {term}`component key`'s constitutive data[^ecdh-parameters]).
[^ecdh-parameters]: For [ECDH](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-algorithm-specific-part-for-ecd) {term}`component keys<OpenPGPComponentKey>`, two additional algorithm parameters are integral to the {term}`component key<OpenPGPComponentKey>`'s constitutive and immutable properties. Those parameters specify a hash function and a {term}`symmetric<SymmetricCryptography>` encryption algorithm.
```{figure} plain_svg/Component_Key.svg
:name: fig-component-key
:alt: Depicts a box with white background and no title. In the box one other box is shown. The inner box has a green frame, with a dotted lower-left section, that shows the text "key creation time" and the green public key symbol, as well as the red-dotted private key symbol in the lower right area. In the top left of the inner box the text reads "Component Key."
An {term}`OpenPGP component key`
```
{term}`Component keys<OpenPGPComponentKey>` containing {term}`private key material` also include {term}`metadata` specifying the password protection scheme. This is another facet of {term}`metadata`, akin to the aforementioned creation timestamp and additional parameters for certain algorithms. However, this discussion focuses on {term}`OpenPGP certificates<OpenPGPCertificate>`, in which the {term}`component keys<OpenPGPComponentKey>` contain only the public part of its cryptographic key data. For information on {term}`private keys<TransferableSecretKey>` in OpenPGP, see [](private_keys).
(fingerprint)=
### Fingerprint
Each {term}`OpenPGP component key` possesses an *{term}`OpenPGP fingerprint`*. This {term}`fingerprint<OpenPGPFingerprint>` is derived from the {term}`public key material<OpenPGPCertificate>`, the {term}`creation timestamp<CreationTime>`, and, when relevant, the ECDH parameters.
```{figure} plain_svg/Fingerprint.svg
:name: fig-fingerprint
:alt: Depicts a box with white background and the title "Fingerprint of an OpenPGP component key." Inside, another box with a green frame, the title "Component Key", the text "key creation time" on the lower left and a the green public key symbol on the lower right is shown. Below the component key box a fingerprint in a box with a light-yellow background and a yellow dotted line is depicted. The word "Fingerprint" is shown left of the box with the fingerprint and both are connected with a yellow dotted line.
Every {term}`OpenPGP component key` is identifiable by a {term}`fingerprint<OpenPGPFingerprint>`.
```
The {term}`fingerprint<OpenPGPFingerprint>` of our example {term}`OpenPGP component key` is `C0A5 8384 A438 E5A1 4F73 7124 26A4 D45D BAEE F4A3 9E6B 30B0 9D55 13F9 78AC CA94`[^keyid].
[^keyid]: In OpenPGP version 4, the rightmost 64 bits were sometimes used as a shorter identifier, called "{term}`Key ID`."
For example, an OpenPGP version 4 {term}`certificate<OpenPGPCertificate>` with the {term}`fingerprint<OpenPGPFingerprint>` `B3D2 7B09 FBA4 1235 2B41 8972 C8B8 6AC4 2455 4239` might be referenced by the 64-bit {term}`Key ID` `C8B8 6AC4 2455 4239` or formatted as `0xC8B86AC424554239`.
Historically, even shorter 32-bit identifiers were used, like this: `2455 4239`, or `0x24554239`. Such identifiers still appear in very old documents about PGP. However, [32-bit identifiers have been long deemed unfit for purpose](https://evil32.com/). At one point, 32-bit identifiers were called "short {term}`Key ID`," while 64-bit identifiers were referred to as "long Key ID."
```{note}
In practice, the {term}`fingerprint<OpenPGPFingerprint>` of a {term}`component key<OpenPGPComponentKey>`, while not theoretically unique, functions effectively as a unique identifier. The use of a [cryptographic hash algorithm](cryptographic-hash) in generating {term}`fingerprints<OpenPGPFingerprint>` makes the occurrence of two different {term}`component keys<OpenPGPComponentKey>` with the same {term}`fingerprint<OpenPGPFingerprint>` extremely unlikely[^finger-unique].
```
[^finger-unique]: For both {term}`OpenPGP version 6<RFC>` and version 4, the likelihood of accidental occurrence of duplicate {term}`fingerprints<OpenPGPFingerprint>` is negligible when {term}`key material` is generated based on an acceptable source of entropy. A separate question is if an attacker can purposely craft a second key with the same {term}`fingerprint<OpenPGPFingerprint>` as a given pre-existing {term}`component key<OpenPGPComponentKey>`. With the current state of the art, this is not possible for OpenPGP version 6 and version 4 keys. However, at the time of this writing, the SHA-1-based {term}`fingerprints<OpenPGPFingerprint>` of OpenPGP version 4 are considered insufficiently strong at protecting against the generation of pairs of {term}`key material` with the same {term}`fingerprint<OpenPGPFingerprint>`.
(primary-key)=
### Primary key
The {term}`OpenPGP primary key` is a {term}`component key<OpenPGPComponentKey>` that serves a distinct, central role in an {term}`OpenPGP certificate`:
- Its {term}`fingerprint<OpenPGPFingerprint>` acts as an identifier for the entire {term}`OpenPGP certificate`.
- It facilitates lifecycle operations, such as adding or {term}`invalidating<Validation>` {term}`subkeys<OpenPGPSubkey>` or {term}`identities<Identity>` within a {term}`certificate<OpenPGPCertificate>`.
```{admonition} Terminology
:class: note
In the {term}`RFC`, the {term}`OpenPGP primary key` is occasionally referred to as "top-level key." Informally, it has also been termed the "{term}`master key<OpenPGPPrimaryKey>`."
```
(subkeys)=
### Subkeys
Modern {term}`OpenPGP certificates<OpenPGPCertificate>` typically include several {term}`subkeys<OpenPGPSubkey>` in addition to the {term}`primary key<OpenPGPPrimaryKey>`, although these {term}`subkeys<OpenPGPSubkey>` are optional.
While {term}`subkeys<OpenPGPSubkey>` have the same structural attributes as the {term}`primary key<OpenPGPPrimaryKey>`, they fulfill different roles. {term}`Subkeys<OpenPGPSubkey>` are cryptographically linked with the {term}`primary key<OpenPGPPrimaryKey>`, a relationship further discussed in {numref}`bind-subkey`.
```{figure} plain_svg/Binding_Subkeys.svg
:name: fig-subkeys
:alt: Diagram depicting three component keys. The primary key is positioned at the top, designated for certification. Below it, connected by arrows, are two subkeys labeled as "for encryption" and "for signing," respectively.
{term}`OpenPGP certificates<OpenPGPCertificate>` can contain multiple {term}`subkeys<OpenPGPSubkey>`.
```
(identity-components)=
## Identity components
{term}`Identity components<IdentityComponent>` in an {term}`OpenPGP certificate` are used by the {term}`certificate holder` to state that they are known by a certain identifier (like a name, or an email address).
(user-ids)=
### User IDs in OpenPGP certificates
{term}`OpenPGP certificates<OpenPGPCertificate>` can contain multiple [User IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#uid). Each {term}`User ID` associates the {term}`certificate<OpenPGPCertificate>` with an {term}`identity`.
```{figure} plain_svg/Binding_a_UserID.svg
:name: fig-user-ids
:alt: Depicts a diagram with white background and the title "User IDs". Inside, a public primary component key for certification and a User ID is shown. A green arrow points from component key to User ID and is annotated with a signature.
Relationship of {term}`User ID` to primary {term}`component key` in an {term}`OpenPGP certificate`
```
A typical {term}`User ID` {term}`identity` is a UTF-8-encoded string composed of a name and an email address. By convention, {term}`User IDs<UserID>` align with the format described in [RFC2822](https://www.rfc-editor.org/rfc/rfc2822) as a *name-addr*.
For further conventions on {term}`User IDs<UserID>`, refer to the document [draft-dkg-openpgp-userid-conventions-00](https://datatracker.ietf.org/doc/draft-dkg-openpgp-userid-conventions/), dated 25 August 2023.
**Split User IDs**
One proposed variant for encoding {term}`identities<Identity>` in {term}`User IDs<UserID>` is to use ["split User IDs"](https://dkg.fifthhorseman.net/blog/2021-dkg-openpgp-transition.html#split-user-ids). Although uncommon, there are currently no significant technical barriers to implementing this format[^dkg-split].
[^dkg-split]: Historically, the OpenPGP ecosystem faced challenges in this context. For further details, refer to Daniel Kahn Gillmor's January 2019 article, ["What were Separated User IDs"](https://dkg.fifthhorseman.net/blog/2019-dkg-openpgp-transition.html#what-were-separated-user-ids).
The rationale for split {term}`User IDs<UserID>` lies in the distinction between a name and an email address, which represent two separate facets of an individual's {term}`identity`. Separating these elements simplifies the process for third parties tasked with certifying that an {term}`identity` is legitimately connected to a {term}`certificate<OpenPGPCertificate>`.
Consider this scenario: A third party is confident about the email-based {term}`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 {term}`identity` (e.g., `Alice Adams`), so are unwilling to extend the same level of {term}`certification`. Split {term}`User IDs<UserID>` address this dichotomy by allowing distinct {term}`certification` processes for each type of {term}`identity`.
(primary-user-id)=
### Implications of the Primary User ID
Within a {term}`certificate<OpenPGPCertificate>`, a specific {term}`User ID` is designated as the [Primary User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-primary-user-id).
Each {term}`User ID` carries associated preference settings, such as preferred encryption algorithms, which is detailed in {numref}`zoom-user-id`). When a {term}`certificate<OpenPGPCertificate>` is used in the context of a specific {term}`identity`, then the preferences associated with that {term}`identity component` are used. When a {term}`certificate<OpenPGPCertificate>` is used without reference to a specific {term}`identity`, the preferences associated with the {term}`direct key signature`, or the {term}`primary User ID` take precedence by default.
The {term}`primary User ID` was historically the main store for preferences that apply to the {term}`certificate<OpenPGPCertificate>` as a whole. For more on this, see {ref}`primary-metadata`.
(user-attributes)=
### User attributes in OpenPGP
While
[user attributes](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#user-attribute-packet) are similar to {term}`User IDs<UserID>`, they are less commonly used.
Currently, the OpenPGP standard prescribes only one format to be stored in user attributes: an [image](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-the-image-attribute-subpack) in JPEG format. Typically, this image represents the key owner, although it is not required.
## Linking the components
To form an {term}`OpenPGP certificate`, individual {term}`components<Component>` are interconnected by the {term}`certificate holder` using their OpenPGP software. Within OpenPGP, this process is termed "binding", as in "a {term}`subkey<OpenPGPSubkey>` is bound to the {term}`primary key<OpenPGPPrimaryKey>`." These bindings are realized using cryptographic {term}`signatures<OpenPGPSignaturePacket>`. An in-depth discussion of this topic can be found in [](signing_components).
In very abstract terms, the {term}`primary key<OpenPGPPrimaryKey>` of a {term}`certificate<OpenPGPCertificate>` acts as a root of trust or "{term}`certification authority<CertificationAuthority>`." It is responsible for:
- issuing {term}`signatures<OpenPGPSignaturePacket>` that express the {term}`certificate holder`'s intent to use specific {term}`subkeys<OpenPGPSubkey>` or {term}`identity components<IdentityComponent>`;
- conducting other lifecycle operations, including setting {term}`expiration` dates and marking {term}`components<Component>` as {term}`invalidated<Validation>` or "{term}`revoked<Revocation>`."
By binding {term}`components<Component>` using digital {term}`signatures<OpenPGPSignaturePacket>`, recipients of an {term}`OpenPGP certificate` need only {term}`validate<Validation>` the {term}`authenticity<Authentication>` of the {term}`primary key` to use for their communication partner. Traditionally, this is done by manually verifying the *{term}`fingerprint<OpenPGP Fingerprint>`* of the {term}`primary key<OpenPGPPrimaryKey>`. Once the {term}`validity<Validation>` of the {term}`primary key<OpenPGPPrimaryKey>` is confirmed, the {term}`validity<Validation>` of the remaining {term}`components<Component>` can be automatically assessed by the user's OpenPGP software. Generally, {term}`components<Component>` are {term}`valid<Validation>` parts of a {term}`certificate<OpenPGPCertificate>` if there is a statement signed by the {term}`certificate<OpenPGPCertificate>`'s {term}`primary key<OpenPGPPrimaryKey>` endorsing this {term}`validity<Validation>`.
(metadata-in-certificates)=
## Metadata in certificates
{term}`OpenPGP certificates<OpenPGPCertificate>`, their {term}`component keys<ComponentKey>`, and {term}`identities<Identity>` possess {term}`metadata` that is not stored within the {term}`components<Component>` it pertains to. Instead, this {term}`metadata` is stored within signature packets, which are integral to the structure of an OpenPGP certificate.
Key attributes, such as {term}`capabilities<Capability>` (like *signing* or *encryption*) and {term}`expiration times<ExpirationTime>`, are examples of {term}`metadata` not stored in the {term}`component key` data. How this {term}`metadata` is stored depends on the {term}`component`:
- **{term}`Primary key<OpenPGPPrimaryKey>` {term}`metadata`** is defined either through a {term}`direct key signature` on the {term}`primary key<OpenPGPPrimaryKey>` (preferred in OpenPGP version 6), or by associating the {term}`metadata` with the [Primary User ID](primary-user-id).
- **{term}`Subkey<OpenPGPSubkey>` {term}`metadata`** is defined within the [subkey binding signature](recipe-binding-subkeys) that links the {term}`subkey<OpenPGPSubkey>` to the {term}`certificate<OpenPGPCertificate>`.
- **{term}`Identity component` {term}`metadata`** is associated via the [certifying self-signature](bind-identity) that links the {term}`identity` (usually in the form of a {term}`User ID`) to the {term}`certificate<OpenPGPCertificate>`.
It is crucial to note that the {term}`components<Component>` of an {term}`OpenPGP certificate` remain static after their creation. The use of {term}`signatures<OpenPGPSignaturePacket>` to store {term}`metadata` allows for subsequent modifications without altering the original {term}`component<Component>`. For instance, a {term}`certificate holder` can update the {term}`expiration time` of a {term}`component` by issuing a new, superseding {term}`signature<OpenPGPSignaturePacket>`.
```{figure} plain_svg/Primary_key_metadata.svg
:name: fig-primary-metadata
:alt: Depicts a direct key signature, associated with a primary component key.
{term}`Metadata` can be associated with the {term}`primary key<OpenPGPPrimaryKey>` using a *{term}`direct key signature`*.
```
(key-flags)=
### Defining operational capabilities of component keys with key flags
Each {term}`component key` has a set of ["key flags"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#key-flags) that delineate the operations a key can perform.
- **{term}`Signing<SigningKeyFlag>`**: allows the key to sign data
- **{term}`Encryption<EncryptionKeyFlag>`**: allows the key to encrypt data
- **{term}`Authentication<AuthenticationKeyFlag>`**: primarily used for SSH authentication[^auth-flag]
[^auth-flag]: It's important to note that the function of the [authentication](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-authentication-via-digital-) {term}`key flag` is unrelated to the {term}`authentication` process used in certifying OpenPGP {term}`identities<Identity>` and linking them to {term}`certificate<OpenPGPCertificate>`. Rather, this flag indicates a mechanism that uses {term}`cryptographic signatures<OpenPGPSignaturePacket>` to confirm control of {term}`private key material` with a remote system.
```{note}
Distinct {term}`component keys<ComponentKey>` handle specific operations. Only the {term}`primary key<OpenPGPPrimaryKey>` can be used for {term}`certification`, although it can have additional {term}`capabilities<Capability>`. {term}`Subkeys<OpenPGPSubkey>` can be used for signing, encryption, and authentication but cannot have the {term}`certification` {term}`capability`. A {term}`component key` can technically have multiple {term}`capabilities<Capability>`. It is considered good practice, however, to [use separate keys for each capability](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-10.1.5-7).
Notably, in many algorithms, encryption and signing-related functionalities (i.e., {term}`certification<CertificationKeyFlag>`, {term}`signing<SigningKeyFlag>`, {term}`authentication<AuthenticationKeyFlag>`) are mutually exclusive, because the algorithms only support one of those two families of operations[^key-flag-sharing].
```
[^key-flag-sharing]: With ECC algorithms, it's impossible to combine {term}`encryption<EncryptionKeyFlag>` functions with those intended for {term}`signing<SigningKeyFlag>`. For example, ed25519 is specifically used for {term}`signing<SigningKeyFlag>`; cv25519 is designated for {term}`encryption<EncryptionKeyFlag>`.
(preferences-features)=
### Algorithm preferences and feature signaling
OpenPGP incorporates significant ["cryptographic agility"](https://en.wikipedia.org/wiki/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 {term}`certificate<OpenPGPCertificate>` of the passive party.
Beyond these explicitly expressed preferences, implementations also deduce {term}`capabilities<Capability>` of communication partners based on the version of the {term}`OpenPGP certificate` they possess.
#### User ID-specific preferences
As a starting point, a {term}`certificate<OpenPGPcertificate>` has a set of preferences that apply generally. These are defined either in a {term}`direct key signature`, or via the {term}`primary User ID` of the {term}`certificate<OpenPGPcertificate>`.
Additionally, OpenPGP allows modeling {term}`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 {term}`identity`-specific preferences can be expressed on the certifying {term}`signatures<OpenPGPSignaturePacket>` that bind {term}`User IDs<UserID>` to a {term}`certificate<OpenPGPcertificate>`.
## A typical OpenPGP certificate, revisited
Following our review of how {term}`keys<ComponentKey>` and {term}`identity components<IdentityComponent>` are linked, let's reexamine the {term}`OpenPGP certificate` from {numref}`fig-openpgp-certificate-components`. Our focus now extends to all of its binding signatures and the {term}`direct key signature` that contains {term}`metadata` for the full {term}`certificate<OpenPGPcertificate>`:
```{figure} plain_svg/OpenPGP_Certificate.svg
:name: fig-openpgp-certificate
:alt: Depicts an OpenPGP certificate, including a set of components, binding signatures, and a direct key signature on the primary key.
This shows a typical {term}`OpenPGP certificate`, including binding {term}`signatures<OpenPGPSignaturePacket>` for all of its {term}`components<Component>`, and a {term}`signature<OpenPGPSignaturePacket>` that associates {term}`metadata` with the {term}`primary key<OpenPGPPrimaryKey>`.
```
(revocations)=
## Revocations
When a {term}`certificate holder` needs to {term}`invalidate<Validation>` certain {term}`components<Component>` of their {term}`certificate<OpenPGPCertificate>`, or even the entire {term}`certificate<OpenPGPCertificate>`, they accomplish this through "{term}`revocation`." {term}`Revoking<Revocation>` the {term}`primary key<OpenPGPPrimaryKey>` renders the entire {term}`certificate<OpenPGPCertificate>` {term}`invalid<Validation>`.
Notably, {term}`revocations<Revocation>` are not the only means by which {term}`components<Component>` can become {term}`invalid<Validation>`. Other factors, such as the passing of a {term}`component`'s {term}`expiration time`, can also render {term}`components<Component>` {term}`invalid<Validation>`.
For more detailed information on {term}`revoking<Revocation>` specific {term}`components<Component>` of a {term}`certificate<OpenPGPCertificate>`, see the section on {ref}`self-revocations`.
(third-party-identity-certifications)=
## Third-party (identity) certifications
Since its inception, {term}`third-party identity certifications<Third-partyIdentityCertification>` have been a cornerstone of the OpenPGP ecosystem. The original PGP designers, starting with Phil Zimmermann, advocated for decentralized {term}`trust models<TrustModel>` over reliance on centralized authorities. This decentralized approach in OpenPGP is known as the ["Web of Trust."](wot)
{term}`Third-party certifications<Third-partyIdentityCertification>` are statements by OpenPGP users confirming that a user with a specific {term}`identity` is the owner of a particular {term}`OpenPGP certificate`.
For example, Bob's OpenPGP software may issue a {term}`certification` that Bob has checked that the {term}`User ID` `Alice Adams <alice@example.org>` and the {term}`certificate<OpenPGPCertificate>` with the {term}`fingerprint<OpenPGPFingerprint>` `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 {term}`certification` confirming as legitimate the link between the {term}`User ID` `Alice Adams <alice@example.org>` and the {term}`certificate<OpenPGPCertificate>` bearing the {term}`fingerprint<OpenPGPFingerprint>` `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 {term}`certificate<OpenPGPCertificate>` his OpenPGP software associates with Alice matches the one Alice uses. In essence, both users must have a {term}`certificate<OpenPGPCertificate>` for Alice with an identical {term}`fingerprint<OpenPGPFingerprint>`. In OpenPGP version 6, manual {term}`fingerprint<OpenPGPFingerprint>` comparison by end users is discouraged, with a replacement {term}`verification` mechanism still under development. The {term}`verification` process must occur over a sufficiently secure channel, such as an end-to-end encrypted video call or a face-to-face meeting.
