From 6700eddaba6ebb5254f59e6494511b833d650b8c Mon Sep 17 00:00:00 2001 From: Paul Schaub Date: Mon, 27 Nov 2023 20:25:05 +0100 Subject: [PATCH 01/21] There are different implementations of the WoT around, not all of them might use DK sigs as delegations afaik --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index ae264a6..be0b7fd 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -62,7 +62,7 @@ The meaning of an OpenPGP signature depends significantly on its issuer. Self-si In another instance: - *When issued as a 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 preferences and advertises features applicable to the entire certificate. -- *When issued by a third party*, especially when it carries a [trust signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-trust-signature) subpacket, a similar direct key signature delegates trust to the signed certificate. This designates the signed certificate as a trust root within the issuer's Web of Trust. +- *When issued by a third party*, especially when it carries a [trust signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-trust-signature) subpacket, a similar direct key signature delegates trust to the signed certificate. This may designate the signed certificate as a trust root within the issuer's Web of Trust. ## Self-signatures in certificate formation and management From 5d096959de1551533c9e3e71ad872393ed7a6c9e Mon Sep 17 00:00:00 2001 From: Paul Schaub Date: Mon, 27 Nov 2023 22:03:21 +0100 Subject: [PATCH 02/21] Some minor changes to chapter 8 --- book/source/08-signing_components.md | 77 ++++++++++++++++++---------- 1 file changed, 50 insertions(+), 27 deletions(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index be0b7fd..041ef20 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -40,7 +40,7 @@ No [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh- ### Third-party signatures -Third-party signatures are pivotal in OpenPGP for decentralized authentication, forming the basis of the Web of Trust. They encode authentication-related statements about certificates and linked identities, establishing trustworthiness and verification. +Third-party signatures are pivotal in OpenPGP for decentralized authentication, forming the basis of the Web of Trust. They encode authentication-related statements about certificates and linked identities, establishing trustworthiness in identity claims. Third-party signatures are used to make specific statements: @@ -49,15 +49,15 @@ Third-party signatures are used to make specific statements: - revoking, and thus invalidating, prior third-party signature statements ```{note} -The **certify others** [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) (`0x01`) is required to issue third-party signatures. Only the certificate's primary can hold this key flag. +The **certify others** [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) (`0x01`) is required to issue third-party signatures. Typically, only the certificate's primary can hold this key flag. ``` ### Distinct functions of self-signatures and third-party signatures -The meaning of an OpenPGP signature depends significantly on its issuer. Self-signatures and third-party signatures, even when of the same type, serve distinct functions. For example: +The meaning of an OpenPGP signature depends significantly on its issuer. Self-signatures and third-party signatures, 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: - Certifying self-signatures (type IDs `0x10` - `0x13`) bind a User ID to a certificate. -- Third-party signatures of the same type IDs endorse the authenticity of a User ID. +- Third-party signatures of the same type IDs endorse the authenticity of a User ID claimed by the holder of a certificate. In another instance: @@ -70,7 +70,7 @@ Self-signatures play a crucial role in forming and managing the structure of Ope Internally, an OpenPGP certificate is essentially a series of packets strung sequentially. When a certificate is stored in a file format known as a [transferable public key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-transferable-public-keys), packets can be easily added or removed. -To safeguard against unauthorized additions, OpenPGP uses cryptographic signatures. These validate that any additions, such as subkeys or [identity components](identity_components), were made by the owner of the OpenPGP certificate using its primary key. While anyone can still store unrelated elements to a certificate dataset, OpenPGP implementations will reject them if they lack a valid cryptographic connection with the certificate. +To safeguard against unauthorized additions and alterations of components, OpenPGP uses cryptographic signatures. These validate that any additions, such as added subkeys or [identity components](identity_components), were made by the owner of the OpenPGP certificate using its primary key. While anyone can still store unrelated elements to a certificate dataset, OpenPGP implementations will reject them if they lack a valid cryptographic connection with the certificate. ```{note} Conversely, omissions of packets by third parties can easily occur when handling an OpenPGP certificate dataset. This could pose a challenge, for example, when an attacker deliberately omits revocation packets. Without access to an alternative, complete certificate source, recipients might not detect these omissions. @@ -112,7 +112,9 @@ Binding subkeys that possess the *signing* key flag to a certificate represents That is, to bind a signing-capable subkey to a primary key, it is insufficient that the "primary key wants to be associated with the subkey." The subkey must explicitly signal that it "wants to be associated with the 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) signing subkey. To prevent such scenarios, where an attacker might wrongfully "adopt" a victim's signing subkey, a dual-layer of signatures is used: +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) signing subkey. +As a consequence, Alice could claim to have issued signatures which were in fact issued by Bob. +To prevent such scenarios, where an attacker might wrongfully "adopt" a victim's signing subkey, a dual-layer of signatures is used: - the [subkey binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-subkey-binding) (type ID `0x18`), which is issued by the certificate's primary key - the [primary key binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-primary-binding) (type ID `0x19`), created by the subkey itself. This is informally known as an embedded "back signature," because the subkey's signature points back to the primary key. @@ -131,11 +133,11 @@ The back signature signifies the mutuality of the subkey's association with the Self-signatures also play a vital role in binding identity components, such as User IDs or User Attributes, to an OpenPGP certificate. -Take for instance, the User ID `Alice Adams `. To link this User ID to her OpenPGP certificate (`AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3`), Alice would use a cryptographic signature. +To bind the User ID `Alice Adams ` to her OpenPGP certificate (`AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3`), Alice would use a certification signature. -There are four types of *certifying self-signature*. The most commonly used type for binding User IDs is the [positive certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-positive-cert) (type ID `0x13`). Alternatively, types `0x10`, `0x11` or `0x12` might be used. This binding signature must be issued by the primary key. +There are four types of *certifying self-signature*. According to the specification, the most commonly used type for binding User IDs is the [generic certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-generic-certification-of-a-) (type ID `0x10`). Alternatively, types `0x11`, `0x12` or `0x13` might be used. This binding signature must be issued by the primary key. -The certifying self-signature packet – calculated over the primary key, User ID, and metadata of the signature packet – is then added to the certificate, directly following the User ID packet. +The certifying self-signature packet – calculated over the primary key, User ID, and metadata of the signature packet – is added to the certificate, directly following the User ID packet. ```{figure} diag/user_id_certification.png :name: fig-user-id-certification @@ -147,9 +149,9 @@ Linking a User ID to an OpenPGP certificate (primary-metadata)= ### Adding metadata to the primary key/certificate -The signatures that bind subkeys and identity components to a certificate serve dual purposes: linking components to the certificate and adding metadata to components. +The signatures that bind subkeys and identity components to a certificate serve dual purposes: linking components to the certificate and adding scoped metadata to components. -Unlike these components, the primary key of a certificate doesn't require a linking signature since it serves as the central anchor of the certificate. However, associating metadata with the primary key is still essential, as it generally applies to the entire certificate. +Unlike subkeys and User IDs, the primary key of a certificate doesn't require a linking signature since it serves as the central anchor of the certificate. Metadata can be added to the primary key via two mechanisms: @@ -160,6 +162,7 @@ The types of metadata typically associated with the primary key through these me - key expiration - key flags +- features - algorithm preference signaling (direct_key_signature)= @@ -167,7 +170,7 @@ The types of metadata typically associated with the primary key through these me 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 a key mechanism for storing information about the primary key and the entire certificate. -In OpenPGP v6, a direct key signature is 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, a direct key signature is the [preferred mechanism](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.2.3.10-9) for storing algorithm preferences and features. #### Self-signature binding to primary User ID @@ -181,8 +184,8 @@ Revocation self-signatures represent an important class of self-signatures, used There are several types of revocation signatures, 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) (type ID `0x20`) marks a primary key as revoked. -- A [**subkey revocation signature**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-subkey-revocation-signature) (type ID `0x28`) revokes a prior subkey binding signature. -- A [**certification revocation**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-certification-revocation-si) (type ID `0x30`) revokes a certification signature. +- A [**subkey revocation signature**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-subkey-revocation-signature) (type ID `0x28`) invalidates the binding of a subkey. +- A [**certification revocation**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-certification-revocation-si) (type ID `0x30`) invalidates the binding of a User ID or User Attribute. Common scenarios for using revocations include marking certificates or individual subkeys as unusable (e.g., when the private key has been compromised or replaced) or declaring User IDs as no longer valid. @@ -192,11 +195,17 @@ OpenPGP certificates act as append-only data structures in practice. Once elemen Revocations are used to mark components or signatures as invalid. ``` +```{admonition} TODO +:class: warning + +Research, under what circumstances revocations revoke individual signatures, and when they instead "unbind" components. +``` + Note: certification signatures [can be made irrevocable](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-revocable). #### Hard vs soft revocations -Revocation signatures 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 revocation was issued. This code determines whether the revocation is considered *soft* or *hard*. +Revocation signatures 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 revocation was issued. This code determines whether the revocation is considered *soft* or *hard*. - **Soft revocation**: This is typically used for graceful or planned invalidation of components, such as retiring or updating components. It invalidates the component from the revocation signature's creation time, but earlier uses remain valid. Soft revocations can be reversed with a new self-signature. - **Hard revocation**: This irrevocably invalidates the component, affecting all past and future uses. It is typically used to signal compromise of secret key material. @@ -212,17 +221,17 @@ Third-party signatures in OpenPGP primarily encode authentication statements for ### Certifying identity components -When a signer issues a certifying signature on an identity, it indicates a verified link between the identity and the certificate. That is, the signer vouches for the connection. +When a signer issues a certifying signature on an identity, it indicates a verified link between the identity and the certificate. That is, the signer vouches for the identity claim. For example, Alice can vouch that Bob's User ID `Bob Baker ` is legitimately linked with his certificate `BB28 9FB7 A68D BFA8 C384 CCCD E205 8E02 D9C6 CD2F 3C7C 56AE 7FB5 3D97 1170 BA83`, by creating a certification signature. Bob can then distribute Alice's certifying signature as part of his certificate. -Other users may or may not decide to rely on Alice's statement. +Other users may or may not decide to rely on Alice's statement when questioning the authenticity of Bob's certificate. ### Trust signatures: delegating authentication OpenPGP uses [*trust signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#trust-signature-subpacket) subpackets to delegate authentication decisions, designating the recipient certificate as a "trusted introducer" (or a trust root) for the user. This includes specifying trust depth (or level) for transitive delegations and quantifying trust with numerical values, indicating the extent of reliance on the introducer's certifications. -Trust signature subpackets are applicable in: +Trust signature subpackets are applicable in *third-party* signatures, more specifically: - identity certification signatures (type ID `0x10` - `0x13`) - [direct key signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) (type ID `0x1F`) @@ -233,7 +242,7 @@ The "trust depth" (or level) in OpenPGP signifies the extent of transitive deleg A trust depth of 1 means relying on certifications made directly by the trusted introducer. The user's OpenPGP software will accept certifications made directly by the introducer for authenticating identities. -However, when the trust depth is set higher, it implies a chain of delegation extending beyond the initial introducer. The user's software will recognize and accept certifications made not only by the primary introducer but also by other intermediaries whom the primary introducer designated as trusted introducers. +However, when the trust depth is set higher, it implies a chain of delegation may extend beyond the initial introducer. The user's software will recognize and accept certifications made not only by the primary introducer but also by other intermediaries whom the primary introducer designated as trusted introducers. This allows for a more extensive network of trusted certifications, enabling a broader and more interconnected Web of Trust. @@ -288,7 +297,7 @@ The OpenPGP RFC doesn't specify exactly how Web of Trust calculations are perfor ### Revoking third-party signatures -To reverse a previously issued third-party signature, the issuer can generate a [*certification revocation signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-certification-revocation-si) (type ID `0x30`). The revocation must be issued by the same key that created the original signature or, in deprecated practice, by a designated Revocation Key. +To reverse a previously issued third-party signature, the issuer can generate a [*certification revocation signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-certification-revocation-si) (type ID `0x30`). The revocation must be issued by the same key that created the original signature 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). ## Advanced topics @@ -316,13 +325,13 @@ This signature should have the following structure: #### Change expiration time -To adjust the expiration time of an OpenPGP certificate, issue a new *DirectKey* signature (type `0x1F`) with a modified Key Expiration Time subpacket. The structure of this signature is identical to the one outlined in the previous section on changing algorithm preferences. +To adjust the expiration time of an OpenPGP certificate, a new *DirectKey* signature (type `0x1F`) with a modified Key Expiration Time subpacket must be issued. The structure of this signature is identical to the one outlined in the previous section on changing algorithm preferences. Additionally, the expiration date can be altered for individual User IDs (detailed below) or separate subkeys (see {numref}`bind_subkey`). #### Add User ID -To bind a User ID to an OpenPGP certificate, the signature should have the following structure: +To bind a User ID to an OpenPGP certificate a certification signature (type `0x10`-`0x13`) is used which should have the following structure: | Subpacket | Area | Critical | Mandatory | Notes | |-------------------------|--------|----------------|-------------------|-------------------------------------------------| @@ -335,7 +344,15 @@ In addition to these subpackets, self-certifications for User IDs can include ot #### Remove or revoke a User ID -Since OpenPGP certificates are often distributed by the means of key servers, new signatures on a certificate are often "merged" into existing copies of the certificate locally by the recipient. This integration process means it is practically impossible to directly remove signatures or User IDs from a certificate, as there is no way to communicate the intention of packet deletion to the recipient. +Since OpenPGP certificates are often distributed by the means of key servers, new signatures on a certificate are often "merged" into existing copies of the certificate locally by the recipient. + +```{admonition} TODO +:class: warning + +Link to the "Merging" section in chapter 4, once merged. +``` + +This integration process means it is practically impossible to directly remove signatures or User IDs from a certificate, as there is no way to communicate the intention of packet deletion to the recipient. To effectively mark a User ID as invalid, the user can publish a copy of their certificate with a *CertificationRevocation* signature (type `0x30`) attached to the invalidated User ID. This signature signals that the specified User ID is no longer valid or associated with the certificate holder. @@ -354,7 +371,7 @@ It is generally advisable to use reason code `32` for revoking User IDs. (binding_subkeys)= #### Add a subkey -Users may need to add a new subkey to their OpenPGP certificate, often for reasons such as upgrading to a subkey with more advanced cryptographic algorithms. The process involves creating a specific signature structure: +As part of lifecycle management, the user may need to add a new subkey to their OpenPGP certificate, often for reasons such as upgrading to a subkey with more advanced cryptographic algorithms. The process involves creating a specific signature structure: | Subpacket | Area | Critical | Mandatory | Notes | |-------------------------------|--------|----------------|-------------------|-----------------------------------------------------| @@ -388,6 +405,12 @@ In `SubkeyRevocation` signatures, the [reason for revocation](https://www.ietf.o Note that a value of `32` is not applicable in these signatures. +```{admonition} TODO +: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 OpenPGP certificate, rendering it unusable. This could be for various reasons, such as migrating to a new certificate or in response to a compromise of the certificate's secret key material. @@ -410,7 +433,7 @@ In OpenPGP, certain subpackets are universally expected across all types of sign * **Signature Creation Time**: This is a mandatory subpacket in every OpenPGP signature. It contains the timestamp of when the signature was created. For security and integrity, this subpacket must be located in the hashed area of the signature and is recommended to be marked as critical. -* **Issuer Fingerprint**: Essential for signature verification, this subpacket identifies the key (or subkey) used to create the signature. OpenPGP v6 signatures should include the Issuer Fingerprint subpacket, containing the 32-byte fingerprint of the key. +* **Issuer Fingerprint**: Essential for signature verification, this subpacket identifies the key (or subkey) that was used to create the signature. OpenPGP v6 signatures should include the Issuer Fingerprint subpacket, containing the 32-byte fingerprint of the key. ```{note} The key used as the issuer in the signature might be a subkey of the certificate. @@ -420,10 +443,10 @@ This subpacket can be placed in either the hashed or unhashed area due to its se ### Managing subpacket conflicts and duplication -In OpenPGP signatures, both the hashed and unhashed areas are composed of lists of subpackets. Inherently, this structure permits the duplication of the same subpacket, which could lead to conflicts. To manage these potential conflicts: +In OpenPGP signatures, both the hashed and unhashed areas are composed of lists of subpackets. Inherently, this structure permits the duplication of the same subpacket, which could lead to conflicts. To manage these potential conflicts, the following strategies are used: - **Precedence of hashed area**: Subpackets within the hashed area of a signature take precedence over those in the unhashed area. This hierarchy helps resolve conflicts when the same subpacket appears in both areas. -- **Handling conflicts within the same area**: Conflicts can still arise within the same area, such as when two subpackets have different expiration dates. In such cases, the [OpenPGP specification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-notes-on-subpackets) advises that implementations should favor the last occurrence of a conflicting subpacket in the hashed area. +- **Handling conflicts within the same area**: Conflicts can still arise within the same area, such as when two subpackets have different expiration dates. In such cases, the [OpenPGP specification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-notes-on-subpackets) advises that implementations should favor the last occurrence of a conflicting subpacket in the hashed area. In certain scenarios, having duplicate subpackets with conflicting content is logical and even necessary. For example, consider a signature created by a version 4 issuer key, which was upgraded from an older OpenPGP version (like v3). Since the key ID calculation scheme changed from v3 to v4, the identifiers for the same key would differ between these versions. Therefore, a v4 signature might contain two issuer key ID subpackets, each with different, yet correct values for v3 and v4 keys, respectively. This allows for backward compatibility and ensures the signature can be validated under both key ID calculation schemes. \ No newline at end of file From e187175d6532eb1776615e408102d57745cae0f7 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 19:36:51 +0100 Subject: [PATCH 03/21] minor edits --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index 041ef20..adc1f4f 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -40,7 +40,7 @@ No [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh- ### Third-party signatures -Third-party signatures are pivotal in OpenPGP for decentralized authentication, forming the basis of the Web of Trust. They encode authentication-related statements about certificates and linked identities, establishing trustworthiness in identity claims. +Third-party signatures are pivotal in OpenPGP for decentralized authentication, forming the basis of the Web of Trust. They encode authentication-related statements about certificates and linked identities, establishing trustworthiness of identity claims. Third-party signatures are used to make specific statements: From e59e70939ce8582ddd94126a961aea255761d75f Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 19:37:06 +0100 Subject: [PATCH 04/21] clarify certification key flag limitation --- book/source/08-signing_components.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index adc1f4f..b370273 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -49,9 +49,11 @@ Third-party signatures are used to make specific statements: - revoking, and thus invalidating, prior third-party signature statements ```{note} -The **certify others** [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) (`0x01`) is required to issue third-party signatures. Typically, only the certificate's primary can hold this key flag. +The **certify others** [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) (`0x01`) is required to issue third-party signatures. By convention[^primary-certification], only the certificate's primary can hold this key flag. ``` +[^primary-certification]: Implementations currently assume that only the primary key may hold the "certify others" key flag. However, the RFC doesn't clearly specify this limitation. + ### Distinct functions of self-signatures and third-party signatures The meaning of an OpenPGP signature depends significantly on its issuer. Self-signatures and third-party signatures, 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: From 8719b9deb2bb3b3a5ebb75489c54df3c45259f1c Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 19:40:52 +0100 Subject: [PATCH 05/21] this addition seems mostly distracting to me? --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index b370273..da0d4e4 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -59,7 +59,7 @@ The **certify others** [key flag](https://www.ietf.org/archive/id/draft-ietf-ope The meaning of an OpenPGP signature depends significantly on its issuer. Self-signatures and third-party signatures, 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: - Certifying self-signatures (type IDs `0x10` - `0x13`) bind a User ID to a certificate. -- Third-party signatures of the same type IDs endorse the authenticity of a User ID claimed by the holder of a certificate. +- Third-party signatures of the same type IDs endorse the authenticity of a User ID. In another instance: From 46f3ee92f596d9e28f4b5b7a02c5af196811e7dd Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 19:53:44 +0100 Subject: [PATCH 06/21] further clarify --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index da0d4e4..4a76589 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -72,7 +72,7 @@ Self-signatures play a crucial role in forming and managing the structure of Ope Internally, an OpenPGP certificate is essentially a series of packets strung sequentially. When a certificate is stored in a file format known as a [transferable public key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-transferable-public-keys), packets can be easily added or removed. -To safeguard against unauthorized additions and alterations of components, OpenPGP uses cryptographic signatures. These validate that any additions, such as added subkeys or [identity components](identity_components), were made by the owner of the OpenPGP certificate using its primary key. While anyone can still store unrelated elements to a certificate dataset, OpenPGP implementations will reject them if they lack a valid cryptographic connection with the certificate. +To safeguard against unauthorized addition or alteration of components, OpenPGP uses cryptographic signatures. These validate that all components, such as subkeys or [identity components](identity_components), were linked to the OpenPGP certificate by its owner, using the primary key. While anyone can still store unrelated elements to a certificate dataset, OpenPGP implementations will reject them if they lack a valid cryptographic connection with the certificate. ```{note} Conversely, omissions of packets by third parties can easily occur when handling an OpenPGP certificate dataset. This could pose a challenge, for example, when an attacker deliberately omits revocation packets. Without access to an alternative, complete certificate source, recipients might not detect these omissions. From 3235ad49d4c6dade229b90a0d62a784201adedbb Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 20:06:24 +0100 Subject: [PATCH 07/21] i think the rfc says that generic certifications are commonly used for third party certifications, while this section is about self-signatures --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index 4a76589..22187f7 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -137,7 +137,7 @@ Self-signatures also play a vital role in binding identity components, such as U To bind the User ID `Alice Adams ` to her OpenPGP certificate (`AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3`), Alice would use a certification signature. -There are four types of *certifying self-signature*. According to the specification, the most commonly used type for binding User IDs is the [generic certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-generic-certification-of-a-) (type ID `0x10`). Alternatively, types `0x11`, `0x12` or `0x13` might be used. This binding signature must be issued by the primary key. +There are four types of *certifying self-signature*. The most commonly used type for binding User IDs is the [positive certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-positive-cert) (type ID `0x13`). Alternatively, types `0x10`, `0x11` or `0x12` might be used. This binding signature must be issued by the primary key. The certifying self-signature packet – calculated over the primary key, User ID, and metadata of the signature packet – is added to the certificate, directly following the User ID packet. From 71df26b237b524c55c58da3282a46dbc81262b23 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 20:14:55 +0100 Subject: [PATCH 08/21] I feel that this addition is more confusing than helpful, here? (We're not introducing the term in this meaning, anywhere, as far as i can tell) --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index 22187f7..a27dafe 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -151,7 +151,7 @@ Linking a User ID to an OpenPGP certificate (primary-metadata)= ### Adding metadata to the primary key/certificate -The signatures that bind subkeys and identity components to a certificate serve dual purposes: linking components to the certificate and adding scoped metadata to components. +The signatures that bind subkeys and identity components to a certificate serve dual purposes: linking components to the certificate and adding metadata to components. Unlike subkeys and User IDs, the primary key of a certificate doesn't require a linking signature since it serves as the central anchor of the certificate. From ac61a0ca558d86a53f5feca3bcbe81e5cd0f94e1 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 20:16:09 +0100 Subject: [PATCH 09/21] generalize to include user attributes --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index a27dafe..9972bb4 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -153,7 +153,7 @@ Linking a User ID to an OpenPGP certificate The signatures that bind subkeys and identity components to a certificate serve dual purposes: linking components to the certificate and adding metadata to components. -Unlike subkeys and User IDs, the primary key of a certificate doesn't require a linking signature since it serves as the central anchor of the certificate. +Unlike subkeys and identities, the primary key of a certificate doesn't require a linking signature since it serves as the central anchor of the certificate. Metadata can be added to the primary key via two mechanisms: From 3d82292858d626aa9845331fb5c7b6132348b991 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 20:19:34 +0100 Subject: [PATCH 10/21] this seems helpful and non-obvious to me? --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index 9972bb4..c7b6a49 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -153,7 +153,7 @@ Linking a User ID to an OpenPGP certificate The signatures that bind subkeys and identity components to a certificate serve dual purposes: linking components to the certificate and adding metadata to components. -Unlike subkeys and identities, the primary key of a certificate doesn't require a linking signature since it serves as the central anchor of the certificate. +Unlike subkeys and identities, the primary key of a certificate doesn't require a linking signature since it serves as the central anchor of the certificate. However, associating metadata with the primary key is still essential, as it generally applies to the entire certificate. Metadata can be added to the primary key via two mechanisms: From dda95bdc153641823346d94035010ef32215b78a Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 20:27:57 +0100 Subject: [PATCH 11/21] minor edit --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index c7b6a49..15874a2 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -227,7 +227,7 @@ When a signer issues a certifying signature on an identity, it indicates a verif For example, Alice can vouch that Bob's User ID `Bob Baker ` is legitimately linked with his certificate `BB28 9FB7 A68D BFA8 C384 CCCD E205 8E02 D9C6 CD2F 3C7C 56AE 7FB5 3D97 1170 BA83`, by creating a certification signature. Bob can then distribute Alice's certifying signature as part of his certificate. -Other users may or may not decide to rely on Alice's statement when questioning the authenticity of Bob's certificate. +Other users may or may not decide to rely on Alice's statement to determine the authenticity of Bob's certificate. ### Trust signatures: delegating authentication From e3c76587e312c9bab0f7d2576890639a1692693d Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 20:38:17 +0100 Subject: [PATCH 12/21] revert to the original plural --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index 15874a2..9b2e5d6 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -373,7 +373,7 @@ It is generally advisable to use reason code `32` for revoking User IDs. (binding_subkeys)= #### Add a subkey -As part of lifecycle management, the user may need to add a new subkey to their OpenPGP certificate, often for reasons such as upgrading to a subkey with more advanced cryptographic algorithms. The process involves creating a specific signature structure: +As part of lifecycle management, users may need to add a new subkey to their OpenPGP certificate, often for reasons such as upgrading to a subkey with more advanced cryptographic algorithms. The process involves creating a specific signature structure: | Subpacket | Area | Critical | Mandatory | Notes | |-------------------------------|--------|----------------|-------------------|-----------------------------------------------------| From 326f1541cb7d730f53289073588ba97ee4debf20 Mon Sep 17 00:00:00 2001 From: Paul Schaub Date: Tue, 28 Nov 2023 22:11:30 +0100 Subject: [PATCH 13/21] missing 'key' --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index 9b2e5d6..c1fe686 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -49,7 +49,7 @@ Third-party signatures are used to make specific statements: - revoking, and thus invalidating, prior third-party signature statements ```{note} -The **certify others** [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) (`0x01`) is required to issue third-party signatures. By convention[^primary-certification], only the certificate's primary can hold this key flag. +The **certify others** [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) (`0x01`) is required to issue third-party signatures. By convention[^primary-certification], only the certificate's primary key can hold this key flag. ``` [^primary-certification]: Implementations currently assume that only the primary key may hold the "certify others" key flag. However, the RFC doesn't clearly specify this limitation. From d0b4502a4b578a35a9da45d9a49dfcfe2ef6e49f Mon Sep 17 00:00:00 2001 From: Paul Schaub Date: Tue, 28 Nov 2023 22:13:20 +0100 Subject: [PATCH 14/21] MOST implementations assume only primary-key Certification capable --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index c1fe686..20c41b4 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -52,7 +52,7 @@ Third-party signatures are used to make specific statements: The **certify others** [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) (`0x01`) is required to issue third-party signatures. By convention[^primary-certification], only the certificate's primary key can hold this key flag. ``` -[^primary-certification]: Implementations currently assume that only the primary key may hold the "certify others" key flag. However, the RFC doesn't clearly specify this limitation. +[^primary-certification]: Most implementations currently assume that only the primary key may hold the "certify others" key flag. However, the RFC doesn't clearly specify this limitation. ### Distinct functions of self-signatures and third-party signatures From 7e339903fc16764eacdb5c4aee5cc6410bde353c Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Thu, 30 Nov 2023 16:54:25 +0100 Subject: [PATCH 15/21] Attempt to address https://codeberg.org/openpgp/notes/pulls/152/files#issuecomment-1357973 --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index 20c41b4..d705b39 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -59,7 +59,7 @@ The **certify others** [key flag](https://www.ietf.org/archive/id/draft-ietf-ope The meaning of an OpenPGP signature depends significantly on its issuer. Self-signatures and third-party signatures, 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: - Certifying self-signatures (type IDs `0x10` - `0x13`) bind a User ID to a certificate. -- Third-party signatures of the same type IDs endorse the authenticity of a User ID. +- Third-party signatures of the same type IDs endorse the authenticity of a User ID on another user's certificate. In another instance: From e496ee28e7d162ec7b85531a06d43b5970078de6 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Thu, 30 Nov 2023 16:55:50 +0100 Subject: [PATCH 16/21] Attempt to solve https://codeberg.org/openpgp/notes/pulls/152/files#issuecomment-1357978 --- book/source/08-signing_components.md | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index d705b39..9cdb2a4 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -149,34 +149,36 @@ Linking a User ID to an OpenPGP certificate ``` (primary-metadata)= -### Adding metadata to the primary key/certificate +### Adding global metadata to a certificate The signatures that bind subkeys and identity components to a certificate serve dual purposes: linking components to the certificate and adding metadata to components. -Unlike subkeys and identities, the primary key of a certificate doesn't require a linking signature since it serves as the central anchor of the certificate. However, associating metadata with the primary key is still essential, as it generally applies to the entire certificate. +Adding metadata that applies to the entire certificate is also essential, but doesn't require the function of binding any component to the certificate. Instead, for this use case, the signature mechanism is used just to associate metadata globally with the certificate. -Metadata can be added to the primary key via two mechanisms: +Two types of signature can be used to perform this function, for more details see below: - direct key signature on the primary key - *primary User ID* binding signature -The types of metadata typically associated with the primary key through these methods include: +The types of metadata typically associated with the certificate through these methods include: - key expiration -- key flags +- key flags (capabilities) - features - algorithm preference signaling (direct_key_signature)= #### Direct key signature -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 a key mechanism for storing information about the primary key and the entire certificate. - -In OpenPGP v6, a direct key signature is the [preferred mechanism](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.2.3.10-9) for storing algorithm preferences and features. +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 metadata for the entire certificate, by associating it with the primary key. #### Self-signature binding to primary User ID -In an OpenPGP certificate, one User ID serves as the [*primary* User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-primary-user-id). The metadata in the binding self-signature on this User ID applies to the certificate's primary key. +In OpenPGP v4, another mechanism was often used for this purpose: Piggybacking the global certificate metadata into a User ID binding signature. Specifically, the 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 OpenPGP certificate. + +When using this mechanism, the primary User ID binding signature contains a mix metadata: some that applies just to that particular User ID, and some that applies to the certificate, globally. + +Many existing OpenPGP certificates are using this mechanism, so OpenPGP applications need to be able to handle it. (self-revocations)= ### Revocation self-signatures: Invalidating certificate components From 16d444207395244096a8eed435d310d2cf7b97fd Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Mon, 4 Dec 2023 11:19:41 +0000 Subject: [PATCH 17/21] ed ch8 feedback commit e59e70939c --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index 9cdb2a4..8015b72 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -52,7 +52,7 @@ Third-party signatures are used to make specific statements: The **certify others** [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) (`0x01`) is required to issue third-party signatures. By convention[^primary-certification], only the certificate's primary key can hold this key flag. ``` -[^primary-certification]: Most implementations currently assume that only the primary key may hold the "certify others" key flag. However, the RFC doesn't clearly specify this limitation. +[^primary-certification]: Most current implementations assume that only the primary key may hold the *certify others* key flag, although this is not specified in the RFC. ### Distinct functions of self-signatures and third-party signatures From 6bc0ddddd9e82c8ba0de1fa55f5ce7b100e28421 Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Mon, 4 Dec 2023 11:31:35 +0000 Subject: [PATCH 18/21] remove s to clarify the or choice --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index 8015b72..8326633 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -137,7 +137,7 @@ Self-signatures also play a vital role in binding identity components, such as U To bind the User ID `Alice Adams ` to her OpenPGP certificate (`AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3`), Alice would use a certification signature. -There are four types of *certifying self-signature*. The most commonly used type for binding User IDs is the [positive certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-positive-cert) (type ID `0x13`). Alternatively, types `0x10`, `0x11` or `0x12` might be used. This binding signature must be issued by the primary key. +There are four types of *certifying self-signature*. The most commonly used type for binding User IDs is the [positive certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-positive-cert) (type ID `0x13`). Alternatively, type `0x10`, `0x11`, or `0x12` might be used. This binding signature must be issued by the primary key. The certifying self-signature packet – calculated over the primary key, User ID, and metadata of the signature packet – is added to the certificate, directly following the User ID packet. From a20aaba4d36cf80b7c4f058d5460e8803c71175e Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Mon, 4 Dec 2023 11:49:19 +0000 Subject: [PATCH 19/21] edits to commit 7e339903fc --- book/source/08-signing_components.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index 8326633..d1fab66 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -72,7 +72,7 @@ Self-signatures play a crucial role in forming and managing the structure of Ope Internally, an OpenPGP certificate is essentially a series of packets strung sequentially. When a certificate is stored in a file format known as a [transferable public key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-transferable-public-keys), packets can be easily added or removed. -To safeguard against unauthorized addition or alteration of components, OpenPGP uses cryptographic signatures. These validate that all components, such as subkeys or [identity components](identity_components), were linked to the OpenPGP certificate by its owner, using the primary key. While anyone can still store unrelated elements to a certificate dataset, OpenPGP implementations will reject them if they lack a valid cryptographic connection with the certificate. +To safeguard against unauthorized additions or alterations of components, OpenPGP uses cryptographic signatures. These validate that all components, such as subkeys or [identity components](identity_components), were linked to the OpenPGP certificate by its owner, using the primary key. While anyone can still store unrelated elements to a certificate dataset, OpenPGP implementations will reject them if they lack a valid cryptographic connection with the certificate. ```{note} Conversely, omissions of packets by third parties can easily occur when handling an OpenPGP certificate dataset. This could pose a challenge, for example, when an attacker deliberately omits revocation packets. Without access to an alternative, complete certificate source, recipients might not detect these omissions. @@ -115,7 +115,7 @@ Binding subkeys that possess the *signing* key flag to a certificate represents That is, to bind a signing-capable subkey to a primary key, it is insufficient that the "primary key wants to be associated with the subkey." The subkey must explicitly signal that it "wants to be associated with the 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) signing subkey. -As a consequence, Alice could claim to have issued signatures which were in fact issued by Bob. +Alice could thus claim to have issued signatures which were actually issued by Bob. To prevent such scenarios, where an attacker might wrongfully "adopt" a victim's signing subkey, a dual-layer of signatures is used: - the [subkey binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-subkey-binding) (type ID `0x18`), which is issued by the certificate's primary key From 34954ef996d612b316cd99210f1bac966f5e523f Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Mon, 4 Dec 2023 12:57:44 +0000 Subject: [PATCH 20/21] edit to commit e496ee28e7 --- book/source/08-signing_components.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index d1fab66..d4d1475 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -153,9 +153,9 @@ Linking a User ID to an OpenPGP certificate The signatures that bind subkeys and identity components to a certificate serve dual purposes: linking components to the certificate and adding metadata to components. -Adding metadata that applies to the entire certificate is also essential, but doesn't require the function of binding any component to the certificate. Instead, for this use case, the signature mechanism is used just to associate metadata globally with the certificate. +While it is essential to add metadata that pertains to the entire certificate, this does not require binding any component to the certificate. In this case, the signature mechanism is used just to associate metadata globally with the certificate. -Two types of signature can be used to perform this function, for more details see below: +Two signature types can perform this function: - direct key signature on the primary key - *primary User ID* binding signature @@ -174,11 +174,11 @@ A [*direct key signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-cr #### Self-signature binding to primary User ID -In OpenPGP v4, another mechanism was often used for this purpose: Piggybacking the global certificate metadata into a User ID binding signature. Specifically, the 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 OpenPGP certificate. +In OpenPGP v4, another mechanism was often used for metadata management: integrating global certificate metadata within a User ID binding signature. This is specifically evident in the 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 OpenPGP certificate. -When using this mechanism, the primary User ID binding signature contains a mix metadata: some that applies just to that particular User ID, and some that applies to the certificate, globally. +This method results in the primary User ID binding signature containing a mix of metadata: some specific to that User ID and some applicable to the certificate globally. -Many existing OpenPGP certificates are using this mechanism, so OpenPGP applications need to be able to handle it. +Given the widespread adoption of this mechanism in existing OpenPGP certificates, it is crucial that OpenPGP applications recognize and manage it. (self-revocations)= ### Revocation self-signatures: Invalidating certificate components From f41cd951395ece0b1c8e3e7317176d700854391d Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Mon, 4 Dec 2023 13:07:44 +0000 Subject: [PATCH 21/21] move globally --- book/source/08-signing_components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index d4d1475..bbf610d 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -153,7 +153,7 @@ Linking a User ID to an OpenPGP certificate The signatures that bind subkeys and identity components to a certificate serve dual purposes: linking components to the certificate and adding metadata to components. -While it is essential to add metadata that pertains to the entire certificate, this does not require binding any component to the certificate. In this case, the signature mechanism is used just to associate metadata globally with the certificate. +While it is essential to add metadata that pertains to the entire certificate, this does not require binding any component to the certificate. In this case, the signature mechanism is used just to associate metadata with the certificate globally. Two signature types can perform this function: