fix header level

book/source/adv/certificates.md

@@ -170,68 +170,33 @@ This variance underscores the importance of understanding your specific GnuPG co
 
 [^gpg-default-strip]: GnuPG's changes in the default handling of third-party certifications on imports were prompted by the 2019 [keyserver flooding event](https://dev.gnupg.org/T4607#127792).
 
-### Limitations that can result from stripping historical self-signatures
+## Minimization for email: Use cases and considerations
 
-Some implementations, such as Sequoia, prefer to rely on the full historical set of self-signatures to construct a view of the certificate over time. This way, signatures can be verified at different reference times. In this model, removing superseded self-signatures can cause problems with the validation of historical signature.
+Certificate minimization plays a critical role in email communications. By reducing certificate size, email clients can improve performance and enhance security. However, certificate minimization strategies may vary, depending on the use case and with consideration given to the balance between usability and security.
 
-An example for the tension between minimization and nuanced verification of the [temporal validity](temporal-validity) of signatures can be seen in the case of rpm-sequoia. See [this discussion](https://github.com/rpm-software-management/rpm-sequoia/issues/50#issuecomment-1689642607) for details:
+The approach adopted by [Autocrypt](https://autocrypt.org/) aims to simplify end-to-end encryption for emails by automatically negotiating encryption capabilities. Autocrypt Level 1 specifies a [minimal format for OpenPGP certificates](https://autocrypt.org/level1.html#openpgp-based-key-data) that are distributed by the autocrypt mechanism in mail headers, emphasizing the importance of keeping certificates small for efficient email communication. An essential practice within the Autocrypt framework is the on-demand generation of minimized certificate views. For instance, when an email is sent or composed, an Autocrypt header is constructed with a freshly minimized version of the sender's certificate. This ensures that the certificate data embedded in the email is both current and optimized for the specific communication context. The receiving end is then expected to merge this data with any locally available information, maintaining a comprehensive and up-to-date view of the certificate. 
 
-Initially, when checking the validity of a data signature for a software package, `rpm-sequoia` used the signature's creation time as the reference time. However, the availability of historical self-signatures in certificates is limited. So sometimes only a more recent self-signature for the primary key is available, and there is no evidence that the primary key was valid at the reference time.
+Proton Mail, a secure email service, exemplifies certificate minimization by selectively fetching only the necessary OpenPGP certificates via Web Key Directory (WKD) when composing a message. This targeted approach ensures that only essential component keys are used, omitting components like invalid subkeys, authentication subkeys not relevant to email encryption, superseded self-signatures, and third-party certifications. With many real-world certificates, the space savings of such a minimization are significant[^space-example].
 
-To deal with this reality, the rpm-sequoia implementation was adjusted to accept data signatures that predate the validity of the current primary key self-signature[^primary-self-sig].
+The examples of Autocrypt and Proton Mail illustrate the advantages of certificate minimization in email communications. However, these examples also highlight several challenges:
 
-[^primary-self-sig]: Which in OpenPGP version 4 is often a primary User ID binding signature.
+- **Balance between security and usability:** Minimizing certificates must carefully balance security concerns with usability. Overly aggressive minimization might omit crucial information necessary for verifying the authenticity of a message.
+- **Historical signature verification:** The removal of historical self-signatures can complicate the verification of signatures at different reference times, potentially impacting the trustworthiness of the certificate. For an example, see [this discussion](https://github.com/rpm-software-management/rpm-sequoia/issues/50#issuecomment-1689642607) of [temporal validity](temporal-validity) in the case of`rpm-sequoia`.
+- **Dynamic certificate views:** Minimization strategies need to account for the dynamic nature of certificates, where updates and changes are frequent. This requires a thoughtful approach to ensure that minimized certificates remain current and valid.
 
-### Autocrypt
+Moreover, while pursuing certificate minimization for email, it's essential to balance the reduction in size with the preservation of the OpenPGP trust framework. Adequate information must be retained within the certificate to allow users to verify its authenticity and integrity, ensuring that the minimization process does not impede the ability to establish trust through the Web of Trust mechanism.
 
-The [Autocrypt](https://autocrypt.org/) project describes itself as:
+Overall, certificate minimization for email presents a promising approach to enhancing email security and performance. However, it requires discernment and careful implementation to navigate the inherent trade-offs between minimizing certificate size and maintaining the integrity and trustworthiness of email communications.
 
-> [..] a set of guidelines for developers to achieve convenient end-to-end-encryption of e-mails. It specifies how e-mail programs negotiate encryption capabilities using regular e-mails.
+[^space-example]: This example demonstrates how to minimize a certificate using GnuPG commands, targeting only relevant components:
 
-The Autocrypt Level 1 specification defines a specific [minimal format for OpenPGP certificates](https://autocrypt.org/level1.html#openpgp-based-key-data) that are distributed by the autocrypt mechanism.
+```sh
+gpg --export-options export-minimal,export-clean,no-export-attributes \
+    --export-filter keep-uid=mbox=wiktor@metacode.biz \
+    --export-filter 'drop-subkey=expired -t || revoked -t || usage =~ a' \
+    --export wiktor@metacode.biz
 
-One goal of the Autocrypt mechanism is to distribute certificates widely. To this end, Autocrypt sends certificates in mail headers, where smaller size is greatly preferable.
-
-Basic encrypted email functionality requires only a small subset of the recipient's certificate, so small certificate size is feasible.
-
-### Minimization for email
-
-Note that minimization of certificates isn't generally "right" or "wrong." The benefit or harm depends on the context.
-
-For example, we might consider minimizing a certificate for distribution via WKD, with the use-case of email in mind.
-
-Many certificates can be significantly pruned if the only goal of distributing them is to enable encryption and signature verification. For such cases, many components can be dropped, including invalid subkeys and their binding signatures, authentication subkeys (which are irrelevant to email), shadowed self-signatures, and third-party certifications. With many real-world certificates, the space savings of such a minimization are significant[^space-example].
-
-Such minimization might be appropriate and convenient to enable encrypted communication with a Proton Mail client, which automatically fetches OpenPGP certificates via WKD while composing a message. The Proton Mail use case requires only component keys, not third-party certifications, and it doesn't require historical component keys or self-signatures.
-
-However, in a different context, the same certificate might be fetched to verify the authenticity of a signature. In that case, third-party certifications may be crucial for the client. Stripping them could prevent the client from performing Web of Trust calculations and validating the authenticity of the certificate.
-
-[^space-example]: The following fragment processes an example certificate. It drops any subkey that is not valid at the time of export (because of revocation or expiration), authentication subkeys, and any third-party certifications:
-
-    ```sh
-    gpg --export-options export-minimal,export-clean,no-export-attributes \
-        --export-filter keep-uid=mbox=wiktor@metacode.biz \
-        --export-filter 'drop-subkey=expired -t || revoked -t || usage =~ a' \
-        --export wiktor@metacode.biz
-    ```
-
-    At the time of writing, the original certificate consists of 152322 bytes of data. The filtered variant consists of only 3771 bytes, which is 40x smaller. In some contexts, there are hard constraints on size, and minimization is unavoidable, e.g., when embedding certificate data in email headers.
-
-### Pitfalls of minimization
-
-Disadvantages/risks of minimizing certificates:
-
-- A minimized certificate does not present a full view of how it (and the validity of its components) evolved over time.
-- As the OpenPGP subsystem on a user's computer learns about more certificates, third-party certifications that were previously unusable may become usable. Dropping third-party certifications by unknown issuers as a part of minimization prevents this mechanism.
-- An OpenPGP implementation that minimizes a certificate might remove component keys that it cannot use itself (e.g. because it doesn't support the algorithm of that key), even if the *receiving* implementation supports them.
-- Refreshing certificates from key servers may inflate the certificate again, since OpenPGP certificates tend to act as [append-only structures](append-only).
-- Some libraries, such as [anonaddy-sequoia](https://gitlab.com/willbrowning/anonaddy-sequoia/-/blob/master/src/sequoia.rs?ref_type=heads#L125) strip unusable encryption subkeys, but retain at least one subkey, even if all subkeys are expired. Although this may leave only an expired encryption subkey in the certificate, this presents a better UX for the end user who potentially is still in possession of the private key for decryption.
-
-### Guidelines
-
-1. Don't minimize certificates unless you have a good reason to.
-2. When minimizing a certificate, minimize it in a way that suites your use-case. E.g., when minimizing a certificate for distribution alongside a signed software packet, make sure to include enough historical self-signatures as to not break the verification of the signed packet.
-3. When presenting a minimized view of a certificate to a consumer, consider when that a new version of that view needs to be generated. Ideally, minimized certificates are freshly generated on demand (e.g., an Autocrypt header is constructed while an email is sent or composed). The receiver is expected to typically merge all data it sees locally.
+The process significantly reduces the certificate size from 152,322 bytes to just 3,771 bytes, demonstrating a substantial decrease in size by over 40 times. Such minimization is particularly crucial in contexts with strict size limitations, like embedding certificate data in email headers.
 
 ## Fingerprints and beyond: "Naming" certificates in user-facing contexts