vanitasvitae
/
openpgp-notes
mirror of https://codeberg.org/openpgp/notes.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add some more context to prefixed signed format

This commit is contained in:
Heiko Schaefer 2023-12-28 04:13:27 +01:00
parent fcab56b666
commit 096efc3635
No known key found for this signature in database
GPG Key ID: DAE9A9050FCCF1EB
1 changed files with 9 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
book/source/adv/signing_data.md
View File

@ -146,6 +146,8 @@ By contrast, a message, where the signer attests an already signed message has t
A {term}`prefixed signed message` consists of {term}`signature packet(s)<signature packet>` followed by the message. For the verifier, processing one-pass signed and prefixed signed messages are equally convenient. However, on the signer's side, it takes more resources to generate a {term}`prefixed signed message`.
This is a legacy format. Not all modern implementations support. However, for example, GnuPG 2.4.x can validate messages with this signature format.
#### Structure
In this format, the signature packets are stored ahead of the message itself:
@ -163,7 +165,13 @@ Structure of a prefixed signed message.
Compared to a {term}`one-pass signed message`, there are no {term}`one-pass signature packets<One-pass Signature Packet>` in this format, and the (otherwise equivalent) {term}`signature packet(s)<signature packet>` are stored ahead of the signed data.
For verification, this is equally convenient as the one-pass signed message form.
```{note}
Even when a prefixed signed message contains multiple signature packets, each signature packet contains an independent signature of just the message payload. Signatures do not include subsequent signatures in their hashes, every signature is only over the raw payload data of the message.
```
#### Format is inefficient for the signer
For verification, this format 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: