openpgp-notes/book/source/08-signing_components.md

(component_signatures_chapter)=

Signatures on components

This chapter examines {term}OpenPGP signatures<OpenPGP Signature Packet> associated with {term}certificate components<Component>, applying to:

• {term}component keys<Component Key>, encompassing {term}primary keys<OpenPGP Primary Key> and {term}subkeys<OpenPGP Subkey>
• {term}identity components<Identity Component>, namely {term}User IDs<User ID> and {term}User attributes<User attribute>

{term}Signatures on components<Signature On Component> are used to construct and maintain {term}certificates<OpenPGP Certificate>, and to model the {term}authentication of {term}identities<Identity>.

This chapter expands on topics introduced in the {ref}certificates_chapter chapter.

Self-signatures vs third-party signatures

{term}Component signatures<Signature On Component> 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<OpenPGP Certificate>'s {term}primary key<OpenPGP Primary Key>
• {term}third-party signatures<Third-party Signature>, 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<OpenPGP Certificate>. They bind the various {term}components<Component> of a {term}certificate<OpenPGP Certificate> into one combined data structure and facilitate the {term}certificate<OpenPGP Certificate>'s {term}life-cycle management.

{term}Life-cycle management operations include:

• {term}binding<Binding Signature> additional {term}components<Component> to a {term}certificate<OpenPGP Certificate>
• modifying {term}expiration time or other {term}metadata of components<Component>
• 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<Certificate Holder> using the {term}certificate<OpenPGP Certificate>'s {term}primary key<OpenPGP Primary Key>.

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-party Signature> 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<OpenPGP Certificate> and linked {term}identities<Identity>, establishing trustworthiness of {term}identity claims<Identity Claim>.

Third-party signatures are used to make specific statements:

• {term}certifying<Certification> {term}identity claims<Identity Claim>
• {term}delegating<Delegation> {term}authentication decisions
• {term}revoking<Revocation>, and thus {term}invalidating<Validation>, prior {term}third-party signature statements

The **{term}`certify others<Certification Key Flag>`** [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-party Signature>`. By convention[^primary-certification], only the {term}`certificate<OpenPGP Certificate>`'s {term}`primary key<OpenPGP Primary Key>` can hold this {term}`key flag`.

Distinct functions of self-signatures and third-party signatures

The meaning of an {term}OpenPGP signature<OpenPGP Signature Packet> depends significantly on its {term}issuer. {term}Self-signatures<Self-signature> and {term}third-party signatures<Third-party Signature>, even when of the same signature type, serve distinct functions. For example:

• {term}Certifying self-signatures<Certifying Self-signature> ({term}type IDs<Signature Type ID> 0x10 - 0x13) bind a {term}User ID to a {term}certificate<OpenPGP Certificate>.
• {term}Third-party signatures<Third-party Signature> of the same {term}type IDs<Signature Type ID> endorse the {term}authenticity<Authentication> of a {term}User ID on another user's {term}certificate<OpenPGP Certificate>.

In another instance:

• When issued as a {term}self-signature, a direct key signature sets {term}preferences<Algorithm Preferences> and advertises {term}features<Features Subpacket> applicable to the entire {term}certificate<OpenPGP Certificate>.
• When issued by a {term}third party<Third-party Signature>, especially when it carries a trust signature {term}subpacket<OpenPGP Signature Subpacket>, a similar {term}direct key signature {term}delegates<Delegation> trust to the signed {term}certificate<OpenPGP Certificate>. This may designate the signed {term}certificate<OpenPGP Certificate> as a {term}trust anchor within the {term}issuer's {term}Web of Trust.

(binding_sigs)=

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<OpenPGP certificate>. 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<OpenPGP Certificate> is stored in a file format known as a transferable public key, {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<Cryptographic Signature>. These validate that all {term}components<Component>, such as {term}subkeys<OpenPGP Subkey> or identity components, were linked to the {term}OpenPGP certificate by its {term}owner<Certificate Holder>, using the {term}primary key<OpenPGP Primary Key>. While anyone can still store unrelated elements to a {term}certificate<OpenPGP Certificate> dataset, {term}OpenPGP implementations<OpenPGP implementation> will reject them if they lack a {term}valid<Validation> cryptographic connection with the {term}certificate<OpenPGP Certificate>.

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<OpenPGP Certificate>` 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<OpenPGP Certificate>'s {term}owner<Certificate Holder>) to a {term}certificate<OpenPGP Certificate>:

• Third-party certifications are often stored within the {term}packet data of the {term}certificate<OpenPGP Certificate> 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 {ref}cert-flooding for discussion of a related pitfall.)
• {term}OpenPGP software<OpenPGP Implementation> may locally add unbound identity data to a {term}certificate<OpenPGP Certificate>.

