SPDX-FileCopyrightText: 2023 The "Notes on OpenPGP" project
SPDX-License-Identifier: CC-BY-SA-4.0
-->
# Signatures on components
This chapter examines {term}`OpenPGP signatures<OpenPGPSignaturePacket>` associated with {term}`certificate components<Component>`, applying to:
- {term}`component keys<ComponentKey>`, encompassing {term}`primary keys<OpenPGPPrimaryKey>` and {term}`subkeys<OpenPGPSubkey>`
- {term}`identity components<IdentityComponent>`, namely {term}`User IDs<UserID>` and {term}`User attributes<Userattribute>`
{term}`Signatures on components<SignatureOnComponent>` are used to construct and maintain {term}`certificates<OpenPGPCertificate>`, and to model the {term}`authentication` of {term}`identities<Identity>`.
This chapter expands on topics introduced in the [](certificates) chapter.
## Self-signatures vs third-party signatures
{term}`Component signatures<SignatureOnComponent>` in OpenPGP are categorized into two distinct types:
- **{term}`self-signatures<Self-Signature>`**, which are issued by the {term}`certificate holder` using the {term}`certificate<OpenPGPCertificate>`'s {term}`primary key<OpenPGPPrimaryKey>`
- **{term}`third-party signatures<Third-partySignature>`**, which are issued by an external entity, not the {term}`certificate holder`
(self-signatures)=
### Self-signatures
{term}`Self-signatures<Self-signature>` are fundamental in creating and managing {term}`OpenPGP certificates<OpenPGPCertificate>`. They bind the various {term}`components<Component>` of a {term}`certificate<OpenPGPCertificate>` into one combined data structure and facilitate the {term}`certificate<OpenPGPCertificate>`'s {term}`life-cycle management`.
{term}`Life-cycle management` operations include:
- {term}`binding<BindingSignature>` additional {term}`components<Component>` to a {term}`certificate<OpenPGPCertificate>`
- revoking, and thus invalidating, {term}`components<Component>` or existing {term}`self-signatures<Self-signature>`
{term}`Self-signatures<Self-signature>` are issued by the {term}`certificate's owner<CertificateHolder>` using the {term}`certificate<OpenPGPCertificate>`'s {term}`primary key<OpenPGPPrimaryKey>`.
```{note}
No [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) is required to issue {term}`self-signatures<Self-signature>`. An {term}`OpenPGP primary key` can issue {term}`self-signatures<Self-signature>` by default.
```
### Third-party signatures
{term}`Third-party signatures<Third-partySignature>` are pivotal in OpenPGP for decentralized {term}`authentication`, forming the basis of the {term}`Web of Trust`. They encode {term}`authentication`-related statements about {term}`certificates<OpenPGPCertificate>` and linked {term}`identities<Identity>`, establishing trustworthiness of {term}`identity claims<IdentityClaim>`.
Third-party signatures are used to make specific statements:
- {term}`revoking<Revocation>`, and thus {term}`invalidating<Validation>`, prior {term}`third-party signature` statements
```{note}
The **{term}`certify others<CertificationKeyFlag>`** [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) (`0x01`) is required to issue {term}`third-party signatures<Third-partySignature>`. By convention[^primary-certification], only the {term}`certificate<OpenPGPCertificate>`'s {term}`primary key<OpenPGPPrimaryKey>` can hold this {term}`key flag`.
```
[^primary-certification]: Most current {term}`implementations<OpenPGPImplementation>` assume that only the {term}`primary key<OpenPGPPrimaryKey>` may hold the *{term}`certify others<Certification Key Flag>`* {term}`key flag`, although this is not specified in the {term}`RFC`.
### Distinct functions of self-signatures and third-party signatures
The meaning of an {term}`OpenPGP signature<OpenPGPSignaturePacket>` depends significantly on its {term}`issuer`. {term}`Self-signatures<Self-signature>` and {term}`third-party signatures<Third-partySignature>`, even when of the same [signature type](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-types), serve distinct functions. For example:
- {term}`Certifying self-signatures<CertifyingSelf-signature>` ({term}`type IDs<SignatureTypeID>` `0x10` - `0x13`) bind a {term}`User ID` to a {term}`certificate<OpenPGPCertificate>`.
- {term}`Third-party signatures<Third-partySignature>` of the same {term}`type IDs<SignatureTypeID>` endorse the {term}`authenticity<Authentication>` of a {term}`User ID` on another user's {term}`certificate<OpenPGPCertificate>`.
In another instance:
- *When issued as a {term}`self-signature`*, a [direct key signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) sets {term}`preferences<AlgorithmPreferences>` and advertises {term}`features<FeaturesSubpacket>` applicable to the entire {term}`certificate<OpenPGPCertificate>`.
- *When issued by a {term}`third party<Third-partySignature>`*, especially when it carries a [trust signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-trust-signature) {term}`subpacket<OpenPGPSignatureSubpacket>`, a similar {term}`direct key signature` {term}`delegates<Delegation>` trust to the signed {term}`certificate<OpenPGPCertificate>`. This may designate the signed {term}`certificate<OpenPGPCertificate>` as a {term}`trust anchor` within the {term}`issuer`'s {term}`Web of Trust`.
(binding-signatures)=
## Self-signatures in certificate formation and management
{term}`Self-signatures<Self-signature>` play a crucial role in forming and managing the structure of {term}`OpenPGP certificates<OpenPGPcertificate>`. These act as *{term}`binding signatures<Binding Signature>`*, joining {term}`components<Component>` and embedding {term}`metadata`.
Internally, an {term}`OpenPGP certificate` is essentially a series of {term}`packets<Packet>` strung sequentially. When a {term}`certificate<OpenPGPCertificate>` is stored in a file format known as a [transferable public key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-transferable-public-keys), {term}`packets<Packet>` can be easily added or removed.
To safeguard against unauthorized additions or alterations of {term}`components<Component>`, OpenPGP uses {term}`cryptographic signatures<CryptographicSignature>`. These validate that all {term}`components<Component>`, such as {term}`subkeys<OpenPGPSubkey>` or [identity components](identity-components), were linked to the {term}`OpenPGP certificate` by its {term}`owner<CertificateHolder>`, using the {term}`primary key<OpenPGPPrimaryKey>`. While anyone can still store unrelated elements to a {term}`certificate<OpenPGPCertificate>` dataset, {term}`OpenPGP implementations<OpenPGPimplementation>` will reject them if they lack a {term}`valid<Validation>` cryptographic connection with the {term}`certificate<OpenPGPCertificate>`.
```{note}
Conversely, omissions of {term}`packets<Packet>` by third parties can easily occur when handling an {term}`OpenPGP certificate` dataset. This could pose a challenge, for example, when an attacker deliberately omits {term}`revocation` {term}`packets<Packet>`. Without access to an alternative, complete {term}`certificate<OpenPGPCertificate>` source, recipients might not detect these omissions.
```
However, there are legitimate instances in which third parties add "unbound" {term}`packets<Packet>` (i.e., not signed by the {term}`certificate<OpenPGPCertificate>`'s {term}`owner<CertificateHolder>`) to a {term}`certificate<OpenPGPCertificate>`:
- [Third-party certifications](third-party-certifications) are often stored within the {term}`packet` data of the {term}`certificate<OpenPGPCertificate>` to which they are related. This is a standard practice that provides convenience for users by allowing easy access to all relevant {term}`certifications<Certification>`. (See [](keyserver-flooding) for discussion of a related pitfall.)
- {term}`OpenPGP software<OpenPGPImplementation>` may locally add [unbound identity data](unbound-user-ids) to a {term}`certificate<OpenPGPCertificate>`.
(bind-subkey)=
### Binding subkeys to a certificate
{term}`Subkeys<OpenPGPSubkey>` are linked to {term}`OpenPGP certificates<OpenPGPcertificate>` via a [subkey binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-subkey-binding) ({term}`type ID<SignatureTypeID>` `0x18`). This {term}`signature type<OpenPGPSignatureType>` indicates the association of the {term}`primary key<OpenPGPPrimaryKey>` with the {term}`subkey<OpenPGPSubkey>`.
A {term}`subkey binding signature` binds a {term}`subkey<OpenPGPSubkey>` to a {term}`primary key<OpenPGPPrimaryKey>`, and it embeds {term}`metadata` into the {term}`signature packet<OpenPGPSignaturePacket>`. Once generated, the {term}`subkey binding signature` {term}`packet` is stored in the {term}`certificate<OpenPGPCertificate>` directly after the {term}`subkey<OpenPGPSubkey>` it binds.
{term}`Subkeys<OpenPGPSubkey>` designated for signing purposes, identified by the *{term}`signing<Signing Key Flag>`* [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags), represent a unique category and are handled differently. See {numref}`bind-signing-subkey`.
:alt: Depicts a diagram on white background with the title "Subkey binding signature". At the top left the symbol of a primary component key with certification capability is shown. At the bottom left the symbol of a component key with encryption capability is shown. The primary component key points at the lower component key with a full green arrow line. In the middle of the connection the small symbol of a signature packet is shown. On the right side of the diagram a detailed version of the signature packet can be found in a box with the title "Subkey binding signature". The text reads "Signature over Primary key, Subkey" and the box with "Signature metadata" contains the list "signature creation time", "key expiration time", "key flags" and "issuer fingerprint". The primary component key points at the detailed signature packet with a dotted green arrow line and the text "Primary key creates a subkey binding signature to bind the subkey to the primary key".
Linking an {term}`OpenPGP subkey` to the {term}`primary key<OpenPGPPrimaryKey>` with a {term}`binding signature`
```
{term}`Metadata` for the {term}`subkey`, such as the [*key expiration time*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#key-expiration-subpacket) and {term}`capabilities<Capability>` set by [*key flags*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#key-flags), are included in {term}`subpackets<OpenPGPSignatureSubpacket>` within the {term}`subkey binding signature` {term}`packet`.
```{note}
The {term}`validity<Validation>` of a {term}`subkey<OpenPGPSubkey>` is intrinsically linked to that of the {term}`primary key<OpenPGPPrimaryKey>`. An {term}`expired<Expiration>` {term}`primary key<OpenPGPPrimaryKey>` renders any associated {term}`subkey<OpenPGPSubkey>` {term}`invalid<Validation>`, regardless of the {term}`subkey<OpenPGPSubkey>`'s own {term}`expiration` setting.
Legally, a {term}`subkey<OpenPGPSubkey>` may not have a specified {term}`expiration time`. In such cases, its {term}`expiration` aligns implicitly with that of the {term}`primary key<OpenPGPPrimaryKey>`. Additionally, the {term}`creation time` of a {term}`subkey<OpenPGPSubkey>` must always be more recent than that of the {term}`primary key<OpenPGPPrimaryKey>`.
```
(bind-signing-subkey)=
### Special case: Binding signing subkeys
{term}`Binding` {term}`subkeys<OpenPGPSubkey>` that possess the *{term}`signing<Signing Key Flag>`* {term}`key flag` to a {term}`certificate<OpenPGPCertificate>` represents a unique scenario. While similar to the {term}`binding process<Binding>` of other {term}`subkeys<OpenPGPSubkey>`, there is an additional, critical requirement: mutual association.
That is, to bind a {term}`signing-capable<SigningKeyFlag>` {term}`subkey<OpenPGPSubkey>` to a {term}`primary key<OpenPGPPrimaryKey>`, it is insufficient that the "{term}`primary key<OpenPGPPrimaryKey>` wants to be associated with the {term}`subkey<OpenPGPSubkey>`." The {term}`subkey<OpenPGPSubkey>` must explicitly signal that it "wants to be associated with the {term}`primary key<OpenPGPPrimaryKey>`."
This mutual binding is crucial for security. Without it, an individual (e.g., Alice) could falsely claim a connection to another person's (e.g., Bob's) {term}`signing subkey<OpenPGPSigningSubkey>`.
Alice could thus claim to have issued {term}`signatures<OpenPGPSignaturePacket>` which were actually issued by Bob.
To prevent such scenarios, where an attacker might wrongfully "adopt" a victim's {term}`signing subkey<OpenPGPSigningSubkey>`, a dual-layer of {term}`signatures<OpenPGPSignaturePacket>` is used:
- the [subkey binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-subkey-binding) ({term}`type ID<SignatureTypeID>` `0x18`), which is issued by the {term}`certificate<OpenPGPCertificate>`'s {term}`primary key<OpenPGPPrimaryKey>`
- the [primary key binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-primary-binding) ({term}`type ID<SignatureTypeID>` `0x19`), created by the {term}`subkey<OpenPGPSubkey>` itself. This is informally known as an embedded "{term}`back signature<PrimaryKeyBindingSignature>`," because the {term}`subkey<OpenPGPSubkey>`'s {term}`signature<OpenPGPSignaturePacket>` points back to the {term}`primary key<OpenPGPPrimaryKey>`.
:alt: Depicts a diagram on white background with the title "Subkey binding signature for signing subkeys". At the top left the symbol of a primary component key with certification capability is shown. At the bottom left the symbol of a component key with signing capability is shown. The primary component key points at the lower component key with a full green arrow line. In the middle of the connection the small symbol of a signature packet is shown. On the right side of the diagram a detailed version of the signature packet can be found in a box with the title "Subkey binding signature". The text reads "Signature over Primary key, Subkey" and the box with "Signature metadata" in it contains the list "signature creation time", "key expiration time", "key flags" and "issuer fingerprint". Within the signature metadata a box with a green dotted frame extends the list with an inlined signature packet with the title "Embedded Signature; Primary key binding". Its inner text reads "Signature over Primary Key, Signing Subkey". The signature metadata area of this embedded signature holds the list "signature creation time" and "issuer fingerprint". The cryptographic signature symbol overlaps both metadata and general section of the embedded signature. From the signing component key a green dotted arrow line points to the embedded signature in the subkey binding signature with the text "Signing key creates a primary binding signature to associate itself with the primary key" ("primary binding signature" in bold). At the top of the diagram, the primary component key points at the detailed signature packet with a dotted green arrow line and the text "Primary key creates a subkey binding signature to bind the subkey to the primary key".
Linking an {term}`OpenPGP signing subkey` to the {term}`primary key<OpenPGPPrimaryKey>` with a {term}`binding signature`, and an embedded {term}`primary key binding signature`
```
The {term}`back signature<PrimaryKeyBindingSignature>` signifies the mutuality of the {term}`subkey<OpenPGPSubkey>`'s association with the {term}`primary key<OpenPGPPrimaryKey>` and is embedded as {term}`subpacket<OpenPGPSignatureSubpacket>` data within the {term}`subkey binding signature`, reinforcing the {term}`authenticity<Authentication>` of the {term}`binding`.
(bind-identity)=
### Binding identities to a certificate
{term}`Self-signatures<Self-signature>` also play a vital role in {term}`binding` {term}`identity components<IdentityComponent>`, such as {term}`User IDs<UserID>` or {term}`User Attributes<UserAttribute>`, to an {term}`OpenPGP certificate`.
To bind the {term}`User ID` `Alice Adams <alice@example.org>` to her {term}`OpenPGP certificate` (`AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3`), Alice would use a {term}`certification signature<CertifyingSelf-signature>`.
There are four types of *{term}`certifying self-signature`*. The most commonly used {term}`type<SignatureTypeID>` for {term}`binding` {term}`User IDs<UserID>` is the [positive certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-positive-cert) ({term}`type ID<SignatureTypeID>` `0x13`). Alternatively, {term}`type<SignatureTypeID>` `0x10`, `0x11`, or `0x12` might be used. This {term}`binding signature` must be issued by the {term}`primary key<OpenPGPPrimaryKey>`.
The {term}`certifying self-signature` {term}`packet` – calculated over the {term}`primary key<OpenPGPPrimaryKey>`, {term}`User ID`, and {term}`metadata` of the {term}`signature packet<OpenPGPSignaturePacket>` – is added to the {term}`certificate<OpenPGPCertificate>`, directly following the {term}`User ID` {term}`packet`.
```{figure} plain_svg/user_id_certification.svg
:name: fig-user-id-certification
:alt: Depicts a diagram on white background with the title "User ID binding signature". At the top left the symbol of a primary component key with certification capability is shown. At the bottom left the symbol of a User ID reads "Alice Adams <alice@example.org>". The primary component key points at the User ID with a full green arrow line. In the middle of the connection the small symbol of a signature packet is shown. On the right side of the diagram a detailed version of the signature packet can be found in a box with the title "User ID binding signature". The text reads "Signature over Primary key, User ID" and the box with "Signature metadata" in it contains the list "signature creation time", "key expiration time", "primary User ID flag", "algorithm preferences", "key expiration time (primary key)" and "key flags (primary key)". At the top of the diagram, the primary component key points at the detailed signature packet with a dotted green arrow line and the text "Primary key creates a User ID binding signature to associate the User ID with the primary key".
Linking a {term}`User ID` to an {term}`OpenPGP certificate`
```
(primary-metadata)=
### Adding global metadata to a certificate
The {term}`signatures<OpenPGPSignaturePacket>` that {term}`bind<Binding>` {term}`subkeys<OpenPGPSubkey>` and {term}`identity components<IdentityComponent>` to a {term}`certificate<OpenPGPCertificate>` serve dual purposes: linking {term}`components<Component>` to the {term}`certificate<OpenPGPCertificate>` and adding {term}`metadata` to {term}`components<Component>`.
While it is essential to add {term}`metadata` that pertains to the entire {term}`certificate<OpenPGPCertificate>`, this does not require {term}`binding` any {term}`component` to the {term}`certificate<OpenPGPCertificate>`. In this case, the {term}`signature<OpenPGPSignaturePacket>` mechanism is used just to associate {term}`metadata` with the {term}`certificate<OpenPGPCertificate>` globally.
Two {term}`signature types<OpenPGPSignatureType>` can perform this function:
- {term}`direct key signature` on the {term}`primary key<OpenPGPPrimaryKey>`
- {term}`primary User ID binding signature`
The types of {term}`metadata` typically associated with the {term}`certificate<OpenPGPCertificate>` through these methods include:
A [*direct key signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) serves as the [preferred mechanism](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.2.3.10-9) in OpenPGP v6 for defining {term}`metadata` for the entire {term}`certificate<OpenPGPCertificate>`, by associating it with the {term}`primary key<OpenPGPPrimaryKey>`.
(primary-user-id-binding)=
#### Self-signature binding to primary User ID
In OpenPGP v4, another mechanism was often used for {term}`metadata` management: integrating global {term}`certificate<OpenPGPCertificate>` {term}`metadata` within a {term}`User ID binding signature`. This is specifically evident in the {term}`binding signature` of the [*primary* User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-primary-user-id) of the {term}`OpenPGP certificate`.
This method results in the {term}`primary User ID binding signature` containing a mix of {term}`metadata`: some specific to that {term}`User ID` and some applicable to the {term}`certificate` globally.
Given the widespread adoption of this mechanism in existing {term}`OpenPGP certificates<OpenPGPcertificate>`, it is crucial that {term}`OpenPGP applications<OpenPGPImplementation>` recognize and manage it.
{term}`Revocation self-signatures<RevocationSelf-signature>` represent an important class of {term}`self-signatures<Self-signature>`, used primarily to invalidate {term}`components<Component>` or retract prior {term}`signature<OpenPGPSignaturePacket>` statements.
There are several types of {term}`revocation signatures<RevocationSelf-signature>`, each serving a specific purpose:
- A [**key revocation signature**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-revocation-signature-ty) ({term}`type ID<SignatureTypeID>` `0x20`) marks a {term}`primary key<OpenPGPPrimaryKey>` as {term}`revoked<Revocation>`.
- A [**subkey revocation signature**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-subkey-revocation-signature) ({term}`type ID<SignatureTypeID>` `0x28`) {term}`invalidates<Validation>` the {term}`binding of a subkey<SubkeyBindingSignature>`.
- A [**certification revocation**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-certification-revocation-si) ({term}`type ID<SignatureTypeID>` `0x30`) {term}`invalidates<Validation>` the {term}`binding` of a {term}`User ID` or {term}`User Attribute`.
Common scenarios for using {term}`revocations<Revocation>` include marking {term}`certificates<OpenPGPCertificate>` or individual {term}`subkeys<OpenPGPSubkey>` as unusable (e.g., when the {term}`private key<TransferableSecretKey>` has been compromised or replaced) or declaring {term}`User IDs<UserID>` as no longer {term}`valid<Validation>`.
```{note}
{term}`OpenPGP certificates<OpenPGPCertificate>` act as append-only data structures in practice. Once elements of a {term}`certificate<OpenPGPCertificate>` are published, they cannot be removed from {term}`key servers<KeyServer>` or third-party OpenPGP systems. {term}`Implementations<OpenPGPImplementation>` usually merge all available {term}`components<Component>` and {term}`signatures<OpenPGPSignaturePacket>`.
{term}`Revocations<Revocation>` are used to mark {term}`components<Component>` or {term}`signatures<OpenPGPSignaturePacket>` as {term}`invalid<Validation>`.
```
Note: {term}`certification signatures<Certification>` [can be made irrevocable](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-revocable).
(hard-vs-soft-revocations)=
#### Hard vs soft revocations
{term}`Revocation signatures<RevocationSelf-signature>` often include a [*Reason for Revocation* subpacket](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-reason-for-revocation), with a code specifying *why* the {term}`revocation<RevocationSelf-signature>` was issued. This code determines whether the {term}`revocation` is considered *soft* or *hard*.
- **{term}`Soft revocation`**: This is typically used for graceful or planned {term}`invalidation<Validation>` of {term}`components<Component>`, such as retiring or updating {term}`components<Component>`. It {term}`invalidates<Validation>` the {term}`component` from the {term}`revocation signature<RevocationSelf-signature>`'s {term}`creation time`, but earlier uses remain {term}`valid<Validation>`. Soft revocations can be reversed with a new {term}`self-signature`.
- **{term}`Hard revocation`**: This irrevocably invalidates the {term}`component`, affecting all past and future uses. It is typically used to signal compromise of {term}`secret key material<PrivateKeyMaterial>`.
```{note}
A {term}`revocation signature packet` lacking a {term}`Reason for Revocation subpacket` is interpreted as a {term}`hard revocation`.
```
(third-party-certifications)=
## Authentication and delegation in third-party signatures
{term}`Third-party signatures<Third-partySignature>` in OpenPGP primarily encode {term}`authentication` statements for {term}`identities<Identity>` and {term}`delegate<Delegation>` trust decisions. These {term}`signatures<OpenPGPSignaturePacket>` can be manually inspected or processed as machine-readable artifacts by {term}`OpenPGP software<OpenPGPImplementation>`, which evaluates the {term}`authenticity<Authentication>` of {term}`certificates<OpenPGPCertificate>` based on user-specified {term}`trust anchors<TrustAnchor>`.
### Certifying identity components
When a {term}`signer` issues a {term}`certifying signature<Certification>` on an {term}`identity`, it indicates a verified link between the {term}`identity` and the {term}`certificate<OpenPGPCertificate>`. That is, the {term}`signer` vouches for the {term}`identity claim`.
For example, Alice can vouch that Bob's {term}`User ID` `Bob Baker <bob@example.com>` is legitimately linked with his {term}`certificate<OpenPGPCertificate>` `BB28 9FB7 A68D BFA8 C384 CCCD E205 8E02 D9C6 CD2F 3C7C 56AE 7FB5 3D97 1170 BA83`, by creating a {term}`certification signature<Certification>`. Bob can then distribute Alice's `certifying signature<Certification>` as part of his {term}`certificate<OpenPGPCertificate>`.
Other users may or may not decide to rely on Alice's statement to determine the {term}`authenticity<Authentication>` of Bob's {term}`certificate<OpenPGPCertificate>`.
(delegation)=
### Trust signatures: delegating authentication
OpenPGP uses [*trust signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#trust-signature-subpacket) {term}`subpackets<OpenPGPSignatureSubpacket>` to {term}`delegate<Delegation>` {term}`authentication` decisions, designating the recipient {term}`certificate<OpenPGPCertificate>` as a "{term}`trusted introducer`" (or a {term}`trust anchor`) for the user. This includes specifying {term}`trust depth` (or level) for transitive {term}`delegations<Delegation>` and quantifying trust with numerical values, indicating the extent of reliance on the {term}`introducer<TrustedIntroducer>`'s {term}`certifications<Certification>`.
{term}`Trust signature` {term}`subpackets<OpenPGPSignatureSubpacket>` are applicable in {term}`third-party signatures<Third-partySignature>`, more specifically:
The "{term}`trust depth`" (or {term}`level<TrustDepth>`) in OpenPGP signifies the extent of transitive {term}`delegation` within the {term}`authentication` process. It determines how far a {term}`delegation` can be extended from the original {term}`trusted introducer` to subsequent intermediaries. Essentially, a {term}`certificate<OpenPGPCertificate>` with a {term}`trust depth` of more than one acts as a "{term}`meta-introducer`," facilitating {term}`authentication` decisions across multiple levels in the network.
A {term}`trust depth` of 1 means relying on {term}`certifications<Certification>` made directly by the {term}`trusted introducer`. The user's OpenPGP software will accept {term}`certifications<Certification>` made directly by the {term}`introducer<TrustedIntroducer>` for {term}`authenticating<Authentication>` identities.
However, when the {term}`trust depth` is set higher, it implies a chain of {term}`delegation` may extend beyond the {term}`initial introducer`. The user's software will recognize and accept {term}`certifications<Certification>` made not only by the {term}`primary introducer<InitialIntroducer>` but also by other intermediaries whom the {term}`primary introducer<InitialIntroducer>` designated as {term}`trusted introducers<TrustedIntroducer>`.
This allows for a more extensive network of trusted {term}`certifications<Certification>`, enabling a broader and more interconnected {term}`Web of Trust`.
(trust-amount)=
#### Trust amounts
The "{term}`trust amount`," with a numerical value ranging from `0` to `255`, quantifies the degree of reliance on a {term}`delegation`.
A higher value indicates greater degree of reliance. This quantification aids {term}`OpenPGP software<OpenPGPImplementation>` in determining an aggregate amount of reliance, based on combined {term}`certifications<Certification>` from multiple {term}`trusted introducers<TrustedIntroducer>`.
(trust-scope)=
#### Limiting delegation scope
When using *{term}`trust signature`* {term}`subpackets<OpenPGPSignatureSubpacket>`, a {term}`delegation` can be limited to {term}`identities<Identity>` that match a [*regular expression*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#regex-subpacket).
With this mechanism, for example, it is possible to {term}`delegate<Delegation>` {term}`authentication` decisions only for {term}`User IDs<UserID>` that match the email domain of an organization.
The {term}`Web of Trust` in OpenPGP is a {term}`trust model` that facilitates {term}`authentication` decisions through a network of {term}`certifications<Certification>` and {term}`delegations<Delegation>`. It is characterized by a so-called [strong set](https://en.wikipedia.org/wiki/Web_of_trust#Strong_set), which refers to a group of {term}`certificates<OpenPGPCertificate>` that are robustly interconnected via {term}`third-party certifications<Third-partyIdentityCertification>`.
In this model, users independently {term}`delegate<Delegation>` {term}`authentication` decisions, choosing whose {term}`certification` to rely on. This {term}`delegation` is based on the {term}`certificates<OpenPGPCertificate>` and {term}`third-party signatures<Third-partySignature>` available to them, with their {term}`OpenPGP software<OpenPGPImplementation>` applying the {term}`Web of Trust` mechanism to discern the reliability of each {term}`certificate<OpenPGPCertificate>` for an {term}`identity`.
The {term}`OpenPGP RFC<RFC>` doesn't specify exactly how {term}`Web of Trust` calculations are performed. It only defines the data formats on which these calculations can be performed.
### Revoking third-party signatures
To reverse a previously issued {term}`third-party signature`, the {term}`issuer` can generate a [*certification revocation signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-certification-revocation-si) ({term}`type ID<SignatureTypeID>` `0x30`). The {term}`revocation` must be issued by the same {term}`key<ComponentKey>` that created the original {term}`signature<OpenPGPSignaturePacket>` or, in deprecated practice, by a designated [Revocation Key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-revocation-key).
