Partially flatten section hierarchy for less depth

book/source/signing_data.md

@@ -39,14 +39,14 @@ Note that {term}`data signatures<Data Signature>` are distinct from [](/signing_
 
 [^sign-modes-gpg]: These three forms of {term}`signature<OpenPGP Signature Packet>` application align with GnuPG's `--detach-sign`, `--sign`, and `--clearsign` command options.
 
-### Detached signatures
+## Detached signatures
 
 A {term}`detached signature` is produced by calculating an {term}`OpenPGP signature<OpenPGP Signature Packet>` over the data intended for signing. The original data remains unchanged, and the {term}`OpenPGP signature<OpenPGP Signature Packet>` is stored as a standalone file. A {term}`detached signature` file can be distributed alongside or independent of the original data. The {term}`authenticity<Authentication>` and integrity of the original data file can be {term}`verified<Verification>` by using the {term}`detached signature` file.
 
 This {term}`signature<OpenPGP Signature Packet>` format is especially useful for signing software releases and other files where it is imperative that the content remains unaltered during the signing process.
 
 (inline-signature)=
-### Inline signatures
+## Inline signatures
 
 An {term}`inline signature` joins the signed data and its corresponding {term}`data signature` into a single {term}`OpenPGP message`.
 
@@ -59,9 +59,9 @@ OpenPGP defines two different forms of inline-signed messages:
 
 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. 
 
-#### One-pass-signed message
+### One-pass-signed message
 
-##### Structure
+#### Structure
 
 A {term}`one-pass-signed<One-pass-signed Message>` {term}`OpenPGP message` consists of three segments:
 
@@ -77,7 +77,7 @@ Despite its name, a {term}`one-pass signature packet` is not a type of {term}`si
 Instead, it's a type of auxiliary packet that can be used in conjunction with {term}`signature packets<OpenPGP Signature Packet>`. Its use allows storing the {term}`signature packets<OpenPGP Signature Packet>` after the message body. 
 ```
 
-##### 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.
 
@@ -85,7 +85,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.
 
-##### Verification
+#### Verification
 
 {term}`Inline-signed<Inline Signature>` messages enable efficient {term}`verification` in *one pass*, structured as follows:
 
@@ -97,14 +97,14 @@ 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. 
 
-#### Prefixed-signed message
+### 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
+#### Structure
 
 1. **{term}`Data signature packets<OpenPGP Signature Packet>`**: These contain the {term}`cryptographic signature` corresponding to the original data.
 
@@ -113,14 +113,14 @@ Especially for longer messages, it takes a bit more work to generate an inline s
 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 signatures
+## Cleartext signatures
 
 The *{term}`Cleartext Signature Framework`* (CSF) in OpenPGP accomplishes two primary objectives:
 
 - maintaining the message in a human-readable cleartext format, accessible without OpenPGP-specific software
 - incorporating an {term}`OpenPGP signature<OpenPGP Signature Packet>` for {term}`authentication` by users with OpenPGP-compatible software
 
-#### Example
+### Example
 
 The following is a detailed example of a {numref}`cleartext` signature:
 
@@ -141,7 +141,7 @@ r13/eqMN8kfCDw==
 
 This {term}`signature<Cleartext Signature>` consists of two parts: a message ("hello world") and an ASCII-armored {term}`OpenPGP signature<OpenPGP Signature Packet>`. The message is immediately comprehensible to a human reader, while the {term}`signature<OpenPGP Signature Packet>` block allows for the message's {term}`authenticity<Authentication>` {term}`verification` via OpenPGP software.
 
-#### Use case
+### Use case
 
 {term}`Cleartext signatures<Cleartext Signature>` combine the advantages of both {term}`detached<Detached Signature>` and {term}`inline signatures<Inline Signature>`:
 
@@ -153,7 +153,7 @@ These features are particularly beneficial in scenarios where signed messages ar
 
 [^arch-certifications]: An illustrative example is the workflow adopted by Arch Linux to {term}`certify<Certification>` {term}`User IDs<User ID>` of new packagers. This process relies on [cleartext signed statements from existing packagers](https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/blob/master/.gitlab/issue_templates/New%20Packager%20Key.md?ref_type=heads&plain=1#L33-46). These signed statements are stored as attachments in an issue tracking system for later inspection. The advantage of this approach lies in the convenience of having the message and signature in a single file, which simplifies manual handling. Based on the vouches in these {term}`cleartext signed<Cleartext Signature>` messages and an [email confirmation from the new packager](https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/verify-a-packager-key), the main key operators can issue {term}`OpenPGP third-party certifications<Third-party Identity Certification>`.
 
-#### Text transformations for cleartext signatures
+### Text transformations for cleartext signatures
 
 The {term}`cleartext signature framework` includes specific text normalization procedures to ensure the integrity and clarity of the message:
 
@@ -161,7 +161,7 @@ The {term}`cleartext signature framework` includes specific text normalization p
 
 - **Normalization of line endings**: Consistent with the approach for any other [text signature](data-signature-types), a {term}`cleartext signature` is calculated on the text with normalized line endings (`<CR><LF>`). This ensures that the {term}`signature<OpenPGP Signature Packet>` remains valid regardless of the text format of the receiving {term}`implementation<OpenPGP Implementation>`.
 
-#### Pitfalls
+### Pitfalls
 
 Despite their widespread adoption, {term}`cleartext signatures<Cleartext Signature>` have their limitations and are sometimes viewed as a "legacy method"[^csf-gnupg]. The {term}`RFC` details the [pitfalls of cleartext signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-issues-with-the-cleartext-s), such as incompatibility with semantically meaningful whitespace, challenges with large messages, and security vulnerabilities related to misleading Hash header manipulations. Given these issues, safer alternatives like {term}`inline<Inline Signature>` and {term}`detached signature` forms are advised.