From 819d5e686875ac4f9c4aa94c997b9f3f908e71ee Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Mon, 18 Dec 2023 19:07:19 +0100 Subject: [PATCH 1/9] Adjust glossary link I think this sentence is more about the higher level concept of "data signatures" than about signature packets. --- book/source/signing_data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/signing_data.md b/book/source/signing_data.md index 6ae7953..d5eafe4 100644 --- a/book/source/signing_data.md +++ b/book/source/signing_data.md @@ -26,7 +26,7 @@ Note that {term}`data signatures` are distinct from [](/signing_ {term}`Data signatures` are generated by {term}`hashing` the message content along with the {term}`metadata` in the {term}`OpenPGP signature packet`, and calculating a {term}`cryptographic signature` over that {term}`hash`. The resulting {term}`cryptographic signature` is stored in the {term}`signature packet`. -{term}`Data signature packets` manifest in three distinct forms, which will be detailed in the subsequent section. +{term}`Data signatures` manifest in three distinct forms, which will be detailed in the subsequent section. (forms-of-data-signatures)= ## Forms of OpenPGP data signatures From 16c6d0c265d660c22e11487e8e066cd0515ebb45 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Mon, 18 Dec 2023 19:36:48 +0100 Subject: [PATCH 2/9] Complete unfinished sentence --- book/source/signing_data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/signing_data.md b/book/source/signing_data.md index d5eafe4..76436b8 100644 --- a/book/source/signing_data.md +++ b/book/source/signing_data.md @@ -75,7 +75,7 @@ To produce an {term}`inline signature`, the {term}`signer` processes the entiret For efficient {term}`verification`, an application must understand how to handle the {term}`literal data` prior to its reading. This requirement is addressed by the {term}`one-pass signature packets` located at the beginning of {term}`inline-signed` messages. These {term}`packets` include essential information such as the {term}`fingerprint` of the {term}`signing key` and the {term}`hash` algorithm used for computing the {term}`signature`'s {term}`hash digest`. This setup enables the verifier to process the data correctly and efficiently. -Strictly speaking, knowing just the hash algorithm would be sufficient to begin the verification process. However, having efficient access to the signer's fingerprint or key ID upfront allows OpenPGP software to fetch the signer's certificates before processing the entirety of the - potentially large - signed data, and . +Strictly speaking, knowing just the hash algorithm would be sufficient to begin the verification process. However, having efficient access to the signer's fingerprint or key ID upfront allows OpenPGP software to fetch the signer's certificate(s) before processing the entirety of the - potentially large - signed data. This may, for example, involve downloading the certificate from a keyserver. In case fetching the signer's certificate(s) fails, or requires additional input from the user, it is better to signal the user about this before processing the data. #### Verification From 7ef91f4d057c047c4127eabdd03e14ac3a5b1381 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Mon, 18 Dec 2023 18:28:46 +0100 Subject: [PATCH 3/9] Structure: separate sections for One-pass-signed and Prefixed-signed messages --- book/source/signing_data.md | 33 +++++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/book/source/signing_data.md b/book/source/signing_data.md index 76436b8..b9a43fb 100644 --- a/book/source/signing_data.md +++ b/book/source/signing_data.md @@ -52,12 +52,16 @@ An {term}`inline signature` joins the signed data and its corresponding {term}`d This method is commonly used for signing or encrypting emails. Most email software capable of handling OpenPGP communications typically uses {term}`inline signatures`. -#### Structure +OpenPGP defines two different forms of inline-signed messages: -There are two different constructions available to generate inline-signed messages: +1. **{term}`One-pass-signed messages`** are signed using one or more {term}`one-pass signatures` +2. **{term}`Prefixed-signed messages`** have the actual signature(s) prefixed to the {term}`OpenPGP message`. -* {term}`One-pass-signed messages` are signed using one or more {term}`one-pass signatures` -* {term}`Prefixed-signed messages` have the actual signature(s) prefixed to the {term}`OpenPGP message`. +While the latter is conceptually slightly simpler, it has no strong benefits over {term}`one-pass-signed messages` and is rarely used. + +#### One-pass-signed message + +##### Structure A {term}`one-pass-signed` {term}`OpenPGP message` consists of three segments: @@ -67,9 +71,7 @@ A {term}`one-pass-signed` {term}`OpenPGP message` consi 3. **{term}`Data signature packets`**: These contain the {term}`cryptographic signature` corresponding to the original data. -Less commonly used are {term}`prefixed-signed messages`, where the {term}`signature packet(s)` are simply prepended to the message. - -#### Creation +##### Creation To produce an {term}`inline signature`, the {term}`signer` processes the entirety of the data by reading from an input file and writing into an output {term}`OpenPGP message` file. As the data is processed, the {term}`signer` simultaneously calculates a {term}`cryptographic signature`. This procedure results in the appending of a {term}`data signature packet` to the output {term}`OpenPGP message` file, where it can be efficiently stored. @@ -77,7 +79,7 @@ For efficient {term}`verification`, an application must understand how to handle Strictly speaking, knowing just the hash algorithm would be sufficient to begin the verification process. However, having efficient access to the signer's fingerprint or key ID upfront allows OpenPGP software to fetch the signer's certificate(s) before processing the entirety of the - potentially large - signed data. This may, for example, involve downloading the certificate from a keyserver. In case fetching the signer's certificate(s) fails, or requires additional input from the user, it is better to signal the user about this before processing the data. -#### Verification +##### Verification {term}`Inline-signed` messages enable efficient {term}`verification` in *one pass*, structured as follows: @@ -89,6 +91,21 @@ Strictly speaking, knowing just the hash algorithm would be sufficient to begin Important to note, the {term}`signer`'s {term}`public key`, critical for the final {term}`verification` step, is not embedded in the message. Verifiers must acquire this {term}`key` externally (e.g., from a {term}`key server`) to authenticate the {term}`signature` successfully. +#### Prefixed-signed message + +A {term}`prefixed-signed message` serves the same function as a {term}`one-pass-signed message`. However, this form is less commonly used. +In a {term}`prefixed-signed message`, the {term}`signature packet(s)` are simply prepended to the message. + +Especially for longer messages, it takes a bit more work to generate an inline signed OpenPGP message in this format. + +##### Structure + +1. **{term}`Data signature packets`**: These contain the {term}`cryptographic signature` corresponding to the original data. + +2. [**Literal data packet**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#lit): This contains the original data (e.g., the body of a message), without additional interpretation or conversion. + +Note that the signature packet(s) is/are stored ahead of the message itself, in this format. For verification, this is equally convenient as the one-pass signed message form. However, to create this form, the data must be processed twice: one time reading it to calculate the cryptographic signature, and one time to copy the data into the OpenPGP message after the signature packet(s). + (cleartext-signature)= ### Cleartext signatures From 3d89f0124672a0a5bb7a1a0ad05f4b3cafc6d08c Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Mon, 18 Dec 2023 18:54:11 +0100 Subject: [PATCH 4/9] Add note: a one-pass signature packet is not a type of signature --- book/source/signing_data.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/book/source/signing_data.md b/book/source/signing_data.md index b9a43fb..c505dc6 100644 --- a/book/source/signing_data.md +++ b/book/source/signing_data.md @@ -71,6 +71,12 @@ A {term}`one-pass-signed` {term}`OpenPGP message` consi 3. **{term}`Data signature packets`**: These contain the {term}`cryptographic signature` corresponding to the original data. +```{note} +Despite its name, a {term}`one-pass signature packet` is not a type of {term}`signature packet`. + +Instead, it's a type of auxiliary packet that can be used in conjunction with {term}`signature packets`. Its use allows storing the {term}`signature packets` after the message body. +``` + ##### Creation To produce an {term}`inline signature`, the {term}`signer` processes the entirety of the data by reading from an input file and writing into an output {term}`OpenPGP message` file. As the data is processed, the {term}`signer` simultaneously calculates a {term}`cryptographic signature`. This procedure results in the appending of a {term}`data signature packet` to the output {term}`OpenPGP message` file, where it can be efficiently stored. From e9a21f1d2da435ece88a9b36d96b1b2b11f6edd4 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Mon, 18 Dec 2023 19:39:23 +0100 Subject: [PATCH 5/9] Partially flatten section hierarchy for less depth --- book/source/signing_data.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/book/source/signing_data.md b/book/source/signing_data.md index c505dc6..eaf7177 100644 --- a/book/source/signing_data.md +++ b/book/source/signing_data.md @@ -39,14 +39,14 @@ Note that {term}`data signatures` are distinct from [](/signing_ [^sign-modes-gpg]: These three forms of {term}`signature` application align with GnuPG's `--detach-sign`, `--sign`, and `--clearsign` command options. -### Detached signatures +## Detached signatures A {term}`detached signature` is produced by calculating an {term}`OpenPGP signature` over the data intended for signing. The original data remains unchanged, and the {term}`OpenPGP signature` is stored as a standalone file. A {term}`detached signature` file can be distributed alongside or independent of the original data. The {term}`authenticity` and integrity of the original data file can be {term}`verified` by using the {term}`detached signature` file. This {term}`signature` format is especially useful for signing software releases and other files where it is imperative that the content remains unaltered during the signing process. (inline-signature)= -### Inline signatures +## Inline signatures An {term}`inline signature` joins the signed data and its corresponding {term}`data signature` into a single {term}`OpenPGP message`. @@ -59,9 +59,9 @@ OpenPGP defines two different forms of inline-signed messages: While the latter is conceptually slightly simpler, it has no strong benefits over {term}`one-pass-signed messages` and is rarely used. -#### One-pass-signed message +### One-pass-signed message -##### Structure +#### Structure A {term}`one-pass-signed` {term}`OpenPGP message` consists of three segments: @@ -77,7 +77,7 @@ Despite its name, a {term}`one-pass signature packet` is not a type of {term}`si Instead, it's a type of auxiliary packet that can be used in conjunction with {term}`signature packets`. Its use allows storing the {term}`signature packets` after the message body. ``` -##### Creation +#### Creation To produce an {term}`inline signature`, the {term}`signer` processes the entirety of the data by reading from an input file and writing into an output {term}`OpenPGP message` file. As the data is processed, the {term}`signer` simultaneously calculates a {term}`cryptographic signature`. This procedure results in the appending of a {term}`data signature packet` to the output {term}`OpenPGP message` file, where it can be efficiently stored. @@ -85,7 +85,7 @@ For efficient {term}`verification`, an application must understand how to handle Strictly speaking, knowing just the hash algorithm would be sufficient to begin the verification process. However, having efficient access to the signer's fingerprint or key ID upfront allows OpenPGP software to fetch the signer's certificate(s) before processing the entirety of the - potentially large - signed data. This may, for example, involve downloading the certificate from a keyserver. In case fetching the signer's certificate(s) fails, or requires additional input from the user, it is better to signal the user about this before processing the data. -##### Verification +#### Verification {term}`Inline-signed` messages enable efficient {term}`verification` in *one pass*, structured as follows: @@ -97,14 +97,14 @@ Strictly speaking, knowing just the hash algorithm would be sufficient to begin Important to note, the {term}`signer`'s {term}`public key`, critical for the final {term}`verification` step, is not embedded in the message. Verifiers must acquire this {term}`key` externally (e.g., from a {term}`key server`) to authenticate the {term}`signature` successfully. -#### Prefixed-signed message +### Prefixed-signed message A {term}`prefixed-signed message` serves the same function as a {term}`one-pass-signed message`. However, this form is less commonly used. In a {term}`prefixed-signed message`, the {term}`signature packet(s)` are simply prepended to the message. Especially for longer messages, it takes a bit more work to generate an inline signed OpenPGP message in this format. -##### Structure +#### Structure 1. **{term}`Data signature packets`**: These contain the {term}`cryptographic signature` corresponding to the original data. @@ -113,14 +113,14 @@ Especially for longer messages, it takes a bit more work to generate an inline s Note that the signature packet(s) is/are stored ahead of the message itself, in this format. For verification, this is equally convenient as the one-pass signed message form. However, to create this form, the data must be processed twice: one time reading it to calculate the cryptographic signature, and one time to copy the data into the OpenPGP message after the signature packet(s). (cleartext-signature)= -### Cleartext signatures +## Cleartext signatures The *{term}`Cleartext Signature Framework`* (CSF) in OpenPGP accomplishes two primary objectives: - maintaining the message in a human-readable cleartext format, accessible without OpenPGP-specific software - incorporating an {term}`OpenPGP signature` for {term}`authentication` by users with OpenPGP-compatible software -#### Example +### Example The following is a detailed example of a {numref}`cleartext` signature: @@ -141,7 +141,7 @@ r13/eqMN8kfCDw== This {term}`signature` consists of two parts: a message ("hello world") and an ASCII-armored {term}`OpenPGP signature`. The message is immediately comprehensible to a human reader, while the {term}`signature` block allows for the message's {term}`authenticity` {term}`verification` via OpenPGP software. -#### Use case +### Use case {term}`Cleartext signatures` combine the advantages of both {term}`detached` and {term}`inline signatures`: @@ -153,7 +153,7 @@ These features are particularly beneficial in scenarios where signed messages ar [^arch-certifications]: An illustrative example is the workflow adopted by Arch Linux to {term}`certify` {term}`User IDs` of new packagers. This process relies on [cleartext signed statements from existing packagers](https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/blob/master/.gitlab/issue_templates/New%20Packager%20Key.md?ref_type=heads&plain=1#L33-46). These signed statements are stored as attachments in an issue tracking system for later inspection. The advantage of this approach lies in the convenience of having the message and signature in a single file, which simplifies manual handling. Based on the vouches in these {term}`cleartext signed` messages and an [email confirmation from the new packager](https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/verify-a-packager-key), the main key operators can issue {term}`OpenPGP third-party certifications`. -#### Text transformations for cleartext signatures +### Text transformations for cleartext signatures The {term}`cleartext signature framework` includes specific text normalization procedures to ensure the integrity and clarity of the message: @@ -161,7 +161,7 @@ The {term}`cleartext signature framework` includes specific text normalization p - **Normalization of line endings**: Consistent with the approach for any other [text signature](data-signature-types), a {term}`cleartext signature` is calculated on the text with normalized line endings (``). This ensures that the {term}`signature` remains valid regardless of the text format of the receiving {term}`implementation`. -#### Pitfalls +### Pitfalls Despite their widespread adoption, {term}`cleartext signatures` have their limitations and are sometimes viewed as a "legacy method"[^csf-gnupg]. The {term}`RFC` details the [pitfalls of cleartext signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-issues-with-the-cleartext-s), such as incompatibility with semantically meaningful whitespace, challenges with large messages, and security vulnerabilities related to misleading Hash header manipulations. Given these issues, safer alternatives like {term}`inline` and {term}`detached signature` forms are advised. From b2199d95c5bf2080bbf81a61152b9df17a8366e9 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 19 Dec 2023 11:01:15 +0100 Subject: [PATCH 6/9] Adjust styling of "One-pass signed" to use only one dash, and "Prefixed Signed" accordingly (This mirrors section 10.3 in c-r) --- book/source/glossary.md | 4 ++-- book/source/signing_data.md | 16 ++++++++-------- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/book/source/glossary.md b/book/source/glossary.md index 01fc23f..d07f4dc 100644 --- a/book/source/glossary.md +++ b/book/source/glossary.md @@ -315,7 +315,7 @@ Notation Tag One-pass Signature Packet One or more {term}`packets` before the actual data in a {term}`Data Signature` which contain information to allow a receiving {term}`implementation` to create {term}`hashes` required for signature verification. See [RFC 5.4](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#one-pass-sig) for more details. -One-pass-signed Message +One-pass signed Message A {term}`OpenPGP Message` signed using one or more {term}`One-pass signatures`. OpenPGP Certificate @@ -408,7 +408,7 @@ Preferred AEAD Ciphersuites Subpacket See [RFC 5.2.3.15](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-preferred-aead-ciphersuites) -Prefixed-Signed Message +Prefixed signed Message An {term}`OpenPGP Message` with one or more prefixed {term}`signature packets`. Primary Component Key diff --git a/book/source/signing_data.md b/book/source/signing_data.md index eaf7177..bdb21a7 100644 --- a/book/source/signing_data.md +++ b/book/source/signing_data.md @@ -54,16 +54,16 @@ This method is commonly used for signing or encrypting emails. Most email softwa OpenPGP defines two different forms of inline-signed messages: -1. **{term}`One-pass-signed messages`** are signed using one or more {term}`one-pass signatures` -2. **{term}`Prefixed-signed messages`** have the actual signature(s) prefixed to the {term}`OpenPGP message`. +1. **{term}`One-pass signed messages`** are signed using one or more {term}`one-pass signatures` +2. **{term}`Prefixed signed messages`** have the actual signature(s) prefixed to the {term}`OpenPGP message`. -While the latter is conceptually slightly simpler, it has no strong benefits over {term}`one-pass-signed messages` and is rarely used. +While {term}`prefixed signed messages` are conceptually slightly simpler, they have no strong benefits over {term}`one-pass signed messages` and are rarely used. -### One-pass-signed message +### One-pass signed message #### Structure -A {term}`one-pass-signed` {term}`OpenPGP message` consists of three segments: +A {term}`one-pass signed` {term}`OpenPGP message` consists of three segments: 1. [**One-pass signature packets**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#one-pass-sig): These one or more {term}`packets` precede the signed data and enable {term}`signature` computation in one pass. @@ -97,10 +97,10 @@ Strictly speaking, knowing just the hash algorithm would be sufficient to begin Important to note, the {term}`signer`'s {term}`public key`, critical for the final {term}`verification` step, is not embedded in the message. Verifiers must acquire this {term}`key` externally (e.g., from a {term}`key server`) to authenticate the {term}`signature` successfully. -### Prefixed-signed message +### Prefixed signed message -A {term}`prefixed-signed message` serves the same function as a {term}`one-pass-signed message`. However, this form is less commonly used. -In a {term}`prefixed-signed message`, the {term}`signature packet(s)` are simply prepended to the message. +A {term}`prefixed signed message` serves the same function as a {term}`one-pass signed message`. However, this form is less commonly used. +In a {term}`prefixed signed message`, the {term}`signature packet(s)` are simply prepended to the message. Especially for longer messages, it takes a bit more work to generate an inline signed OpenPGP message in this format. From 864ed59a645611089d90514fe1e3d4c92ade1457 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 19 Dec 2023 13:27:04 +0100 Subject: [PATCH 7/9] Edits for clarity --- book/source/signing_data.md | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/book/source/signing_data.md b/book/source/signing_data.md index bdb21a7..b844be7 100644 --- a/book/source/signing_data.md +++ b/book/source/signing_data.md @@ -52,15 +52,17 @@ An {term}`inline signature` joins the signed data and its corresponding {term}`d This method is commonly used for signing or encrypting emails. Most email software capable of handling OpenPGP communications typically uses {term}`inline signatures`. -OpenPGP defines two different forms of inline-signed messages: +OpenPGP defines two variant forms of inline-signed messages: -1. **{term}`One-pass signed messages`** are signed using one or more {term}`one-pass signatures` -2. **{term}`Prefixed signed messages`** have the actual signature(s) prefixed to the {term}`OpenPGP message`. +1. **{term}`One-pass signed messages`** This is the commonly used format for inline-signed messages. A signer can produce this format in one pass. +2. **{term}`Prefixed signed messages`** This format predates[^inline-signature-formats] {term}`one-pass signed messages` and is conceptually slightly simpler. However, it has no strong benefits and is now rarely used. -While {term}`prefixed signed messages` are conceptually slightly simpler, they have no strong benefits over {term}`one-pass signed messages` and are rarely used. +[^inline-signature-formats]: One-pass signing was first specified in RFC 2440. The format was not supported in PGP 2.6.x. ### One-pass signed message +This is the commonly used format for inline signed messages. + #### Structure A {term}`one-pass signed` {term}`OpenPGP message` consists of three segments: @@ -90,7 +92,7 @@ Strictly speaking, knowing just the hash algorithm would be sufficient to begin {term}`Inline-signed` messages enable efficient {term}`verification` in *one pass*, structured as follows: 1. **Initiation with {term}`one-pass signature packets`**: These {term}`packets` begin the {term}`verification` process. They include the {term}`signer`'s {term}`key ID`/{term}`fingerprint`, essential for identifying the appropriate {term}`public key` for signature {term}`validation`. - + 2. **Processing the {term}`literal data packet`**: This step involves {term}`hashing` the literal data, preparing it for {term}`signature` {term}`verification`. 3. **{term}`Verifying` {term}`signature packets`**: Located at the end of the message, these {term}`packets` are checked against the previously calculated {term}`hash digest`. @@ -99,18 +101,24 @@ Important to note, the {term}`signer`'s {term}`public key`, ### Prefixed signed message -A {term}`prefixed signed message` serves the same function as a {term}`one-pass signed message`. However, this form is less commonly used. -In a {term}`prefixed signed message`, the {term}`signature packet(s)` are simply prepended to the message. - -Especially for longer messages, it takes a bit more work to generate an inline signed OpenPGP message in this format. +A {term}`prefixed signed message` consists of {term}`signature packet(s)` followed by the message. This inline signature format serves the same function as a {term}`one-pass signed message`. For the verifier, the two formats are equally convenient. However, on the signer's side, it takes more computational work to generate a {term}`prefixed signed message`. #### Structure -1. **{term}`Data signature packets`**: These contain the {term}`cryptographic signature` corresponding to the original data. +In this format, the signature packets are stored ahead of the message itself: + +1. **{term}`Data signature packets`**: These one or more packets contain the {term}`cryptographic signature` corresponding to the original data. 2. [**Literal data packet**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#lit): This contains the original data (e.g., the body of a message), without additional interpretation or conversion. -Note that the signature packet(s) is/are stored ahead of the message itself, in this format. For verification, this is equally convenient as the one-pass signed message form. However, to create this form, the data must be processed twice: one time reading it to calculate the cryptographic signature, and one time to copy the data into the OpenPGP message after the signature packet(s). +Compared to a {term}`one-pass signed message`, there are no {term}`one-pass signature packets` in this format, and the (otherwise equivalent) {term}`signature packet(s)` are stored ahead of the signed data. + +For verification, this is equally convenient as the one-pass signed message form. + +However, when a signer creates a {term}`prefixed signed message`, the signed data must be processed twice: + +- once reading it to calculate the cryptographic signature, and +- once more to store the data in the generated OpenPGP message, after the signature packet(s). (cleartext-signature)= ## Cleartext signatures From cf765f0b446c09ccfcaac4de9c668d55326e6f13 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 19 Dec 2023 13:37:05 +0100 Subject: [PATCH 8/9] Add link target headers --- book/source/signing_data.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/book/source/signing_data.md b/book/source/signing_data.md index b844be7..3fe97eb 100644 --- a/book/source/signing_data.md +++ b/book/source/signing_data.md @@ -59,6 +59,7 @@ OpenPGP defines two variant forms of inline-signed messages: [^inline-signature-formats]: One-pass signing was first specified in RFC 2440. The format was not supported in PGP 2.6.x. +(one-pass-signature)= ### One-pass signed message This is the commonly used format for inline signed messages. @@ -99,6 +100,7 @@ Strictly speaking, knowing just the hash algorithm would be sufficient to begin Important to note, the {term}`signer`'s {term}`public key`, critical for the final {term}`verification` step, is not embedded in the message. Verifiers must acquire this {term}`key` externally (e.g., from a {term}`key server`) to authenticate the {term}`signature` successfully. +(prefixed-signature)= ### Prefixed signed message A {term}`prefixed signed message` consists of {term}`signature packet(s)` followed by the message. This inline signature format serves the same function as a {term}`one-pass signed message`. For the verifier, the two formats are equally convenient. However, on the signer's side, it takes more computational work to generate a {term}`prefixed signed message`. From 99e2ea7cdd89d389c6c66eea3aa86a3db0ab1180 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 19 Dec 2023 15:45:07 +0100 Subject: [PATCH 9/9] Expand glossary entries for inline signatures forms. --- book/source/glossary.md | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/book/source/glossary.md b/book/source/glossary.md index d07f4dc..e804683 100644 --- a/book/source/glossary.md +++ b/book/source/glossary.md @@ -224,7 +224,14 @@ Initial Introducer An {term}`OpenPGP Certificate` explicitly {term}`delegated` to from a {term}`Trust Anchor`. Inline Signature - A {term}`Data Signature` which exists encapsulated alongside the data it was created for in an OpenPGP container. See [](forms-of-data-signatures). + An [inline signature](inline-signature) is a type of {term}`OpenPGP message` which stores a {term}`Data Signature` alongside the message it signs. Both the message and the signature are stored in a shared OpenPGP container. + + The standard defines two variant formats for inline signatures: + + - {term}`One-pass signed Message`: This format is now commonly used. + - {term}`Prefixed signed Message`: This is a historical format. It is still supported, but rarely used. + + For more context, see [](forms-of-data-signatures). Issuer An entity, that created an {term}`OpenPGP Signature Packet` using an {term}`Transferable Secret Key`. @@ -316,7 +323,9 @@ One-pass Signature Packet One or more {term}`packets` before the actual data in a {term}`Data Signature` which contain information to allow a receiving {term}`implementation` to create {term}`hashes` required for signature verification. See [RFC 5.4](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#one-pass-sig) for more details. One-pass signed Message - A {term}`OpenPGP Message` signed using one or more {term}`One-pass signatures`. + The commonly used form of an OpenPGP {term}`Inline Signature`. It combines an {term}`OpenPGP Message` with {term}`signature packets` and accompanying auxiliary {term}`One-pass signatures`. + + For details see [](one-pass-signature). OpenPGP Certificate An OpenPGP certificate contains public key material, identity claims and third party certifications (but no private key material) @@ -409,7 +418,9 @@ Preferred AEAD Ciphersuites Subpacket See [RFC 5.2.3.15](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-preferred-aead-ciphersuites) Prefixed signed Message - An {term}`OpenPGP Message` with one or more prefixed {term}`signature packets`. + A type of {term}`Inline Signature`. This form of {term}`Inline Signature` is historical and now rarely used. Superseded by {term}`One-pass signed Message`. + + For details see [](prefixed-signature). Primary Component Key See {term}`OpenPGP Primary Key`.