mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-25 17:12:06 +01:00
Structure: separate sections for One-pass-signed and Prefixed-signed messages
This commit is contained in:
parent
16c6d0c265
commit
7ef91f4d05
1 changed files with 25 additions and 8 deletions
|
@ -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<Inline Signature>`.
|
This method is commonly used for signing or encrypting emails. Most email software capable of handling OpenPGP communications typically uses {term}`inline signatures<Inline Signature>`.
|
||||||
|
|
||||||
#### 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<One-pass-signed Message>`** are signed using one or more {term}`one-pass signatures<One-pass Signature Packet>`
|
||||||
|
2. **{term}`Prefixed-signed messages<Prefixed-signed Message>`** have the actual signature(s) prefixed to the {term}`OpenPGP message<OpenPGP Message>`.
|
||||||
|
|
||||||
* {term}`One-pass-signed messages<One-pass-signed Message>` are signed using one or more {term}`one-pass signatures<One-pass Signature Packet>`
|
While the latter is conceptually slightly simpler, it has no strong benefits over {term}`one-pass-signed messages<One-pass-signed Message>` and is rarely used.
|
||||||
* {term}`Prefixed-signed messages<Prefixed-signed Message>` have the actual signature(s) prefixed to the {term}`OpenPGP message<OpenPGP Message>`.
|
|
||||||
|
#### One-pass-signed message
|
||||||
|
|
||||||
|
##### Structure
|
||||||
|
|
||||||
A {term}`one-pass-signed<One-pass-signed Message>` {term}`OpenPGP message` consists of three segments:
|
A {term}`one-pass-signed<One-pass-signed Message>` {term}`OpenPGP message` consists of three segments:
|
||||||
|
|
||||||
|
@ -67,9 +71,7 @@ A {term}`one-pass-signed<One-pass-signed Message>` {term}`OpenPGP message` consi
|
||||||
|
|
||||||
3. **{term}`Data signature packets<OpenPGP Signature Packet>`**: These contain the {term}`cryptographic signature` corresponding to the original data.
|
3. **{term}`Data signature packets<OpenPGP Signature Packet>`**: These contain the {term}`cryptographic signature` corresponding to the original data.
|
||||||
|
|
||||||
Less commonly used are {term}`prefixed-signed messages<Prefixed-signed Message>`, where the {term}`signature packet(s)<signature packet>` 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.
|
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.
|
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<Inline Signature>` messages enable efficient {term}`verification` in *one pass*, structured as follows:
|
{term}`Inline-signed<Inline Signature>` 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<OpenPGP Certificate>`, 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<OpenPGP Signature Packet>` successfully.
|
Important to note, the {term}`signer`'s {term}`public key<OpenPGP Certificate>`, 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<OpenPGP Signature Packet>` 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)<signature packet>` 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<OpenPGP Signature Packet>`**: 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-signature)=
|
||||||
### Cleartext signatures
|
### Cleartext signatures
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue