From eec47a64013100d1547e041ab1030a3115f008a1 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 27 Dec 2023 03:40:21 +0100 Subject: [PATCH] Simplify "nesting" section --- book/source/adv/signing_data.md | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/book/source/adv/signing_data.md b/book/source/adv/signing_data.md index 4082a64..6a75d40 100644 --- a/book/source/adv/signing_data.md +++ b/book/source/adv/signing_data.md @@ -96,25 +96,19 @@ Important to note, the {term}`signer`'s {term}`public key`, A {term}`one-pass signed message` can contain multiple signatures. -There are two subtly different use cases for this: - -- Multiple signers can issue cryptographic signatures that can be stored in one shared (and thus space-efficient) inline signed message. In this case, each signer makes a cryptographic statement about just the signed message. The individual signatures are independent of each other. -- Alternatively, a later signer can sign not just the input message, but also include a previous signature in their signature. In this case, the second signer notarizes the previous signer's signature combined with the signed message. - ```{note} One-pass signatures are nested. The outermost one-pass signature packet corresponds to the outermost signature packet. ``` -There is one exception, though. -```{note} -Of course there is. -``` +There are two subtly different use cases for inline signatures that contain multiple signatures: + +- Multiple signers can issue cryptographic signatures that can be stored in one shared (and thus space-efficient) inline signed message. In this case, each signer makes a cryptographic statement about just the signed message. The individual signatures are independent of each other. +- Alternatively, a later signer can sign not just the input message, but also include a previous signature in their signature. In this case, the second signer attests the previous signer's signature combined with the signed message. + +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`. -The OPS packet has a "nested" flag[^nested-flag], which can either be `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. -[^nested-flag]: See [description of the nested flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.4-3.8.1). - This mechanism enables attested signatures, where the signer signs an already one-pass signed message including the already contained signature. As a practical example, consider the following notation: