From 16d444207395244096a8eed435d310d2cf7b97fd Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Mon, 4 Dec 2023 11:19:41 +0000 Subject: [PATCH 1/5] 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 2/5] 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 3/5] 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 4/5] 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 5/5] 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: