ch4: restructure "advanced" section

book/source/04-certificates.md

@@ -305,18 +305,29 @@ The popular [SKS keyserver network experienced certificate flooding firsthand](h
 
 ## Advanced topics
 
+(append-only)=
+### Certificates are effectively "append only" data structures
+
 ```{admonition} TODO
 :class: warning
 
-This section only contains notes and still needs to be written
+- write
+- find places in the text that should link to this section (this concept has been hinted at in more than one place, i think)
 ```
 
 (append-only)=
-### Certificate management / Evolution of a certificate over time
+### Merging
 
-Minimized versions, merging, effective "append only" semantics, ...
+- How to merge two copies of the same certificate?
+- Canonicalization
 
-#### Certificate minimization
+```{admonition} TODO
+:class: warning
+
+write
+```
+
+### Certificate minimization
 
 Certificate minimization is a practice of presenting partial view of a certificate by filtering out selected components.
 
@@ -325,7 +336,7 @@ Stripping some components has several benefits:
   - in some contexts it's clear that the entire certificate is not necessary to facilitate some workflows, for example e-mail clients require only encryption, signing and certifying component keys and they don't need authentication subkeys that are used for SSH connections,
   - sometimes the certificate grows naturally so big that the user software [has problems handing it](https://www.reddit.com/r/GnuPG/comments/bp23p4/my_key_is_too_large/).
 
-##### Implementations
+#### Implementations
 
 GnuPG is [stripping signatures on key import](https://dev.gnupg.org/T4607#127792).
 
@@ -340,7 +351,7 @@ Besides that GnuPG also offers two ways of cert minimization, described [in thei
 
 Some libraries, such as Sequoia, depend on old self-signatures as they construct a view of the certificate in the past, when the signature was allegedly created. This can cause problems with signature verification as [reported in rpm-sequoia ticket](https://github.com/rpm-software-management/rpm-sequoia/issues/50#issuecomment-1689642607) where Sequoia ultimately would revert back to GnuPG-specific approach.
 
-##### Autocrypt/WKD minimization
+#### Autocrypt/WKD minimization
 
 E-mail clients depend only on a limited subset of components of the certificate, thus it's possible to construct a smaller key that will be easier to transfer buy mail user-agents.
 
@@ -354,7 +365,7 @@ At the time of writing this exported key has exactly 3771 bytes which is signifi
 
 Note that in some contexts it's not clear if minimization brings more benefit than harm. Consider ProtonMail client which fetches OpenPGP certificates via WKD automatically when composing a message. It needs only subkeys. But if the same key is fetched as part of automatic signature verification then stripping certifications and leaving only subkeys would prevent the client from performing Web of Trust calculations and authenticating the certificate.
 
-##### Pitfalls of minimization
+#### Pitfalls of minimization
 
 Disadvantages of minimized certificates:
   - does not present full view on how the certificate evolved,
@@ -363,7 +374,7 @@ Disadvantages of minimized certificates:
   - refreshing keys from keyservers will inflate the key again since OpenPGP certificates are append-only structures,
   - carelessly stripping all invalid components may make the key unusable. Some libraries, such as [anonaddy-sequoia](https://gitlab.com/willbrowning/anonaddy-sequoia/-/blob/master/src/sequoia.rs?ref_type=heads#L125) strip all unusable encryption subkeys unless it leaves the key with no encryption subkeys. In this case at least one subkey is left. Even though it may be expired it presents a better UX for the end-user who probably is still in possesion of the private key for decryption.
 
-##### Guidelines
+#### Guidelines
 
 1. Don't minimize certificates unless you have a good reason to
 2. If presenting minimzied certificate view consider when it needs updates. In the best case the certificate would be minimized on demand (e.g. Autocrypt header constructed when the e-mail is sent or composed) and the client would merge all data collected.
@@ -378,19 +389,18 @@ In v4, a 20 byte fingerprint in hex representation was used to name certificates
 For v6, this type of approach is discouraged, but a replacement mechanism is still pending.
 ```
 
-### Merging
-
-- How to merge two copies of the same certificate?
-- Canonicalization
-
-### How to generate "minimized" certificate?
-
 ### When are certificates valid?
 
 - Full certificate: Primary revoked/key expired/binding signature expired,
 - Subkey: Revoked/key expired/binding signature expired
 - User ID: revoked, binding expired, ...
 
+```{admonition} TODO
+:class: warning
+
+write, link to chapter 9
+```
+
 ### Best practices regarding Key Freshness
 
 ```{admonition} TODO
@@ -412,6 +422,12 @@ write
 
 ### Metadata leak of Social Graph
 
+```{admonition} TODO
+:class: warning
+
+write
+```
+
 (unbound_user_ids)=
 ### Adding unbound User IDs to a certificate