mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-26 17:42:06 +01:00
ch4: clarification as suggested by wiktor
This commit is contained in:
parent
e0457bac64
commit
fc665cb197
1 changed files with 2 additions and 0 deletions
|
@ -183,6 +183,8 @@ Instead, this kind of metadata is stored as part of the signature packets that j
|
||||||
- For subkeys, metadata is defined with the [subkey binding signature](binding_subkeys) that links the subkey to the certificate.
|
- 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.
|
- For identity components like User IDs, metadata is associated via the [certifying self-signature](bind_ident) that links the identity 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.
|
||||||
|
|
||||||
### Defining operational capabilities of component keys with key flags
|
### 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.
|
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.
|
||||||
|
|
Loading…
Reference in a new issue