vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2025-02-17 01:26:29 +01:00
Code Issues Projects Releases Packages Wiki Activity

clarify metadata section

Browse source
This commit is contained in:
Heiko Schaefer 2023-11-18 18:54:03 +01:00
parent d157a4d1fc
commit 26df966a2c
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 8 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
book/source/04-certificates.md
View file

@ -169,15 +169,17 @@ By binding components using digital signatures, recipients of an OpenPGP certifi
## 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.
Much of the metadata for OpenPGP certificates, component keys, and identities, is not actually stored as part of the components that the metadata applies to.
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.
For example, the capabilities of a component key, such as *signing* or *encryption*, as well as its expiration time, are not stored as a part of the data of that component key.
Instead, are stored using mechanisms that bind components into an OpenPGP certificate:
Instead, this kind of metadata is stored as part of the signature packets that join 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.
- For the primary key, its key flags and other metadata can be defined in two ways:
- With a [direct key signature](direct_key_signature) on the primary key,
- or by associating the metadata with the [Primary User ID](primary_user_id).
- For subkeys, metadata is defined with the [subkey binding signature](binding_subkeys) that links the subkey to the certificate.
- 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