From 864ed59a645611089d90514fe1e3d4c92ade1457 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 19 Dec 2023 13:27:04 +0100 Subject: [PATCH] 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