ch9: initial stab at splitting out "advanced" material

book/source/09-verification.md

@@ -32,7 +32,7 @@ The validity of a correct signature is additionally constrained by a number of c
 
 [^unknown-critical]: Note that this implies that a signature might be considered valid by one implementation and be rejected by another, based on the set of subpackets and notations each implementation is aware of.
 
-### Well-formedness of signatures
+## Well-formedness of signatures
 
 There are a number of criteria that a signature must fulfill to be considered well-formed:
 
@@ -44,7 +44,7 @@ There are a number of criteria that a signature must fulfill to be considered we
 - The same applies to notations. Unknown notations that are marked as critical render the signature malformed.
 
 (temporal-validity)=
-### Temporal validity
+## Temporal validity
 
 A signature is valid only for a constrained period of time:
 
@@ -62,7 +62,7 @@ For the signature to qualify as valid, it needs to be in effect. In other words,
 
 The same reference time must be used when verifying required qualifying signatures, if any.
 
-### Self-qualifying and non-self-qualifying signatures
+## Self-qualifying and non-self-qualifying signatures
 
 Some signatures can be verified on their own, while others require the verification of additional signatures on the issuer certificate. We will call the former category *self-qualifying* signatures.
 
@@ -85,7 +85,7 @@ Examples for signatures which are not self-qualifying are:
   - third-party certification (`0x10`-`0x13`), or
   - third-party certification revocation signatures (`0x30`).
 
-### Signature qualification
+## Signature qualification
 
 To verify non-self-qualifying signatures, it is necessary to look at more than just the signature itself.
 
@@ -110,6 +110,21 @@ On the other hand, to verify a data signature over a text document, an implement
 Tree of signatures that qualify a data signature
 ```
 
+## Revocations
+
+A signature can be *disqualified* by the presence of a revocation signature.
+
+Revocations can be limited in scope, e.g., a subkey-revocation signature only revokes a single subkey.
+Moreover, revocations can also be constrained to a certain validity period by including a soft revocation reason and expiration time in the revocation signature.
+
+```{admonition} TODO
+:class: warning
+
+Give guidance which revocations need to be considered for different types of signatures
+```
+
+## Advanced topics
+
 ### Attribute shadowing
 
 When determining the preferences of a key, several signatures may have to be inspected.
@@ -169,20 +184,7 @@ As attribute and signature shadowing can occur in combination, it is not always
 Signatures shadow one another, based on reference time.
 ```
 
-### Revocations
+### Which signatures take precedence?
-
-A signature can be *disqualified* by the presence of a revocation signature.
-
-Revocations can be limited in scope, e.g., a subkey-revocation signature only revokes a single subkey.
-Moreover, revocations can also be constrained to a certain validity period by including a soft revocation reason and expiration time in the revocation signature.
-
-```{admonition} TODO
-:class: warning
-
-Give guidance which revocations need to be considered for different types of signatures
-```
-
-## Which signatures take precedence?
 
 Multiple signatures can be attached to an OpenPGP certificate or component. These signatures can contain conflicting information.
 
@@ -237,7 +239,7 @@ For each certificate, there is at most one "active" direct key signature, for ea
 direct key signatures can be revoked, [canceling them](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.2.3.10-4), meaning an older direct-key signature might become active again? The text of the spec is confusing here.
 ```
 
-## Complexity of the packet format
+### Complexity of the packet format
 
 OpenPGP certificates can contain complex preference settings. Additionally, the OpenPGP packet format allows a lot of flexibility when storing certificates in TPK format.