(bind_subkey)=

Binding subkeys to a certificate

{term}Subkeys<OpenPGP Subkey> are linked to {term}OpenPGP certificates<OpenPGP certificate> via a subkey binding signature ({term}type ID<Signature Type ID> 0x18). This {term}signature type<OpenPGP Signature Type> indicates the association of the {term}primary key<OpenPGP Primary Key> with the {term}subkey<OpenPGP Subkey>.

A {term}subkey binding signature binds a {term}subkey<OpenPGP Subkey> to a {term}primary key<OpenPGP Primary Key>, and it embeds {term}metadata into the {term}signature packet<OpenPGP Signature Packet>. Once generated, the {term}subkey binding signature {term}packet is stored in the {term}certificate<OpenPGP Certificate> directly after the {term}subkey<OpenPGP Subkey> it binds.

{term}Subkeys<OpenPGP Subkey> designated for signing purposes, identified by the {term}signing<Signing Key Flag> key flag, represent a unique category and are handled differently. See {numref}bind_subkey_sign.

:name: fig-subkey-binding-signature
: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<OpenPGP Primary Key>` with a {term}`binding signature`

{term}Metadata for the {term}subkey, such as the key expiration time and {term}capabilities<Capability> set by key flags, are included in {term}subpackets<OpenPGP Signature Subpacket> within the {term}subkey binding signature {term}packet.

The {term}`validity<Validation>` of a {term}`subkey<OpenPGP Subkey>` is intrinsically linked to that of the {term}`primary key<OpenPGP Primary Key>`. An {term}`expired<Expiration>` {term}`primary key<OpenPGP Primary Key>` renders any associated {term}`subkey<OpenPGP Subkey>` {term}`invalid<Validation>`, regardless of the {term}`subkey<OpenPGP Subkey>`'s own {term}`expiration` setting.

Legally, a {term}`subkey<OpenPGP Subkey>` may not have a specified {term}`expiration time`. In such cases, its {term}`expiration` aligns implicitly with that of the {term}`primary key<OpenPGP Primary Key>`. Additionally, the {term}`creation time` of a {term}`subkey<OpenPGP Subkey>` must always be more recent than that of the {term}`primary key<OpenPGP Primary Key>`.

(bind_subkey_sign)=

Special case: Binding signing subkeys

{term}Binding {term}subkeys<OpenPGP Subkey> that possess the {term}signing<Signing Key Flag> {term}key flag to a {term}certificate<OpenPGP Certificate> represents a unique scenario. While similar to the {term}binding process<Binding> of other {term}subkeys<OpenPGP Subkey>, there is an additional, critical requirement: mutual association.

That is, to bind a {term}signing-capable<Signing Key Flag> {term}subkey<OpenPGP Subkey> to a {term}primary key<OpenPGP Primary Key>, it is insufficient that the "{term}primary key<OpenPGP Primary Key> wants to be associated with the {term}subkey<OpenPGP Subkey>." The {term}subkey<OpenPGP Subkey> must explicitly signal that it "wants to be associated with the {term}primary key<OpenPGP Primary Key>."

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<OpenPGP Signing Subkey>. Alice could thus claim to have issued {term}signatures<OpenPGP Signature Packet> which were actually issued by Bob. To prevent such scenarios, where an attacker might wrongfully "adopt" a victim's {term}signing subkey<OpenPGP Signing Subkey>, a dual-layer of {term}signatures<OpenPGP Signature Packet> is used:

• the subkey binding signature ({term}type ID<Signature Type ID> 0x18), which is issued by the {term}certificate<OpenPGP Certificate>'s {term}primary key<OpenPGP Primary Key>
• the primary key binding signature ({term}type ID<Signature Type ID> 0x19), created by the {term}subkey<OpenPGP Subkey> itself. This is informally known as an embedded "{term}back signature<Primary Key Binding Signature>," because the {term}subkey<OpenPGP Subkey>'s {term}signature<OpenPGP Signature Packet> points back to the {term}primary key<OpenPGP Primary Key>.

:name: fig-subkey-binding-signature-for-signing-subkeys
: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<OpenPGP Primary Key>` with a {term}`binding signature`, and an embedded {term}`primary key binding signature`

