vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2024-11-23 16:12:05 +01:00
Code Issues Projects Releases Packages Wiki Activity

ch4: flatten section structure

Browse source 
(And remove todo that was moved to ch6)
This commit is contained in:
Heiko Schaefer 2023-10-17 18:08:42 +02:00
parent 95cf1f7cab
commit 9d79096f24
No known key found for this signature in database
GPG key ID: 4A849A1904CCBD7D
1 changed files with 12 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -46,7 +46,7 @@ All elements in an OpenPGP certificate are structured around one central compone
OpenPGP certificates are typically long-lived and may be changed (typically by their owner), over time. Components can be added and invalidated, over the lifetime of a certificate OpenPGP certificates are typically long-lived and may be changed (typically by their owner), over time. Components can be added and invalidated, over the lifetime of a certificate
``` ```
### OpenPGP component keys ## Component keys
An OpenPGP certificate usually contains multiple OpenPGP component keys. An OpenPGP certificate usually contains multiple OpenPGP component keys.
@ -61,7 +61,7 @@ An OpenPGP component key
Component key representations that include private key material also contain metadata that specifies the password protection scheme for the private key material. However, in this chapter, we're looking at *OpenPGP certificates*, which *don't* contain private key information. Each component key of such a certificate contains only the public part of its cryptographic key data. To read more about private keys in OpenPGP, see {numref}`private_key_chapter`. Component key representations that include private key material also contain metadata that specifies the password protection scheme for the private key material. However, in this chapter, we're looking at *OpenPGP certificates*, which *don't* contain private key information. Each component key of such a certificate contains only the public part of its cryptographic key data. To read more about private keys in OpenPGP, see {numref}`private_key_chapter`.
#### Fingerprint ### Fingerprint
For each OpenPGP component key, an *OpenPGP fingerprint* can be derived from the combination of the public key material and creation timestamp (and ECDH parameters, if applicable). For each OpenPGP component key, an *OpenPGP fingerprint* can be derived from the combination of the public key material and creation timestamp (and ECDH parameters, if applicable).
@ -78,7 +78,7 @@ Historically, even shorter 32 bit identifiers have sometimes been used, like thi
Component keys are used in one of two roles: either as "OpenPGP primary key," or as an "OpenPGP subkey". Component keys are used in one of two roles: either as "OpenPGP primary key," or as an "OpenPGP subkey".
#### Primary key ### Primary key
The "OpenPGP primary key" is a component key that serves a central role in an OpenPGP certificate: The "OpenPGP primary key" is a component key that serves a central role in an OpenPGP certificate:
@ -93,7 +93,7 @@ The validity of the primary key limits its capacity to confer validity to other
In the RFC, the OpenPGP primary key is also sometimes referred to as "top-level key." It has also sometimes informally been called "master key." In the RFC, the OpenPGP primary key is also sometimes referred to as "top-level key." It has also sometimes informally been called "master key."
``` ```
#### Subkeys ### Subkeys
In addition to the primary key, modern OpenPGP certificates usually contain a number of "subkeys" (however, it's not technically necessary for a certificate to contain subkeys). In addition to the primary key, modern OpenPGP certificates usually contain a number of "subkeys" (however, it's not technically necessary for a certificate to contain subkeys).
@ -106,7 +106,7 @@ Subkeys have the same structure as the primary key, but they are used in a diffe
OpenPGP certificates can contain a number of subkeys OpenPGP certificates can contain a number of subkeys
``` ```
#### Key flags: defining which operations a component key can perform ### Key flags: defining which operations a component 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 specify which operations that 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 specify which operations that key can perform.
@ -126,7 +126,7 @@ It is considered good practice to have separate component keys for each type of
[^key-flag-sharing]: With ECC algorithms, it's actually not possible to share encryption functionality with the signing-based functionalities, e.g.: ed25519 used for signing; cv25519 used for encryption. [^key-flag-sharing]: With ECC algorithms, it's actually not possible to share encryption functionality with the signing-based functionalities, e.g.: ed25519 used for signing; cv25519 used for encryption.
#### Component key metadata, including key flags ### Component key metadata, including key flags
The key flags for a component key are actually not defined *inside* that component key itself. The key flags for a component key are actually not defined *inside* that component key itself.
@ -137,11 +137,11 @@ Instead, key flags, together with other metadata about that component key (such
(identity_components)= (identity_components)=
### Identity components ## Identity components
Identity components in an OpenPGP certificate are used by the certificate holder to state that they are known by a certain identifier (like a name, or an email address). Identity components in an OpenPGP certificate are used by the certificate holder to state that they are known by a certain identifier (like a name, or an email address).
#### User IDs ### User IDs
An OpenPGP certificate can contain any number of [User IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-id-packet-tag-13). Each User ID associates the certificate with an identity. An OpenPGP certificate can contain any number of [User IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-id-packet-tag-13). Each User ID associates the certificate with an identity.
@ -157,7 +157,7 @@ Also see [draft-dkg-openpgp-userid-conventions-00](https://datatracker.ietf.org/
One proposed variant for encoding identities in User ID is to use ["split User IDs"](https://dkg.fifthhorseman.net/blog/2021-dkg-openpgp-transition.html#split-user-ids). One proposed variant for encoding identities in User ID is to use ["split User IDs"](https://dkg.fifthhorseman.net/blog/2021-dkg-openpgp-transition.html#split-user-ids).
(primary_user_id)= (primary_user_id)=
#### Primary User ID and its implications ### Primary User ID and its implications
One User ID in a certificate has the special property of being the [Primary User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-primary-user-id). One User ID in a certificate has the special property of being the [Primary User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-primary-user-id).
@ -170,7 +170,7 @@ i think crypto-refresh suggests that the direct key signature should hold the de
we might need to write a more nuanced text here, about how DKS and primary user id interact in v6, and mention the differences to v4? we might need to write a more nuanced text here, about how DKS and primary user id interact in v6, and mention the differences to v4?
``` ```
#### User attributes ### User attributes
[User attributes](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-attribute-packet-tag-1) are similar to User IDs, but less commonly used. [User attributes](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-attribute-packet-tag-1) are similar to User IDs, but less commonly used.
@ -188,19 +188,14 @@ The primary key issues signatures that express the certificate holder's intent t
Binding components together with digital signatures means that recipients of an OpenPGP certificate only need to verify that the primary key is the correct one to use for their communication partner (traditionally, this has often been done by manually verifying the *fingerprint* of the primary key). Once the validity of the primary key is established, the validity of all other components can be automatically determined by the user's OpenPGP software. To a first estimation, components are valid parts of a certificate if there is a statement signed with the certificate's primary key that expresses this validity. Binding components together with digital signatures means that recipients of an OpenPGP certificate only need to verify that the primary key is the correct one to use for their communication partner (traditionally, this has often been done by manually verifying the *fingerprint* of the primary key). Once the validity of the primary key is established, the validity of all other components can be automatically determined by the user's OpenPGP software. To a first estimation, components are valid parts of a certificate if there is a statement signed with the certificate's primary key that expresses this validity.
### Revocations ## Revocations
```{admonition} TODO ```{admonition} TODO
:class: warning :class: warning
This section only contains notes and still needs to be written This section needs to be written
``` ```
Note: certification signatures [can be made irrevocable](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-revocable).
#### Hard vs. soft revocations
(third_party_cert)=
## Third party (identity) certifications ## Third party (identity) certifications
```{admonition} TODO ```{admonition} TODO