ch4: flatten section structure

(And remove todo that was moved to ch6)

book/source/04-certificates.md

@@ -46,7 +46,7 @@ All elements in an OpenPGP certificate are structured around one central compone
 OpenPGP certificates are typically long-lived and may be changed (typically by their owner), over time. Components can be added and invalidated, over the lifetime of a certificate
 ```
 
-### OpenPGP component keys
+## Component keys
 
 An OpenPGP certificate usually contains multiple OpenPGP component keys.
 
@@ -61,7 +61,7 @@ An OpenPGP component key
 
 Component key representations that include private key material also contain metadata that specifies the password protection scheme for the private key material. However, in this chapter, we're looking at *OpenPGP certificates*, which *don't* contain private key information. Each component key of such a certificate contains only the public part of its cryptographic key data. To read more about private keys in OpenPGP, see {numref}`private_key_chapter`.
 
-#### Fingerprint
+### Fingerprint
 
 For each OpenPGP component key, an *OpenPGP fingerprint* can be derived from the combination of the public key material and creation timestamp (and ECDH parameters, if applicable).
 
@@ -78,7 +78,7 @@ Historically, even shorter 32 bit identifiers have sometimes been used, like thi
 
 Component keys are used in one of two roles: either as "OpenPGP primary key," or as an "OpenPGP subkey".
 
-#### Primary key
+### Primary key
 
 The "OpenPGP primary key" is a component key that serves a central role in an OpenPGP certificate:
 
@@ -93,7 +93,7 @@ The validity of the primary key limits its capacity to confer validity to other
 In the RFC, the OpenPGP primary key is also sometimes referred to as "top-level key." It has also sometimes informally been called "master key."
 ```
 
-#### Subkeys
+### Subkeys
 
 In addition to the primary key, modern OpenPGP certificates usually contain a number of "subkeys" (however, it's not technically necessary for a certificate to contain subkeys).
 
@@ -106,7 +106,7 @@ Subkeys have the same structure as the primary key, but they are used in a diffe
 OpenPGP certificates can contain a number of subkeys
 ```
 
-#### Key flags: defining which operations a component key can perform
+### Key flags: defining which operations a component key can perform
 
 Each component key has a set of ["Key Flags"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#key-flags) that specify which operations that key can perform.
 
@@ -126,7 +126,7 @@ It is considered good practice to have separate component keys for each type of
 
 [^key-flag-sharing]: With ECC algorithms, it's actually not possible to share encryption functionality with the signing-based functionalities, e.g.: ed25519 used for signing; cv25519 used for encryption.
 
-#### Component key metadata, including key flags
+### Component key metadata, including key flags
 
 The key flags for a component key are actually not defined *inside* that component key itself.
 
@@ -137,11 +137,11 @@ Instead, key flags, together with other metadata about that component key (such
 
 
 (identity_components)=
-### Identity components
+## Identity components
 
 Identity components in an OpenPGP certificate are used by the certificate holder to state that they are known by a certain identifier (like a name, or an email address).
 
-#### User IDs
+### User IDs
 
 An OpenPGP certificate can contain any number of [User IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-id-packet-tag-13). Each User ID associates the certificate with an identity.
 
@@ -157,7 +157,7 @@ Also see [draft-dkg-openpgp-userid-conventions-00](https://datatracker.ietf.org/
 One proposed variant for encoding identities in User ID is to use ["split User IDs"](https://dkg.fifthhorseman.net/blog/2021-dkg-openpgp-transition.html#split-user-ids). 
 
 (primary_user_id)=
-#### Primary User ID and its implications
+### Primary User ID and its implications
 
 One User ID in a certificate has the special property of being the [Primary User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-primary-user-id).
 
@@ -170,7 +170,7 @@ i think crypto-refresh suggests that the direct key signature should hold the de
 we might need to write a more nuanced text here, about how DKS and primary user id interact in v6, and mention the differences to v4? 
 ```
 
-#### User attributes
+### User attributes
 
 [User attributes](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-attribute-packet-tag-1) are similar to User IDs, but less commonly used.
 
@@ -188,19 +188,14 @@ The primary key issues signatures that express the certificate holder's intent t
 
 Binding components together with digital signatures means that recipients of an OpenPGP certificate only need to verify that the primary key is the correct one to use for their communication partner (traditionally, this has often been done by manually verifying the *fingerprint* of the primary key). Once the validity of the primary key is established, the validity of all other components can be automatically determined by the user's OpenPGP software. To a first estimation, components are valid parts of a certificate if there is a statement signed with the certificate's primary key that expresses this validity.
 
-### Revocations
+## Revocations
 
 ```{admonition} TODO
 :class: warning
 
-This section only contains notes and still needs to be written
+This section needs to be written
 ```
 
-Note: certification signatures [can be made irrevocable](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-revocable).
-
-#### Hard vs. soft revocations
-
-(third_party_cert)=
 ## Third party (identity) certifications
 
 ```{admonition} TODO