The {term}back signature<Primary Key Binding Signature> signifies the mutuality of the {term}subkey<OpenPGP Subkey>'s association with the {term}primary key<OpenPGP Primary Key> and is embedded as {term}subpacket<OpenPGP Signature Subpacket> data within the {term}subkey binding signature, reinforcing the {term}authenticity<Authentication> of the {term}binding.

(bind_ident)=

Binding identities to a certificate

{term}Self-signatures<Self-signature> also play a vital role in {term}binding {term}identity components<Identity Component>, such as {term}User IDs<User ID> or {term}User Attributes<User Attribute>, 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<Certifying Self-signature>.

There are four types of {term}certifying self-signature. The most commonly used {term}type<Signature Type ID> for {term}binding {term}User IDs<User ID> is the positive certification ({term}type ID<Signature Type ID> 0x13). Alternatively, {term}type<Signature Type ID> 0x10, 0x11, or 0x12 might be used. This {term}binding signature must be issued by the {term}primary key<OpenPGP Primary Key>.

The {term}certifying self-signature {term}packet – calculated over the {term}primary key<OpenPGP Primary Key>, {term}User ID, and {term}metadata of the {term}signature packet<OpenPGP Signature Packet> – is added to the {term}certificate<OpenPGP Certificate>, directly following the {term}User ID {term}packet.

: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<OpenPGP Signature Packet> that {term}bind<Binding> {term}subkeys<OpenPGP Subkey> and {term}identity components<Identity Component> to a {term}certificate<OpenPGP Certificate> serve dual purposes: linking {term}components<Component> to the {term}certificate<OpenPGP Certificate> and adding {term}metadata to {term}components<Component>.

While it is essential to add {term}metadata that pertains to the entire {term}certificate<OpenPGP Certificate>, this does not require {term}binding any {term}component to the {term}certificate<OpenPGP Certificate>. In this case, the {term}signature<OpenPGP Signature Packet> mechanism is used just to associate {term}metadata with the {term}certificate<OpenPGP Certificate> globally.

Two {term}signature types<OpenPGP Signature Type> can perform this function:

• {term}direct key signature on the {term}primary key<OpenPGP Primary Key>
• {term}primary User ID binding signature

The types of {term}metadata typically associated with the {term}certificate<OpenPGP Certificate> through these methods include:

• {term}key {term}expiration
• {term}key flags<Key Flag> ({term}capabilities<Capability>)
• {term}features<Features Subpacket>
• {term}algorithm preferences signaling

(direct_key_signature)=

Direct key signature

A direct key signature serves as the preferred mechanism in OpenPGP v6 for defining {term}metadata for the entire {term}certificate<OpenPGP Certificate>, by associating it with the {term}primary key<OpenPGP Primary Key>.

(self_signature_binding_to_primary_user_id)=

Self-signature binding to primary User ID

In OpenPGP v4, another mechanism was often used for {term}metadata management: integrating global {term}certificate<OpenPGP Certificate> {term}metadata within a {term}User ID binding signature. This is specifically evident in the {term}binding signature of the 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<OpenPGP certificate>, it is crucial that {term}OpenPGP applications<OpenPGP Implementation> recognize and manage it.

(self-revocations)=

Revocation self-signatures: Invalidating certificate components

{term}Revocation self-signatures<Revocation Self-signature> represent an important class of {term}self-signatures<Self-signature>, used primarily to invalidate {term}components<Component> or retract prior {term}signature<OpenPGP Signature Packet> statements.

There are several types of {term}revocation signatures<Revocation Self-signature>, each serving a specific purpose:

