vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2024-11-21 23:22:05 +01:00
Code Issues Projects Releases Packages Wiki Activity

Move away from using "plaintext" to refer to signed data

Browse source
This commit is contained in:
Heiko Schaefer 2023-12-27 03:50:43 +01:00
parent eec47a6401
commit fda7264f10
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -107,7 +107,7 @@ There are two subtly different use cases for inline signatures that contain mult
To specify which of these two functions a signature performs, the {term}`one-pass signature packet` has a ["nested" flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.4-3.8.1), with a value of either `1` or `0`. To specify which of these two functions a signature performs, the {term}`one-pass signature packet` has a ["nested" flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.4-3.8.1), with a value of either `1` or `0`.
If this flag is set to `0`, it indicates that further OPSs will follow this packet, which are calculated over the same plaintext data as this OPS is. A value of `1` indicates, that either no further OPS packets will follow (this OPS is the last), or that this OPS is calculated over the usual plaintext data, but wrapped inside any OPS+Signature combinations that follow this OPS. If the "nested" flag is set to `0`, it indicates that further OPSs will follow this packet, which are calculated over the same message payload data as this OPS is. A value of `1` indicates, that either no further OPS packets will follow (this OPS is the last), or that this OPS is calculated over the usual message payload data, but wrapped inside any OPS+Signature combinations that follow this OPS.
This mechanism enables attested signatures, where the signer signs an already one-pass signed message including the already contained signature. This mechanism enables attested signatures, where the signer signs an already one-pass signed message including the already contained signature.
@ -120,17 +120,17 @@ As a practical example, consider the following notation:
A normal, one-pass signed message looks like this: A normal, one-pass signed message looks like this:
`OPS₁ LIT("Hello World") SIG` `OPS₁ LIT("Hello World") SIG`
Here, the signature is calculated over the plaintext `Hello World`, as is it in a message that has the following form: `OPS₁ COMP(LIT("Hello World")) SIG`. Here, the signature is calculated over the payload `Hello World`. The signature doesn't change if the signed message is instead stored as: `OPS₁ COMP(LIT("Hello World")) SIG` (also see [](hashing-inline-data)).
A message, where multiple one-pass signatures are calculated over the same plaintext looks the following: A message, where multiple one-pass signatures are calculated over the same payload looks the following:
`OPS₀ OPS₀ OPS₁ LIT("Hello World") SIG SIG SIG` `OPS₀ OPS₀ OPS₁ LIT("Hello World") SIG SIG SIG`
All three signatures are calculated over the same plaintext `Hello World`. All three signatures are calculated over the same payload `Hello World`.
Now, a message, where the signer attests an already signed message has the following format: Now, a message, where the signer attests an already signed message has the following format:
`OPS₁ OPS₁ LIT("Hello World") SIG SIG` `OPS₁ OPS₁ LIT("Hello World") SIG SIG`
While the inner signature is calculated over the usual plaintext `Hello World`, the outer signature is instead calculated over `OPS₁ Hello World SIG`. While the inner signature is calculated over the usual payload `Hello World`, the outer signature is instead calculated over `OPS₁ Hello World SIG`.
(prefixed-signature)= (prefixed-signature)=
### Prefixed signed message ### Prefixed signed message