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

edit metadata capabilities of commit c6888559f5

Browse source
This commit is contained in:
Tammi L. Coles 2023-11-25 13:59:35 +01:00
parent 6ada412e74
commit a914e60fa3
1 changed files with 8 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -177,21 +177,19 @@ 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
## Metadata capabilities, preferences, and storage
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.
OpenPGP certificates, their component keys, and identities possess metadata that is not stored within the components it pertains to. Instead, this metadata is stored within signature packets, which are integral to the structure of an OpenPGP certificate.
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.
Key attributes, such as capabilities (like *signing* or *encryption*) and expiration times, are examples of metadata not stored in the component key data. How this metadata is stored depends on the component:
Instead, this kind of metadata is stored as part of the signature packets that join components into an OpenPGP certificate:
- **Primary key metadata** is defined either through a direct key signature on the primary key (preferred in OpenPGP version 6), or by associating the metadata with the [Primary User ID](primary_user_id).
- 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 (preferred method in OpenPGP version 6),
- 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.
- **Subkey metadata** is defined within the [subkey binding signature](binding_subkeys) that links the subkey to the certificate.
Note that the components of an OpenPGP certificate are themselves never changed, after their initial creation. By storing associated metadata in signatures, it can be modified at a later point in time by issuing a new signature that replaces the previous one. For example, the certificate holder can change the expiration time of a component of their certificate by issuing a new signature.
- **User ID metadata** is is associated via the [certifying self-signature](bind_ident) that links the identity to the certificate.
It is crucial to note that the components of an OpenPGP certificate remain static after their creation. The use of signatures to store metadata allows for subsequent modifications without altering the original components. For instance, a certificate holder can update the expiration time of a component by issuing a new, superseding signature.
### Defining operational capabilities of component keys with key flags