From 51ba91910605a9e8a67e5be67a6642b14df06fd5 Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Fri, 10 Nov 2023 17:28:26 +0100 Subject: [PATCH 01/25] edit ch7 signatures over data --- book/source/07-signing_data.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 7331a3a..adbf0db 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -6,15 +6,14 @@ SPDX-License-Identifier: CC-BY-SA-4.0 (signing_data)= # Signatures over data -A *data signature* guarantees the authenticity (and implicitly also the integrity) of some data. Typical use cases for data signatures in OpenPGP are signatures for software packages or emails. +In OpenPGP, a *data signature* guarantees the authenticity and, implicitly, the integrity of certain data. Typical use cases include the authentication of software packages and emails. -When we say "authenticity," here, we mean that the signature guarantees that whoever controls the signing key material has issued the signature. +"Authenticity" in this context means that the data signature was issued by the entity controlling the signing key material. However, +it does not automatically signal if the expected party indeed controls the signer certificate. OpenPGP does offer mechanisms for *strong authentication*, connecting certificates to specific identities. This verifies that the intended communication partner is indeed associated with the cryptographic identity behind the signature[^sign-auth]. -It is a separate question if the party we expect indeed controls the signer certificate. OpenPGP does offer mechanisms for *strong authentication* of the connection between certificates and identities. So, if necessary, we can also verify that our intended communication partner really uses the cryptographic identity that issued the signature[^sign-auth]. +[^sign-auth]: Other signing solutions, like [signify](https://flak.tedunangst.com/post/signify), focus on pure signing without strong authentication of the signer's identity. -[^sign-auth]: Other signing solutions, such as [signify](https://flak.tedunangst.com/post/signify), typically only offer a solution for pure signing, without offering a mechanism for strong authentication of the identity of the signer. - -Data signatures can only be issued by component keys that carry the *signing* [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags). +Data signatures can only be issued by component keys with the *signing* [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags). Note that signatures over data are distinct from {ref}`component_signatures_chapter`, which are used to attach metadata or subkeys to a certificate. From f7ea1b115e60bb1e3592e20d27fbcef46551a416 Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Fri, 10 Nov 2023 17:45:36 +0100 Subject: [PATCH 02/25] edit ch7 ## Signature types --- book/source/07-signing_data.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index adbf0db..8f3bdfa 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -19,15 +19,14 @@ Note that signatures over data are distinct from {ref}`component_signatures_chap ## Signature types -Data signatures use one of two OpenPGP [signature types](signature_types): +OpenPGP data signatures use one of two [signature types](signature_types): -- "Signature of a binary document" (*Binary Signature*, type ID `0x00`): A universal signature type for binary data. Binary signatures are typically used for files or data streams. -Binary signatures are calculated over the data "as is", without performing any transformations. -- "Signature of a canonical text document" (*Text Signature*, type ID `0x01`): Used for textual data, such as email bodies. When calculating a text signature, the data is first normalized by converting line endings into a canonical form (``). The normalization mitigates issues caused by platform-specific text encodings, for example with detached signatures, where the message file may get re-encoded between signature generation and validation. +- **Binary signature** (type ID `0x00`): This is the standard signature type for binary data and is typically used for files or data streams. Binary signatures are calculated over the data without any modifications or transformations. +- **Text signature** (type ID `0x01`): Used for textual data, such as email bodies. When calculating a text signature, the data is first normalized by converting line endings into a canonical form (``). This mitigates issues caused by platform-specific text encodings, which is particularly important for detached signatures where the message file might be re-encoded between signature creation and verification. -Data signatures are generated by hashing the message content, plus the metadata in the signature packet, and calculating a cryptographic signature over that hash. The resulting cryptographic signature is stored in an OpenPGP signature packet. +Data signatures are generated by hashing the message content along with the metadata in the signature packet, and calculating a cryptographic signature over that hash. The resulting cryptographic signature is stored in an OpenPGP signature packet. -Data signature packets can be used in three different forms. We'll discuss these in the following section. +Data signature packets manifest in three distinct forms, which will be detailed in the subsequent section. ## Forms of OpenPGP data signatures From 4fd97868e8f4f13488003a571b820ffa09aeb45c Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Fri, 10 Nov 2023 17:53:52 +0100 Subject: [PATCH 03/25] edit ch7 forms of data signatures --- book/source/07-signing_data.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 8f3bdfa..6d9b541 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -33,8 +33,8 @@ Data signature packets manifest in three distinct forms, which will be detailed OpenPGP signatures over data can be used in three different forms[^sign-modes-gpg]: - *Detached*: The signature is a standalone artifact, separate from the signed data. -- *Inline*: The original data and the signature over the data are collectively stored in an OpenPGP container. -- *Cleartext signature*: A message in text format and a signature over this message are stored in a combined text-format, which leaves the original message in a human-readable representation. +- *Inline*: The original data and the signature over data are enclosed within an OpenPGP container. +- *Cleartext signature*: A plaintext message and a signature over this message are stored in a combined text-format, maintaining the original message's readability. [^sign-modes-gpg]: These three signature forms correspond with GnuPG's `--detach-sign`, `--sign` and `--clear-sign` modes. From 1b5edc1774ae3ca1891cd35148fc0d0c9281eeff Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 11 Nov 2023 18:37:14 +0100 Subject: [PATCH 04/25] ch7: clarify CSF and its use --- book/source/07-signing_data.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 6d9b541..cc0385c 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -106,23 +106,22 @@ r13/eqMN8kfCDw== -----END PGP SIGNATURE----- ``` -The cleartext signature consists of two blocks, which contain the message and a signature, respectively. In this case, the message consists of the text "hello world". +A cleartext signature consists of two blocks. These blocks contain the message and a signature, respectively. In this case, the message consists of the text `hello world`. -Notice that this message is readable by a human reader, without requiring additional software tools, as long as the reader understands which elements to ignore. +Notice that the message in the first block is readable by a human reader, without requiring additional software tools, as long as the reader knows where to look, and which elements to ignore. -The message is followed by a block that contains an ASCII-armored OpenPGP signature for the message. Using this signature, OpenPGP software can verify the authenticity of the message in the first block. +The second block contains an ASCII-armored OpenPGP signature for the message. Using this signature, OpenPGP software can verify the authenticity of the message. -#### Use-case +#### Use-cases -One use-case for cleartext signatures is: Asking someone to sign some piece of data. The person who is asked to sign the data can easily inspect it with simple commandline tools, such as `cat`, and verify that they agree with the data they are asked to sign. +Clear text signatures combine two of the benefits of detached and inline-signatures: -```{admonition} TODO -:class: warning +- They are self-contained, the message and signature can be stored as a single file +- The message remains human-readable, without requiring additional software tooling -(Ask David for details:) +This combination can be attractive for processes where signed messages are handled in a partially manual manner, and stored in a system that doesn't have strong support for OpenPGP in that particular workflow[^arch-certifications]. -We use this for example to verify User ID and primary key of Arch Linux packagers before signing the User IDs on their keys with the main signing keys and to verify the data claims when introducing new packagers (i.e. already established packagers vouch for the data of a new packager). -``` +[^arch-certifications]: For example, Arch Linux uses a workflow to certify User IDs of new packagers that relies on [cleartext signed statements by established 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 in an issue tracker system, as attachments, for later inspection. In this use case, it is convenient that the message and the signature are stored as one combined file (not as separate ones which would be more tedious to handle manually), and that the message is easy to read. Based on the vouches in these cleartext signed messages, and an [email confirmation by the new packager](https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/verify-a-packager-key), main signing key operators issue OpenPGP third-party certifications. #### Text transformations for cleartext signatures From 6dc243de9820fc170018cfc2c6cb43609dd97c05 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 11 Nov 2023 18:45:18 +0100 Subject: [PATCH 05/25] ch7: Write "transformations" section about CSF --- book/source/07-signing_data.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index cc0385c..ef18212 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -17,6 +17,7 @@ Data signatures can only be issued by component keys with the *signing* [key fla Note that signatures over data are distinct from {ref}`component_signatures_chapter`, which are used to attach metadata or subkeys to a certificate. +(data_signature_types)= ## Signature types OpenPGP data signatures use one of two [signature types](signature_types): @@ -125,11 +126,9 @@ This combination can be attractive for processes where signed messages are handl #### Text transformations for cleartext signatures -```{admonition} TODO -:class: warning +In the cleartext signature framework, the message text is normalized by [escaping dashes](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-dash-escaped-text), to prevent parsing problems where message content and armor headers are confused. -explain text transformations for cleartext signatures (LF->CRLF and additional escaping) -``` +Additionally, as usual for [text signatures](data_signature_types), the signature is calculated on the text with normalized line endings (``). #### Pitfalls From f0052e23c246f8ea45ae74f1eb2c8ea7dc61d600 Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Mon, 13 Nov 2023 20:57:44 +0100 Subject: [PATCH 06/25] edits to data signature forms --- book/source/07-signing_data.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 6d9b541..c28a887 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -30,13 +30,14 @@ Data signature packets manifest in three distinct forms, which will be detailed ## Forms of OpenPGP data signatures -OpenPGP signatures over data can be used in three different forms[^sign-modes-gpg]: +OpenPGP data signatures can be applied in three distinct methods[^sign-modes-gpg]: -- *Detached*: The signature is a standalone artifact, separate from the signed data. -- *Inline*: The original data and the signature over data are enclosed within an OpenPGP container. -- *Cleartext signature*: A plaintext message and a signature over this message are stored in a combined text-format, maintaining the original message's readability. +- **Detached**: The OpenPGP signature exists as a separate entity, independent from the signed data. +- **Inline**: Both the original data and its corresponding OpenPGP signature are encapsulated within an OpenPGP container. +- **Cleartext signature**: A plaintext message and its OpenPGP signature coexist in a combined text format, preserving the readability of the original message. -[^sign-modes-gpg]: These three signature forms correspond with GnuPG's `--detach-sign`, `--sign` and `--clear-sign` modes. + +[^sign-modes-gpg]: These three methods of signature application align with GnuPG's `--detach-sign`, `--sign`, and `--clearsign` command options. ### Detached signatures From a76acf950b6278b7b8a977277dcd815c046f52c6 Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Mon, 13 Nov 2023 20:57:56 +0100 Subject: [PATCH 07/25] edits to data signature forms --- book/source/07-signing_data.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index c28a887..4ef4aa8 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -30,14 +30,14 @@ Data signature packets manifest in three distinct forms, which will be detailed ## Forms of OpenPGP data signatures -OpenPGP data signatures can be applied in three distinct methods[^sign-modes-gpg]: +OpenPGP data signatures can be applied in three distinct forms[^sign-modes-gpg]: - **Detached**: The OpenPGP signature exists as a separate entity, independent from the signed data. - **Inline**: Both the original data and its corresponding OpenPGP signature are encapsulated within an OpenPGP container. - **Cleartext signature**: A plaintext message and its OpenPGP signature coexist in a combined text format, preserving the readability of the original message. -[^sign-modes-gpg]: These three methods of signature application align with GnuPG's `--detach-sign`, `--sign`, and `--clearsign` command options. +[^sign-modes-gpg]: These three forms of signature application align with GnuPG's `--detach-sign`, `--sign`, and `--clearsign` command options. ### Detached signatures From 7e89a9f11f4224eba727e30b45309f43069a42a3 Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Mon, 13 Nov 2023 21:18:15 +0100 Subject: [PATCH 08/25] remove blank line --- book/source/07-signing_data.md | 1 - 1 file changed, 1 deletion(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 4ef4aa8..28dcaba 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -36,7 +36,6 @@ OpenPGP data signatures can be applied in three distinct forms[^sign-modes-gpg]: - **Inline**: Both the original data and its corresponding OpenPGP signature are encapsulated within an OpenPGP container. - **Cleartext signature**: A plaintext message and its OpenPGP signature coexist in a combined text format, preserving the readability of the original message. - [^sign-modes-gpg]: These three forms of signature application align with GnuPG's `--detach-sign`, `--sign`, and `--clearsign` command options. ### Detached signatures From ee65b80bc7eebd5a2171df9e8b9ba96b1ba23b25 Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Mon, 13 Nov 2023 21:20:09 +0100 Subject: [PATCH 09/25] default to data signatures not signature over data --- book/source/07-signing_data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 28dcaba..f6c2b7b 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -15,7 +15,7 @@ it does not automatically signal if the expected party indeed controls the signe Data signatures can only be issued by component keys with the *signing* [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags). -Note that signatures over data are distinct from {ref}`component_signatures_chapter`, which are used to attach metadata or subkeys to a certificate. +Note that data signatures are distinct from {ref}`component_signatures_chapter`, which are used to attach metadata or subkeys to a certificate. ## Signature types From 62af0cb83b8ede55913fa7dad98825157c5d3514 Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Mon, 13 Nov 2023 21:27:37 +0100 Subject: [PATCH 10/25] edit ch7 detached signatures --- book/source/07-signing_data.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index f6c2b7b..eb4a596 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -40,9 +40,9 @@ OpenPGP data signatures can be applied in three distinct forms[^sign-modes-gpg]: ### Detached signatures -A detached signature is produced by calculating an OpenPGP signature over the signed data. The original data is left as is, while the OpenPGP signature is stored as a standalone file. A detached signature can be distributed alongside or independent of the original data. The authenticity and integrity of the original data file can be verified using the detached signature file. +A detached signature is produced by calculating an OpenPGP signature over the data intended for signing. The original data remains unchanged, and the OpenPGP signature is stored as a standalone file. A detached signature file can be distributed alongside or independent of the original data. The authenticity and integrity of the original data file can be verified by using the detached signature file. -This signature format is especially useful for signing software releases and other files that must not be modified by the signing process. +This 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 signatures From 17d43e0e91485e44c127a2f6b62ea1505e08f70d Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Mon, 13 Nov 2023 21:33:03 +0100 Subject: [PATCH 11/25] edit ch7 inline signatures --- book/source/07-signing_data.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index eb4a596..3fd5d5e 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -46,9 +46,9 @@ This signature format is especially useful for signing software releases and oth ### Inline signatures -An inline signature joins the signed data and a signature over this data into one combined OpenPGP message. +An inline signature joins the signed data and its corresponding data signature into a single OpenPGP message. -This method is usually used with signed and/or encrypted emails. Most software that supports OpenPGP for encrypted and/or signed messages uses inline-signatures. +This method is commonly used for signing or encrypting emails. Most email software capable of handling OpenPGP communications typically uses inline signatures. #### Structure From e6b9c11a3dabce9564b0c9732be731c70e6f53be Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Mon, 13 Nov 2023 22:06:35 +0100 Subject: [PATCH 12/25] edit ch7 inline signatures --- book/source/07-signing_data.md | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 3fd5d5e..618e80f 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -54,15 +54,18 @@ This method is commonly used for signing or encrypting emails. Most email softwa An inline-signed OpenPGP message consists of three segments: -- One or more [One-Pass Signature packets](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#one-pass-sig), -- the original data, wrapped in a [Literal Data packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#lit), -- the corresponding Data Signature packets. +1. **One-pass signature packets**: These one or more packets precede the signed data and enable signature computation in one pass. See[One-Pass Signature Packet (Type ID 4)](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#one-pass-sig) of the RFC. + +2. **Literal data**: This is the original data (e.g., the body of a message) that the user wishes to encrypt or sign, without additional interpretation or conversion. [Literal Data Packet (Type ID 11)](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#lit). + +3. **Data signature packets**: These contain the cryptographic signature corresponding to the original data. + #### Creation -To produce an inline signature, the signer processes the entirety of the data by reading from an input file and writing into am output OpenPGP message file. The signer calculates a cryptographic signature over the course of this process. Therefore, an efficient signer can only emit the resulting data signature packet at the end of this process, and thus store it at the end of the data stream. +To produce an inline signature, the signer processes the entirety of the data by reading from an input file and writing into am output OpenPGP message file. As the data is processed, the signer simultaneously calculates a cryptographic signature. This procedure results in a data signature packet being appended to the output OpenPGP message file, an essential step for efficient signing. -On the other hand, an efficient verifying application needs to know how to process the literal data before reading it. This is the purpose of the so-called One-Pass Signature packets in the first segment of inline-signed messages. One-Pass Signature packets contain the fingerprint of the signing key, as well as the hash algorithm used to calculate the hash digest for the signature. +For efficient verification, an application must understand how to handle the literal data prior to its reading. This requirement is addressed by the One-Pass Signature packets located at the beginning of inline-signed messages. These packets include essential information such as the fingerprint of the signing key and the hash algorithm used for computing the signature's hash digest. This setup enables the verifier to process the data correctly and efficiently. ```{admonition} TODO :class: warning @@ -72,13 +75,15 @@ Is the signer keyid/fingerprint in the OPS important for the verifier to be able #### Verification -This structure allows verifying applications to verify inline-signed messages in *one pass*: +Inline-signed messages enable efficient verification in *one pass*, structured as follows: -- The One-Pass Signature packets initiate the verification process, -- the literal data can then be processed (which means: it gets hashed), -- the signature packets at the end of the message can be verified against the hash digest that the previous step calculated. +1. **Initiation with One-Pass Signature packets**: These packets begin the verification process. They include the signer's key ID/fingerprint, essential for identifying the appropriate public key for signature validation. + +2. **Processing the literal data**: This step involves hashing the literal data, preparing it for signature verification. -Note that the final step of verifying the cryptographic signature requires access to the signer's public key material. This public key material is not included in the signed message. The verifier must obtain the signer's public key data out-of-band (e.g. by obtaining the signer's certificate from a key server). +3. **Verifying signature packets**: Located at the end of the message, these packets are checked against the previously calculated hash digest. + +Important to note, the signer's public key, critical for the final verification step, is not embedded in the message. Verifiers must acquire this key externally (e.g., from a key server) to authenticate the signature successfully. ### Cleartext signatures From 78c8327733438d3f16bec731a926701dec7be062 Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Mon, 13 Nov 2023 22:36:05 +0100 Subject: [PATCH 13/25] edit ch7 cleartext signature --- book/source/07-signing_data.md | 24 ++++++++---------------- 1 file changed, 8 insertions(+), 16 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 618e80f..0c342a5 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -87,14 +87,14 @@ Important to note, the signer's public key, critical for the final verification ### Cleartext signatures -The *Cleartext Signature Framework* (CSF) is an OpenPGP mechanism that combines two goals: +The *Cleartext Signature Framework* (CSF) in OpenPGP accomplishes two primary objectives: -- It leaves the message in clear text format, so that it can be viewed directly by a human in a program that knows nothing about OpenPGP. -- At the same time, it adds an OpenPGP signature that allows verification of that message by users whose software supports OpenPGP. +- maintaining the message in a human-readable cleartext format, accessible without OpenPGP-specific software +- incorporating an OpenPGP signature for authentication by users with OpenPGP-compatible software #### Example -In {numref}`cleartext` we inspect an example of a cleartext signature in detail. Let's have a brief look at this example, here, to get a sense of what a cleartext signature looks like: +Below is a detailed example of a {numref}`cleartext` signature: ```text -----BEGIN PGP SIGNED MESSAGE----- @@ -111,15 +111,11 @@ r13/eqMN8kfCDw== -----END PGP SIGNATURE----- ``` -The cleartext signature consists of two blocks, which contain the message and a signature, respectively. In this case, the message consists of the text "hello world". +This signature is split into two parts: a message ("hello world") and an ASCII-armored OpenPGP signature. The message is immediately comprehensible to a human reader, while the signature block allows for the message's authenticity verification via OpenPGP software. -Notice that this message is readable by a human reader, without requiring additional software tools, as long as the reader understands which elements to ignore. +#### Use case -The message is followed by a block that contains an ASCII-armored OpenPGP signature for the message. Using this signature, OpenPGP software can verify the authenticity of the message in the first block. - -#### Use-case - -One use-case for cleartext signatures is: Asking someone to sign some piece of data. The person who is asked to sign the data can easily inspect it with simple commandline tools, such as `cat`, and verify that they agree with the data they are asked to sign. +A common use case is requesting someone to sign data. The signer can easily inspect the data using simple command line tools (e.g., `cat`) to verify that they agree with the content of the data before deciding to sign it. ```{admonition} TODO :class: warning @@ -139,14 +135,10 @@ explain text transformations for cleartext signatures (LF->CRLF and additional e #### Pitfalls -Cleartext signatures are popular and have useful applications. - -At the same time, they are considered a "legacy method"[^csf-gnupg] by some. +While widely used, cleartext signatures are sometimes considered a "legacy method"[^csf-gnupg]. The RFC outlines [pitfalls of cleartext signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-issues-with-the-cleartext-s) and advises that inline and detached signature forms are often preferable. [^csf-gnupg]: https://lists.gnupg.org/pipermail/gnupg-devel/2023-November/035428.html -The RFC points out a number of specific [pitfalls of cleartext signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-issues-with-the-cleartext-s), and how to avoid them. It advises that in many cases, the inline and detached signature forms are preferable. - ## Advanced topics ### Nesting of one-pass signatures From 94eb58070b4ff18d93ec24ff61361aa88c376827 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 14 Nov 2023 11:33:26 +0100 Subject: [PATCH 14/25] Attempt at clearer description --- book/source/07-signing_data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index cc2a757..1d0bb34 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -15,7 +15,7 @@ it does not automatically signal if the expected party indeed controls the signe Data signatures can only be issued by component keys with the *signing* [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags). -Note that data signatures are distinct from {ref}`component_signatures_chapter`, which are used to attach metadata or subkeys to a certificate. +Note that data signatures are distinct from {ref}`component_signatures_chapter`, which are used to form and maintain certificates, as well as to certify identities on certificates. (data_signature_types)= ## Signature types From 029e517b84190a4afbf0186230d29b653202d6d4 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 14 Nov 2023 13:20:14 +0100 Subject: [PATCH 15/25] removed "particularly", because for inline signatures, this issue doesn't exist at all. added the "cleartext" case, which is equivalent here. --- book/source/07-signing_data.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 1d0bb34..9b010d2 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -22,8 +22,8 @@ Note that data signatures are distinct from {ref}`component_signatures_chapter`, OpenPGP data signatures use one of two [signature types](signature_types): -- **Binary signature** (type ID `0x00`): This is the standard signature type for binary data and is typically used for files or data streams. Binary signatures are calculated over the data without any modifications or transformations. -- **Text signature** (type ID `0x01`): Used for textual data, such as email bodies. When calculating a text signature, the data is first normalized by converting line endings into a canonical form (``). This mitigates issues caused by platform-specific text encodings, which is particularly important for detached signatures where the message file might be re-encoded between signature creation and verification. +- [**Binary signature**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-binary) (type ID `0x00`): This is the standard signature type for binary data and is typically used for files or data streams. Binary signatures are calculated over the data without any modifications or transformations. +- [**Text signature**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-of-a-canonical-te) (type ID `0x01`): Used for textual data, such as email bodies. When calculating a text signature, the data is first normalized by converting line endings into a canonical form (``). This mitigates issues caused by platform-specific text encodings, which is important for detached and cleartext signatures where the message file might be re-encoded between signature creation and verification. Data signatures are generated by hashing the message content along with the metadata in the signature packet, and calculating a cryptographic signature over that hash. The resulting cryptographic signature is stored in an OpenPGP signature packet. From ad7b58ce7192c9a0547cc360717c85cc9f47b2ac Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 14 Nov 2023 13:35:11 +0100 Subject: [PATCH 16/25] clarify/tighten: there is just *one* signature packet in this paragraph. --- book/source/07-signing_data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 9b010d2..712852c 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -25,7 +25,7 @@ OpenPGP data signatures use one of two [signature types](signature_types): - [**Binary signature**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-binary) (type ID `0x00`): This is the standard signature type for binary data and is typically used for files or data streams. Binary signatures are calculated over the data without any modifications or transformations. - [**Text signature**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-of-a-canonical-te) (type ID `0x01`): Used for textual data, such as email bodies. When calculating a text signature, the data is first normalized by converting line endings into a canonical form (``). This mitigates issues caused by platform-specific text encodings, which is important for detached and cleartext signatures where the message file might be re-encoded between signature creation and verification. -Data signatures are generated by hashing the message content along with the metadata in the signature packet, and calculating a cryptographic signature over that hash. The resulting cryptographic signature is stored in an OpenPGP signature packet. +Data signatures are generated by hashing the message content along with the metadata in the OpenPGP signature packet, and calculating a cryptographic signature over that hash. The resulting cryptographic signature is stored in the signature packet. Data signature packets manifest in three distinct forms, which will be detailed in the subsequent section. From 1e231b0f4539c6ab789981f9758a83cdf1f7f5d0 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 14 Nov 2023 17:33:46 +0100 Subject: [PATCH 17/25] adjust RFC linking, minor tweaks. I removed the "type IDs" here, because these are *packet type* IDs. The only IDs we're using in the text are *signature types*. I believe signature type IDs are the only IDs that application developers sometimes think about in numerical terms. --- book/source/07-signing_data.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 712852c..b8ce38d 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -55,13 +55,12 @@ This method is commonly used for signing or encrypting emails. Most email softwa An inline-signed OpenPGP message consists of three segments: -1. **One-pass signature packets**: These one or more packets precede the signed data and enable signature computation in one pass. See[One-Pass Signature Packet (Type ID 4)](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#one-pass-sig) of the RFC. +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 packets precede the signed data and enable signature computation in one pass. -2. **Literal data**: This is the original data (e.g., the body of a message) that the user wishes to encrypt or sign, without additional interpretation or conversion. [Literal Data Packet (Type ID 11)](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#lit). +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. 3. **Data signature packets**: These contain the cryptographic signature corresponding to the original data. - #### Creation To produce an inline signature, the signer processes the entirety of the data by reading from an input file and writing into am output OpenPGP message file. As the data is processed, the signer simultaneously calculates a cryptographic signature. This procedure results in a data signature packet being appended to the output OpenPGP message file, an essential step for efficient signing. From 77d056702a63885732d890fa8d6a0572cf8664e8 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 14 Nov 2023 18:10:06 +0100 Subject: [PATCH 18/25] clarity, fix typo, normalize capitalization --- book/source/07-signing_data.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index b8ce38d..6a5458b 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -63,9 +63,9 @@ An inline-signed OpenPGP message consists of three segments: #### Creation -To produce an inline signature, the signer processes the entirety of the data by reading from an input file and writing into am output OpenPGP message file. As the data is processed, the signer simultaneously calculates a cryptographic signature. This procedure results in a data signature packet being appended to the output OpenPGP message file, an essential step for efficient signing. +To produce an inline signature, the signer processes the entirety of the data by reading from an input file and writing into an output OpenPGP message file. As the data is processed, the signer simultaneously calculates a cryptographic signature. This procedure results in a data signature packet being appended to the output OpenPGP message file, where it can be efficiently stored. -For efficient verification, an application must understand how to handle the literal data prior to its reading. This requirement is addressed by the One-Pass Signature packets located at the beginning of inline-signed messages. These packets include essential information such as the fingerprint of the signing key and the hash algorithm used for computing the signature's hash digest. This setup enables the verifier to process the data correctly and efficiently. +For efficient verification, an application must understand how to handle the literal data prior to its reading. This requirement is addressed by the one-pass signature packets located at the beginning of inline-signed messages. These packets include essential information such as the fingerprint of the signing key and the hash algorithm used for computing the signature's hash digest. This setup enables the verifier to process the data correctly and efficiently. ```{admonition} TODO :class: warning @@ -77,9 +77,9 @@ Is the signer keyid/fingerprint in the OPS important for the verifier to be able Inline-signed messages enable efficient verification in *one pass*, structured as follows: -1. **Initiation with One-Pass Signature packets**: These packets begin the verification process. They include the signer's key ID/fingerprint, essential for identifying the appropriate public key for signature validation. +1. **Initiation with one-pass signature packets**: These packets begin the verification process. They include the signer's key ID/fingerprint, essential for identifying the appropriate public key for signature validation. -2. **Processing the literal data**: This step involves hashing the literal data, preparing it for signature verification. +2. **Processing the literal data packet**: This step involves hashing the literal data, preparing it for signature verification. 3. **Verifying signature packets**: Located at the end of the message, these packets are checked against the previously calculated hash digest. From 5a454e85e7d0bd4ac801804fcf1ccb492883b0eb Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 14 Nov 2023 19:46:23 +0100 Subject: [PATCH 19/25] extend todo-note --- book/source/07-signing_data.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 6a5458b..787e9fc 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -71,6 +71,8 @@ For efficient verification, an application must understand how to handle the lit :class: warning Is the signer keyid/fingerprint in the OPS important for the verifier to be able to verify the signature efficiently? Or is it (only?) there to be hashed and signed, along with the literal data? + +Realization: It's probably useful to know the fingerprints right away, to first go find the public key material, before calculating the hash of a huge file. ``` #### Verification From d47d9fdd5341303a1269355d1c688af43d34222d Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 14 Nov 2023 19:50:13 +0100 Subject: [PATCH 20/25] clarify --- book/source/07-signing_data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 787e9fc..335c7c6 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -113,7 +113,7 @@ r13/eqMN8kfCDw== -----END PGP SIGNATURE----- ``` -This signature is split into two parts: a message ("hello world") and an ASCII-armored OpenPGP signature. The message is immediately comprehensible to a human reader, while the signature block allows for the message's authenticity verification via OpenPGP software. +This signature consists of two parts: a message ("hello world") and an ASCII-armored OpenPGP signature. The message is immediately comprehensible to a human reader, while the signature block allows for the message's authenticity verification via OpenPGP software. #### Use case From 7ed65cc02ce884d6f41ebd23634c1a2389940307 Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Thu, 16 Nov 2023 09:48:07 +0100 Subject: [PATCH 21/25] make second-pass edits to ch7 --- book/source/07-signing_data.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 335c7c6..495dda4 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -6,7 +6,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0 (signing_data)= # Signatures over data -In OpenPGP, a *data signature* guarantees the authenticity and, implicitly, the integrity of certain data. Typical use cases include the authentication of software packages and emails. +In OpenPGP, a *data signature* guarantees the authenticity and, implicitly, the integrity of certain data. Typical use cases of data signatures include the authentication of software packages and emails. "Authenticity" in this context means that the data signature was issued by the entity controlling the signing key material. However, it does not automatically signal if the expected party indeed controls the signer certificate. OpenPGP does offer mechanisms for *strong authentication*, connecting certificates to specific identities. This verifies that the intended communication partner is indeed associated with the cryptographic identity behind the signature[^sign-auth]. @@ -23,7 +23,7 @@ Note that data signatures are distinct from {ref}`component_signatures_chapter`, OpenPGP data signatures use one of two [signature types](signature_types): - [**Binary signature**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-binary) (type ID `0x00`): This is the standard signature type for binary data and is typically used for files or data streams. Binary signatures are calculated over the data without any modifications or transformations. -- [**Text signature**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-of-a-canonical-te) (type ID `0x01`): Used for textual data, such as email bodies. When calculating a text signature, the data is first normalized by converting line endings into a canonical form (``). This mitigates issues caused by platform-specific text encodings, which is important for detached and cleartext signatures where the message file might be re-encoded between signature creation and verification. +- [**Text signature**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-of-a-canonical-te) (type ID `0x01`): Used for textual data, such as email bodies. When calculating a text signature, the data is first normalized by converting line endings into a canonical form (``). This approach mitigates issues caused by platform-specific text encodings. This is especially important for detached and cleartext signatures, where the message file might undergo re-encoding between the creation and verification of the signature. Data signatures are generated by hashing the message content along with the metadata in the OpenPGP signature packet, and calculating a cryptographic signature over that hash. The resulting cryptographic signature is stored in the signature packet. @@ -33,7 +33,7 @@ Data signature packets manifest in three distinct forms, which will be detailed OpenPGP data signatures can be applied in three distinct forms[^sign-modes-gpg]: -- **Detached**: The OpenPGP signature exists as a separate entity, independent from the signed data. +- **Detached**: The OpenPGP signature exists as a separate entity, independent of the signed data. - **Inline**: Both the original data and its corresponding OpenPGP signature are encapsulated within an OpenPGP container. - **Cleartext signature**: A plaintext message and its OpenPGP signature coexist in a combined text format, preserving the readability of the original message. @@ -63,7 +63,7 @@ An inline-signed OpenPGP message consists of three segments: #### Creation -To produce an inline signature, the signer processes the entirety of the data by reading from an input file and writing into an output OpenPGP message file. As the data is processed, the signer simultaneously calculates a cryptographic signature. This procedure results in a data signature packet being appended to the output OpenPGP message file, where it can be efficiently stored. +To produce an inline signature, the signer processes the entirety of the data by reading from an input file and writing into an output OpenPGP message file. As the data is processed, the signer simultaneously calculates a cryptographic signature. This procedure results in the appending of a data signature packet to the output OpenPGP message file, where it can be efficiently stored. For efficient verification, an application must understand how to handle the literal data prior to its reading. This requirement is addressed by the one-pass signature packets located at the beginning of inline-signed messages. These packets include essential information such as the fingerprint of the signing key and the hash algorithm used for computing the signature's hash digest. This setup enables the verifier to process the data correctly and efficiently. @@ -96,7 +96,7 @@ The *Cleartext Signature Framework* (CSF) in OpenPGP accomplishes two primary ob #### Example -Below is a detailed example of a {numref}`cleartext` signature: +The following is a detailed example of a {numref}`cleartext` signature: ```text -----BEGIN PGP SIGNED MESSAGE----- From 2f44224974bb92871191ff7ab0b3bebb28208e72 Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Thu, 16 Nov 2023 11:14:16 +0100 Subject: [PATCH 22/25] edit ch7 section on use case --- book/source/07-signing_data.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 495dda4..eada683 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -117,14 +117,15 @@ This signature consists of two parts: a message ("hello world") and an ASCII-arm #### Use case -Clear text signatures combine two of the benefits of detached and inline-signatures: +Clear text signatures combine the advantages of both detached and inline signatures: -- They are self-contained, the message and signature can be stored as a single file -- The message remains human-readable, without requiring additional software tooling +- **Self-contained format**: Cleartext signatures enable the message and its signature to be stored as a single file. -This combination can be attractive for processes where signed messages are handled in a partially manual manner, and stored in a system that doesn't have strong support for OpenPGP in that particular workflow[^arch-certifications]. +- **Human readability**: The message within a cleartext signature remains accessible in a plain text format. This eliminates the need for specialized software to read the message content. -[^arch-certifications]: For example, Arch Linux uses a workflow to certify User IDs of new packagers that relies on [cleartext signed statements by established 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 in an issue tracker system, as attachments, for later inspection. In this use case, it is convenient that the message and the signature are stored as one combined file (not as separate ones which would be more tedious to handle manually), and that the message is easy to read. Based on the vouches in these cleartext signed messages, and an [email confirmation by the new packager](https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/verify-a-packager-key), main signing key operators issue OpenPGP third-party certifications. +These features are particularly beneficial in scenarios where signed messages are managed semi-manually and where existing system infrastructure offers limited or no native support for OpenPGP in the workflow[^arch-certifications]. + +[^arch-certifications]: An illustrative example is the workflow adopted by Arch Linux to certify 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 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 OpenPGP third-party certifications. #### Text transformations for cleartext signatures From 58340c97a1e959e638f6a821ea0b985e177b69a1 Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Thu, 16 Nov 2023 11:57:46 +0100 Subject: [PATCH 23/25] edit ch7 cleartext transformations subsection --- book/source/07-signing_data.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index eada683..53fe87f 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -129,13 +129,15 @@ These features are particularly beneficial in scenarios where signed messages ar #### Text transformations for cleartext signatures -In the cleartext signature framework, the message text is normalized by [escaping dashes](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-dash-escaped-text), to prevent parsing problems where message content and armor headers are confused. +The cleartext signature framework includes specific text normalization procedures to ensure the integrity and clarity of the message: -Additionally, as usual for [text signatures](data_signature_types), the signature is calculated on the text with normalized line endings (``). +_ **Escaping dashes**: The framework implements a method of [dash-escaped text](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-dash-escaped-text) within the message. Dash-escaping ensures that the parser correctly distinguishes between the armor headers, which are part of the signature's structure, and any lines in the message that happen to start with a dash. + +- **Normalization of line endings**: Consistent with the approach for binary [text signatures](data_signature_types), the cleartext signature is calculated on the text with normalized line endings (``). This ensures that the signature remains valid regardless of the text format of the receiving implementation. #### Pitfalls -While widely used, cleartext signatures are sometimes considered a "legacy method"[^csf-gnupg]. The RFC outlines [pitfalls of cleartext signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-issues-with-the-cleartext-s) and advises that inline and detached signature forms are often preferable. +While widely used, cleartext signatures are sometimes viewed as a "legacy method"[^csf-gnupg]. The RFC outlines [pitfalls of cleartext signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-issues-with-the-cleartext-s) and advises that inline and detached signature forms are often preferable. [^csf-gnupg]: https://lists.gnupg.org/pipermail/gnupg-devel/2023-November/035428.html From 32b5e0cfe0939c82d0d9087d742a82939d3d80d4 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 15 Nov 2023 19:11:59 +0100 Subject: [PATCH 24/25] Align wording with https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/354/diffs --- book/source/07-signing_data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 53fe87f..4d373d5 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -133,7 +133,7 @@ The cleartext signature framework includes specific text normalization procedure _ **Escaping dashes**: The framework implements a method of [dash-escaped text](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-dash-escaped-text) within the message. Dash-escaping ensures that the parser correctly distinguishes between the armor headers, which are part of the signature's structure, and any lines in the message that happen to start with a dash. -- **Normalization of line endings**: Consistent with the approach for binary [text signatures](data_signature_types), the cleartext signature is calculated on the text with normalized line endings (``). This ensures that the signature remains valid regardless of the text format of the receiving implementation. +- **Normalization of line endings**: Consistent with the approach for any other [text signature](data_signature_types), a cleartext signature is calculated on the text with normalized line endings (``). This ensures that the signature remains valid regardless of the text format of the receiving implementation. #### Pitfalls From 1b1e918a0190e23acdec0bd94949b91dd68e5d3a Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Thu, 16 Nov 2023 15:16:05 +0100 Subject: [PATCH 25/25] add detail to ch7 pitfalls section of cleartext signatures --- book/source/07-signing_data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/07-signing_data.md b/book/source/07-signing_data.md index 4d373d5..5163be4 100644 --- a/book/source/07-signing_data.md +++ b/book/source/07-signing_data.md @@ -137,7 +137,7 @@ _ **Escaping dashes**: The framework implements a method of [dash-escaped text]( #### Pitfalls -While widely used, cleartext signatures are sometimes viewed as a "legacy method"[^csf-gnupg]. The RFC outlines [pitfalls of cleartext signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-issues-with-the-cleartext-s) and advises that inline and detached signature forms are often preferable. +Despite their widespread adoption, cleartext signatures have their limitations and are sometimes viewed as a "legacy method"[^csf-gnupg]. The 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 inline and detached signature forms are advised. [^csf-gnupg]: https://lists.gnupg.org/pipermail/gnupg-devel/2023-November/035428.html