• A key revocation signature ({term}type ID<Signature Type ID> 0x20) marks a {term}primary key<OpenPGP Primary Key> as {term}revoked<Revocation>.
• A subkey revocation signature ({term}type ID<Signature Type ID> 0x28) {term}invalidates<Validation> the {term}binding of a subkey<Subkey Binding Signature>.
• A certification revocation ({term}type ID<Signature Type ID> 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<OpenPGP Certificate> or individual {term}subkeys<OpenPGP Subkey> as unusable (e.g., when the {term}private key<Transferable Secret Key> has been compromised or replaced) or declaring {term}User IDs<User ID> as no longer {term}valid<Validation>.

{term}`OpenPGP certificates<OpenPGP Certificate>` act as append-only data structures in practice. Once elements of a {term}`certificate<OpenPGP Certificate>` are published, they cannot be removed from {term}`key servers<Key Server>` or third-party OpenPGP systems. {term}`Implementations<OpenPGP Implementation>` usually merge all available {term}`components<Component>` and {term}`signatures<OpenPGP Signature Packet>`.

{term}`Revocations<Revocation>` are used to mark {term}`components<Component>` or {term}`signatures<OpenPGP Signature Packet>` as {term}`invalid<Validation>`.

:class: warning

Research, under what circumstances revocations revoke individual signatures, and when they instead "unbind" components.

Note: {term}certification signatures<Certification> can be made irrevocable.

(hard_vs_soft_revocations)=

Hard vs soft revocations

{term}Revocation signatures<Revocation Self-signature> often include a Reason for Revocation subpacket, with a code specifying why the {term}revocation<Revocation Self-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<Revocation Self-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<Private Key Material>.

A {term}`revocation signature packet` lacking a {term}`Reason for Revocation subpacket` is interpreted as a {term}`hard revocation`.

(third_party_cert)=

Authentication and delegation in third-party signatures

{term}Third-party signatures<Third-party Signature> in OpenPGP primarily encode {term}authentication statements for {term}identities<Identity> and {term}delegate<Delegation> trust decisions. These {term}signatures<OpenPGP Signature Packet> can be manually inspected or processed as machine-readable artifacts by {term}OpenPGP software<OpenPGP Implementation>, which evaluates the {term}authenticity<Authentication> of {term}certificates<OpenPGP Certificate> based on user-specified {term}trust anchors<Trust Anchor>.

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<OpenPGP Certificate>. 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<OpenPGP Certificate> 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<OpenPGP Certificate>.

Other users may or may not decide to rely on Alice's statement to determine the {term}authenticity<Authentication> of Bob's {term}certificate<OpenPGP Certificate>.

(delegation)=

Trust signatures: delegating authentication

OpenPGP uses trust signature {term}subpackets<OpenPGP Signature Subpacket> to {term}delegate<Delegation> {term}authentication decisions, designating the recipient {term}certificate<OpenPGP Certificate> 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<Trusted Introducer>'s {term}certifications<Certification>.

{term}Trust signature {term}subpackets<OpenPGP Signature Subpacket> are applicable in {term}third-party signatures<Third-party Signature>, more specifically:

• {term}identity certification signatures<Identity Certification> ({term}type ID<Signature Type ID> 0x10 - 0x13)
• direct key signatures ({term}type ID<Signature Type ID> 0x1F)

(trust_depth_level)=

Trust depth/level

The "{term}trust depth" (or {term}level<Trust Depth>) 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<OpenPGP Certificate> 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<Trusted Introducer> 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<Initial Introducer> but also by other intermediaries whom the {term}primary introducer<Initial Introducer> designated as {term}trusted introducers<Trusted Introducer>.

This allows for a more extensive network of trusted {term}certifications<Certification>, enabling a broader and more interconnected {term}Web of Trust.

(trust_amounts)=

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<OpenPGP Implementation> in determining an aggregate amount of reliance, based on combined {term}certifications<Certification> from multiple {term}trusted introducers<Trusted Introducer>.

(limiting_delegation_scope)=

Limiting delegation scope

When using {term}trust signature {term}subpackets<OpenPGP Signature Subpacket>, a {term}delegation can be limited to {term}identities<Identity> that match a regular expression.

With this mechanism, for example, it is possible to {term}delegate<Delegation> {term}authentication decisions only for {term}User IDs<User ID> that match the email domain of an organization.

(wot)=

Web of Trust: Decentralized trust decisions

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, which refers to a group of {term}certificates<OpenPGP Certificate> that are robustly interconnected via third-party certifications<Third-party Identity Certification>.

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<OpenPGP Certificate> and {term}third-party signatures<Third-party Signature> available to them, with their {term}OpenPGP software<OpenPGP Implementation> applying the {term}Web of Trust mechanism to discern the reliability of each {term}certificate<OpenPGP Certificate> 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. See external resources in {numref}wot-resources.

Revoking third-party signatures

To reverse a previously issued {term}third-party signature, the {term}issuer can generate a certification revocation signature ({term}type ID<Signature Type ID> 0x30). The {term}revocation must be issued by the same {term}key<Component Key> that created the original {term}signature<OpenPGP Signature Packet> or, in deprecated practice, by a designated Revocation Key.

Advanced topics

Certification recipes

Different {term}signatures<OpenPGP Signature Packet> in OpenPGP serve various specific purposes. This section provides practical guidance on creating these {term}signatures<OpenPGP Signature Packet>, illustrating each with concrete examples.

(change_algorithm_preferences)=

Change algorithm preferences

To modify the preferred {term}symmetric<Symmetric Cryptography>, compression, {term}hash<Hash Function>, or {term}AEAD algorithms<Authenticated Encryption With Associated Data> for a {term}key<Transferable Secret Key>, the {term}key owner<Certificate Holder> needs to issue a {term}direct key signature ({term}type ID<Signature Type ID> 0x1F) on the {term}primary key<OpenPGP Primary Key>.

This {term}signature<OpenPGP Signature Packet> should have the following structure:

{term}Subpacket<OpenPGP Signature Subpacket>	Area	{term}Critical<Criticality Flag>	Mandatory	Notes
{term}Signature Creation Time<Signature Creation Time Subpacket>	{term}Hashed<Hashed Area>	True	True	Current time
{term}Issuer Fingerprint<Issuer Fingerprint Subpacket>	{term}Hashed<Hashed Area>	True or False	Strongly Recommended	The {term}primary key is the {term}issuer
{term}Key Flags<Key Flag>	{term}Hashed<Hashed Area>	True	False	Retain {term}key flags<Key Flag> from the previous {term}self-signature
{term}Features<Features Subpacket>	{term}Hashed<Hashed Area>	True	False	Retain {term}features<Features Subpacket> from the previous {term}self-signature
{term}Key Expiration Time<Key Expiration Time Subpacket>	{term}Hashed<Hashed Area>	True	False	Retain {term}expiration time from the previous {term}self-signature, if applicable
{term}Hash Algorithm Preferences<Preferred Hash Algorithms Subpacket>	{term}Hashed<Hashed Area>	False	False	New {term}preferences<Algorithm Preferences>
{term}Compression Algorithm Preferences<Preferred Compression Algorithms Subpacket>	{term}Hashed<Hashed Area>	False	False	New {term}preferences<Algorithm Preferences>
{term}Symmetric Algorithm Preferences<Preferred Symmetric Ciphers for v1 SEIPD Subpacket>	{term}Hashed<Hashed Area>	False	False	New {term}preferences<Algorithm Preferences>
{term}AEAD Algorithm Preferences<Preferred AEAD Ciphersuites Subpacket>	{term}Hashed<Hashed Area>	False	False	New {term}preferences<Algorithm Preferences>

Change expiration time

To adjust the {term}expiration time of an {term}OpenPGP certificate, a new {term}DirectKey<Direct Key Signature> {term}signature<OpenPGP Signature Packet> ({term}type ID<Signature Type ID> 0x1F) with a modified {term}Key Expiration Time subpacket must be issued. The structure of this {term}signature<OpenPGP Signature Packet> is identical to the one outlined in the previous section on changing {term}algorithm preferences.

Additionally, the {term}expiration time can be altered for individual {term}User IDs<User ID> (detailed below) or separate {term}subkeys<OpenPGP Subkey> (see {numref}bind_subkey).

Add User ID

To {term}bind<Binding> a {term}User ID to an {term}OpenPGP certificate a {term}certification signature<Certification> ({term}type ID<Signature Type ID> 0x10-0x13) is used which should have the following structure:

{term}Subpacket<OpenPGP Signature Subpacket>	Area	{term}Critical<Criticality Flag>	Mandatory	Notes
{term}Signature Creation Time<Signature Creation Time Subpacket>	{term}Hashed<Hashed Area>	True	True	Current time
{term}Issuer Fingerprint<Issuer Fingerprint Subpacket>	{term}Hashed<Hashed Area>	True or False	Strongly Recommended	The {term}primary key<OpenPGP Primary Key> is the {term}issuer
{term}Primary User ID<Primary User ID Subpacket>	{term}Hashed<Hashed Area>	True	False	Optional
{term}Signature Expiration Time<Signature Expiration Time Subpacket>	{term}Hashed<Hashed Area>	True	False	Optional

In addition to these {term}subpackets<OpenPGP Signature Subpacket>, {term}self-certifications<Self-certification> for {term}User IDs<User ID> can include others – such as {term}key flags<Key Flag>, {term}features<Features Subpacket>, and {term}algorithm preferences – as shown in the previous table. This enables the specification of unique capabilities and {term}preferences<Algorithm Preferences> for each {term}identity associated with the {term}certificate<OpenPGP Certificate>.

Remove or revoke a User ID

Since {term}OpenPGP certificates<OpenPGP certificate> are often distributed by the means of {term}key servers<Key Server>, new {term}signatures<OpenPGP Signature Packet> on a {term}certificate<OpenPGP Certificate> are often "merged" into existing copies of the {term}certificate<OpenPGP Certificate> locally by the recipient.

:class: warning

Link to the "Merging" section in chapter 4, once merged.

This integration process means it is practically impossible to directly remove {term}signatures<OpenPGP Signature Packet> or {term}User IDs<User ID> from a {term}certificate<OpenPGP Certificate>, as there is no way to communicate the intention of {term}packet<OpenPGP Signature Packet> deletion to the recipient.

To effectively mark a {term}User ID as invalid, the user can publish a copy of their {term}certificate<OpenPGP Certificate> with a {term}Certification Revocation signature<Certification Revocation Signature Packet> ({term}type ID<Signature Type ID> 0x30) attached to the invalidated {term}User ID. This {term}signature<OpenPGP Signature Packet> signals that the specified {term}User ID is no longer valid or associated with the {term}certificate holder.

The structure of a {term}Certification Revocation signature<Certification Revocation Signature Packet> is as follows:

{term}Subpacket<OpenPGP Signature Subpacket>	Area	{term}Critical<Criticality Flag>	Mandatory	Notes
{term}Signature Creation Time<Signature Creation Time Subpacket>	{term}Hashed<Hashed Area>	True	True	Current time
{term}Issuer Fingerprint<Issuer Fingerprint Subpacket>	{term}Hashed<Hashed Area>	True or False	Strongly Recommended	The {term}primary key<OpenPGP Primary Key> is the {term}issuer
{term}Reason for Revocation<Reason for Revocation Subpacket>	{term}Hashed<Hashed Area>	True	False	Determines {term}soft<Soft Revocation> or {term}hard revocation

For {term}User ID {term}revocations<Revocation>, the {term}Reason for Revocation<Reason for Revocation Subpacket> {term}subpacket<OpenPGP Signature Subpacket> is crucial. A value of 0 means no specific reason, leading to a {term}hard revocation, while 32 indicates the {term}User ID is no longer valid, resulting in a {term}soft revocation. Omitting the {term}reason subpacket<Reason For Revocation Subpacket> is also equivalent to a {term}hard revocation.

It is generally advisable to use reason code 32 for revoking {term}User IDs<User ID>.

(binding_subkeys)=

Add a subkey

As part of {term}life-cycle management, users may need to add a new {term}subkey<OpenPGP Subkey> to their {term}OpenPGP certificate, often for reasons such as upgrading to a {term}subkey<OpenPGP Subkey> with more advanced cryptographic algorithms. The process involves creating a specific {term}signature<OpenPGP Signature Packet> structure:

{term}Subpacket<OpenPGP Signature Subpacket>	Area	{term}Critical<Criticality Flag>	Mandatory	Notes
{term}Signature Creation Time<Signature Creation Time Subpacket>	{term}Hashed<Hashed Area>	True	True	Current time
{term}Issuer Fingerprint<Issuer Fingerprint Subpacket>	{term}Hashed<Hashed Area>	True or False	Strongly Recommended	The {term}primary key<OpenPGP Primary Key> is the {term}issuer
{term}Key Flags<Key Flag>	{term}Hashed<Hashed Area>	True	Strongly Recommended	Determine the usage of the {term}key<OpenPGP Subkey>
{term}Key Expiration Time<Key Expiration Time Subpacket>	{term}Hashed<Hashed Area>	True	False	Specifies the {term}expiration time of the {term}subkey<OpenPGP Subkey>
{term}Embedded Signature<Embedded Signature Subpacket>	{term}Hashed<Hashed Area>	True	If {term}Key Flags<Key Flag> contains {term}S<Signing Key Flag>	{term}Signing subkeys<OpenPGP Signing Subkey> require embedded {term}Primary Key Binding<Primary Key Binding Signature> {term}signature<OpenPGP Signature Packet>
{term}Hash Algorithm Preferences<Preferred Hash Algorithms Subpacket>	{term}Hashed<Hashed Area>	False	False	Per {term}key<Component Key> {term}preferences<Algorithm Preferences>
{term}Compression Algorithm Preferences<Preferred Compression Algorithms Subpacket>	{term}Hashed<Hashed Area>	False	False	Per {term}key<Component Key> {term}preferences<Algorithm Preferences>
{term}Symmetric Algorithm Preferences<Preferred Symmetric Ciphers for v1 SEIPD Subpacket>	{term}Hashed<Hashed Area>	False	False	Per {term}key<Component Key> {term}preferences<Algorithm Preferences>
{term}AEAD Algorithm Preferences<Preferred AEAD Ciphersuites Subpacket>	{term}Hashed<Hashed Area>	False	False	Per {term}key<Component Key> {term}preferences<Algorithm Preferences>

In addition to these {term}subpackets<OpenPGP Signature Subpacket>, users can specify {term}algorithm preferences for each {term}subkey<OpenPGP Subkey>, distinct from those set in the {term}certificate<OpenPGP Certificate>'s {term}Direct Key<Direct Key Signature> {term}signature<OpenPGP Signature Packet>.

Revoke a subkey

{term}Subkeys<OpenPGP subkey>, like {term}User IDs<User ID>, can be individually revoked in OpenPGP. This is done by issuing a {term}Subkey Revocation signature<Subkey Revocation Signature Packet> ({term}type ID<Signature Type ID> 0x28) using the {term}primary key<OpenPGP Primary Key>.

The structure of such a {term}signature<OpenPGP Signature Packet> is straightforward:

{term}Subpacket<OpenPGP Signature Subpacket>	Area	{term}Critical<Criticality Flag>	Mandatory	Notes
{term}Signature Creation Time<Signature Creation Time Subpacket>	{term}Hashed<Hashed Area>	True	True	Current time
{term}Issuer Fingerprint<Issuer Fingerprint Subpacket>	{term}Hashed<Hashed Area>	True or False	Strongly Recommended	The {term}primary key<OpenPGP Primary Key> is the {term}issuer
{term}Reason for Revocation<Reason For Revocation Subpacket>	{term}Hashed<Hashed Area>	True	False	Determines {term}soft<Soft Revocation> or {term}hard revocation

In {term}Subkey Revocation signatures<Subkey Revocation Signature Packet>, the reason for revocation {term}subpacket<OpenPGP Signature Subpacket> can only have values in the range of 0-3. The values 1 ({term}key<OpenPGP Subkey> superseded) and 3 ({term}key<OpenPGP Subkey> retired and no longer used) indicate {term}soft revocations<Soft Revocation>, whereas values 0 (no reason) and 2 ({term}key<OpenPGP Subkey> compromised) indicate {term}hard revocations<Hard Revocation>.

Note that a value of 32 is not applicable in these {term}signatures<OpenPGP Signature Packet>.

:class: warning

Research and explain hardness in the context of subkey revocations. What does a hard subkey revocation express concretely?

Revoke a certificate

Users may find themselves needing to revoke their entire {term}OpenPGP certificate, rendering it unusable. This could be for various reasons, such as migrating to a new {term}certificate<OpenPGP certificate> or in response to a compromise of the {term}certificate<OpenPGP certificate>'s {term}secret key material<Private Key Material>.

While a {term}soft-revoked<Soft Revocation> {term}certificate<OpenPGP Certificate> can be re-validated at a later time with a new {term}certification, a {term}hard revocation is permanent.

The recommended way to {term}revoke<Revocation> a {term}certificate<OpenPGP Certificate> is by issuing a {term}Key Revocation signature<Key Revocation Signature Packet> ({term}type ID<Signature Type ID> 0x20). Its structure is similar to that of a {term}Certification Revocation signature<Certification Revocation Signature Packet>.

{term}Subpacket<OpenPGP Signature Subpacket>	Area	{term}Critical<Criticality Flag>	Mandatory	Notes
{term}Signature Creation Time<Signature Creation Time Subpacket>	{term}Hashed<Hashed Area>	True	True	Current time
{term}Issuer Fingerprint<Issuer Fingerprint Subpacket>	{term}Hashed<Hashed Area>	True or False	Strongly Recommended	The {term}primary key<OpenPGP Primary Key> is the {term}issuer
{term}Reason for Revocation<Reason For Revocation Subpacket>	{term}Hashed<Hashed Area>	True	False	Determines {term}soft<Soft Revocation> or {term}hard revocation

For {term}Key Revocation signatures<Key Revocation Signature Packet>, the guidelines regarding the Reason for Revocation subpacket are the same as those for {term}Subkey Revocation signatures<Subkey Revocation Signature Packet>.

Common subpackets in OpenPGP signatures

In OpenPGP, certain {term}subpackets<OpenPGP Signature Subpacket> are universally expected across all types of {term}signatures<OpenPGP Signature Packet>, serving fundamental roles in the {term}signature<OpenPGP Signature Packet>'s structure, {term}verification and {term}validation:

• {term}Signature Creation Time<Signature Creation Time Subpacket>: This is a mandatory {term}subpacket<OpenPGP Signature Subpacket> in every {term}OpenPGP signature<OpenPGP Signature Packet>. It contains the timestamp of when the {term}signature<OpenPGP Signature Packet> was created. For security and integrity, this {term}subpacket<OpenPGP Signature Subpacket> must be located in the {term}hashed area of the {term}signature<OpenPGP Signature Packet> and is recommended to be marked as {term}critical<Criticality Flag>.

• {term}Issuer Fingerprint<Issuer Fingerprint Subpacket>: Essential for {term}signature<OpenPGP Signature Packet> {term}validation, this {term}subpacket<OpenPGP Signature Subpacket> identifies the {term}key<OpenPGP Primary Key> (or {term}subkey<OpenPGP Subkey>) that was used to create the {term}signature<OpenPGP Signature Packet>. OpenPGP v6 {term}signatures<OpenPGP Signature Packet> should include the {term}Issuer Fingerprint subpacket, containing the 32-byte {term}fingerprint<OpenPGP Fingerprint> of the {term}key<Component Key>.

The {term}`key<Component Key>` used as the {term}`issuer` in the {term}`signature<OpenPGP Signature Packet>` might be a {term}`subkey<OpenPGP Subkey>` of the {term}`certificate<OpenPGP Certificate>`.

These {term}subpackets<OpenPGP Signature Subpacket> can be placed in either the {term}hashed<Hashed Area> or {term}unhashed area due to its self-{term}authenticating<Authentication> nature. However, we recommend including them in the {term}signature<OpenPGP Signature Packet>'s {term}hashed area.

Managing subpacket conflicts and duplication

In {term}OpenPGP signatures<OpenPGP Signature Packet>, both the {term}hashed<Hashed Area> and {term}unhashed areas<Unhashed Area> are composed of lists of {term}subpackets<OpenPGP Signature Subpacket>. Inherently, this structure permits the duplication of the same {term}subpacket<OpenPGP Signature Subpacket>, which could lead to conflicts. To manage these potential conflicts, the following strategies are used:

• Precedence of {term}hashed area: {term}Subpackets<OpenPGP Signature Subpacket> within the {term}hashed area of a {term}signature<OpenPGP Signature Packet> take precedence over those in the {term}unhashed area. This hierarchy helps resolve conflicts when the same {term}subpacket<OpenPGP Signature Subpacket> appears in both areas.

• Handling conflicts within the same area: Conflicts can still arise within the same area, such as when two {term}subpackets<OpenPGP Signature Subpacket> have different {term}expiration times<Expiration Time>. In such cases, the OpenPGP specification advises that {term}implementations<OpenPGP Implementation> should favor the last occurrence of a conflicting {term}subpacket<OpenPGP Signature Subpacket> in the {term}hashed area.

In certain scenarios, having duplicate {term}subpackets<OpenPGP Signature Subpacket> with conflicting content is logical and even necessary. For example, consider a {term}signature<OpenPGP Signature Packet> created by a version 4 {term}issuer {term}key<Component Key>, which was upgraded from an older OpenPGP version (like v3). Since the {term}key ID calculation scheme changed from v3 to v4, the identifiers for the same {term}key<Component Key> would differ between these versions. Therefore, a v4 signature might contain two {term}issuer key ID subpackets<Issuer Fingerprint Subpacket>, each with different, yet correct values for v3 and v4 {term}keys<Component Key>, respectively. This allows for backward compatibility and ensures the {term}signature<OpenPGP Signature Packet> can be {term}validated<Validation> under both {term}key ID calculation schemes.