mirror of
https://codeberg.org/openpgp/notes.git
synced 2025-09-09 11:19:41 +02:00
Merge pull request 'ch4: add two new diagrams' (#160) from heiko-ch4 into draft
Reviewed-on: https://codeberg.org/openpgp/notes/pulls/160
This commit is contained in:
commit
93519777c7
1 changed files with 20 additions and 2 deletions
|
@ -49,7 +49,7 @@ An OpenPGP certificate (or "OpenPGP key") is a collection of an arbitrary number
|
|||
This documentation collectively refers to component keys and identity components as "the components of a certificate."
|
||||
|
||||
```{figure} diag/Components_of_an_OpenPGP_Certificate.svg
|
||||
:name: fig-openpgp-certificate
|
||||
:name: fig-openpgp-certificate-components
|
||||
:alt: Depicts a box with white background and the title "OpenPGP certificate". In the box several other boxes and accompanying texts, representing component keys and User IDs, are shown. There are three component keys boxes with a green frame, each with a dotted lower-left section, that shows the text "key creation time" and the green public key symbol in the lower right area. All three have a title, a unique fingerprint below the box and a unique capability keyword, perpendicular to the box on the right side. The top-most component key box has a light-green background, with the title "Component Key (primary)" and capability keyword "certification". The second-to-top component key box has a white background, with the title "Component Key" and capability keyword "encryption". The lowest component key box has a white background, with the title "Component Key" and capability keyword "signing". There are two User ID boxes, each with a black frame, open to top left and lower right corner. Both boxes have a user icon on the top left side, the title "User ID" on the top right side and a User ID string at the bottom. The top box has "Alice Adams <alice@example.org>" and the lower box has "Alice" as User ID string.
|
||||
|
||||
Typical components in an OpenPGP certificate
|
||||
|
@ -69,7 +69,7 @@ OpenPGP component keys logically consist of an [asymmetric cryptographic keypair
|
|||
|
||||
[^ecdh-parameters]: For [ECDH](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-part-for-ecd) component keys, two additional algorithm parameters are integral to the component key's constitutive and immutable properties. Those parameters specify a hash function and a symmetric encryption algorithm.
|
||||
|
||||
```{figure} diag/Component_Key.svg
|
||||
```{figure} diag/Component_Key.png
|
||||
:name: fig-component-key
|
||||
:alt: Depicts a box with white background and no title. In the box one other box is shown. The inner box has a green frame, with a dotted lower-left section, that shows the text "key creation time" and the green public key symbol, as well as the red-dotted private key symbol in the lower right area. In the top left of the inner box the text reads "Component Key".
|
||||
|
||||
|
@ -197,6 +197,13 @@ Key attributes, such as capabilities (like *signing* or *encryption*) and expira
|
|||
|
||||
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.
|
||||
|
||||
```{figure} diag/Primary_key_metadata.png
|
||||
:name: fig-primary-metadata
|
||||
:alt: Depicts a direct key signature, associated with a primary component key.
|
||||
|
||||
Metadata can be associated with the primary key using a *direct key signature*.
|
||||
```
|
||||
|
||||
### 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.
|
||||
|
@ -242,6 +249,17 @@ As a starting point, a certificate has a set of preferences that apply generally
|
|||
|
||||
Additionally, OpenPGP allows modeling User ID-specific preferences. The idea is that a user may prefer a different suite of algorithms on their private email account compared to their work email account. Such identity-specific preferences can be expressed on the certifying signatures that bind User IDs to a certificate.
|
||||
|
||||
## A typical OpenPGP certificate, revisited
|
||||
|
||||
Following our review of how keys and identity components are linked, let's reexamine the OpenPGP certificate from {numref}`fig-openpgp-certificate-components`. Our focus now extends to all of its binding signatures and the direct key signature that contains metadata for the full certificate:
|
||||
|
||||
```{figure} diag/OpenPGP_Certificate.png
|
||||
:name: fig-openpgp-certificate
|
||||
:alt: Depicts an OpenPGP certificate, including a set of components, binding signatures, and a direct key signature on the primary key.
|
||||
|
||||
This shows a typical OpenPGP certificate, including binding signatures for all of its components, and a signature that associates metadata with the primary key.
|
||||
```
|
||||
|
||||
## Revocations
|
||||
|
||||
When a certificate owner needs to invalidate certain components of their certificate, or even the entire certificate, they accomplish this through "revocation." Revoking the primary key renders the entire certificate invalid.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue