ch4: restructure text about metadata

Move "metadata" content into its own section.
This section started out as a remark about key flags, and was part of the "component key" section.
Generalizing it seems better, so it's now after the "linking" section, which introduces binding self-signatures.

book/source/04-certificates.md

@@ -113,40 +113,6 @@ While subkeys have the same structural attributes as the primary key, they fulfi
 OpenPGP certificates can contain multiple subkeys.
 ```
 
-#### Defining operational capabilities with key flags
-
-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 delineate the operations a key can perform.
-
-Commonly used key flags include:
-
-- **Certification**: enables issuing third-party certifications
-- **Signing**: allows the key to sign data 
-- **Encryption**: allows the key to encrypt data
-- **Authentication**: primarily used for OpenPGP authentication
-
-```{note}
-Distinct component keys handle specific operations. Only the primary key can be used for certification, although it can have additional capabilities. Subkeys can be used for signing, encryption, and authentication but cannot have the certification capability. It is considered good practice, however, to [use separate keys for each capability](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-10.1.5-7). 
-
-Notably, in many algorithms, encryption and signing-related functionalities (i.e., certification, signing, authentication) are mutually exclusive, because the algorithms only support one of those two families of operations[^key-flag-sharing]).
-```
-
-[^key-flag-sharing]: With ECC algorithms, it's impossible to combine encryption functions with those intended for signing. For example,  ed25519 is specifically used for signing; cv25519 is designated for encryption.
-
-### Component key metadata, including key flags
-
-The key flags for a component key are not stored within  the component key directly.
-
-Instead, key flags, along with other metadata about that component key, such as the key expiration time, are stored using mechanisms that bind components into an OpenPGP certificate:
-
-- For the primary key, its key flags and other metadata can be defined in two ways: they can be linked with the [Primary User ID](primary_user_id) or through a [direct key signature](direct_key_signature).
-- For subkeys, the key flags and other metadata are set using the mechanism that binds the subkey to the certificate, specifically through the primary key. Further details on  [binding subkeys](binding_subkeys) are below.
-
-```{admonition} TODO
-:class: warning
-
-Write a section about algorithm preference/feature signaling
-```
-
 (identity_components)=
 ## Identity components
 
@@ -208,6 +174,45 @@ In very abstract terms, the primary key of a certificate acts as a root of trust
 
 By binding components using digital signatures, recipients of an OpenPGP certificate need only validate the authenticity of the primary key to use for their communication partner. Traditionally, this is done by manually verifying the *fingerprint* of the primary key. Once the validity of the primary key is confirmed, the validity of the remaining components can be automatically assessed by the user's OpenPGP software. Generally, components are valid parts of a certificate if there is a statement signed by the certificate's primary key endorsing this validity.
 
+## Metadata: capabilities, preferences, etc
+
+Much of the metadata in OpenPGP certificates is actually not stored inside the components that the metadata applies to. Instead, much of the metadata for certificates, component keys and identities is defined as a part of the signatures that join components into a certificate.
+
+For example, the capabilities of a component key (such as *signing* or *encryption*), or the expiration time of a component key, are not encoded as a part of the *packet* that encodes the data of that component key.
+
+Instead, are stored using mechanisms that bind components into an OpenPGP certificate:
+
+- For the primary key, its key flags and other metadata can be defined in two ways: they can be linked with the [Primary User ID](primary_user_id) or through a [direct key signature](direct_key_signature).
+- For subkeys, the key flags and other metadata are set using the mechanism that binds the subkey to the certificate, specifically through the primary key. Further details on [binding subkeys](binding_subkeys) are below.
+- For identity components, like User IDs, metadata is associated via the [certifying self-signature](bind_ident) that links the identity to the certificate.
+
+### Defining operational capabilities of component keys with key flags
+
+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 delineate the operations a key can perform.
+
+Commonly used key flags include:
+
+- **Certification**: enables issuing third-party certifications
+- **Signing**: allows the key to sign data
+- **Encryption**: allows the key to encrypt data
+- **Authentication**: primarily used for OpenPGP authentication
+
+```{note}
+Distinct component keys handle specific operations. Only the primary key can be used for certification, although it can have additional capabilities. Subkeys can be used for signing, encryption, and authentication but cannot have the certification capability. It is considered good practice, however, to [use separate keys for each capability](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-10.1.5-7). 
+
+Notably, in many algorithms, encryption and signing-related functionalities (i.e., certification, signing, authentication) are mutually exclusive, because the algorithms only support one of those two families of operations[^key-flag-sharing]).
+```
+
+[^key-flag-sharing]: With ECC algorithms, it's impossible to combine encryption functions with those intended for signing. For example,  ed25519 is specifically used for signing; cv25519 is designated for encryption.
+
+### Algorithm preferences and feature signaling
+
+```{admonition} TODO
+:class: warning
+
+Write a section about algorithm preference/feature signaling
+```
+
 ## Revocations
 
 ```{admonition} TODO