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

get remote changes

Browse source
This commit is contained in:
Tammi L. Coles 2023-10-19 19:49:53 +02:00
commit 498b01f01a
1 changed files with 29 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -51,9 +51,15 @@ OpenPGP certificates tend to have a long lifespan, with the potential for modifi
## Component keys
<<<<<<< HEAD
An OpenPGP certificate usually contains multiple OpenPGP component keys.
OpenPGP component keys consist of an [asymmetric cryptographic keypair](asymmetric_key_pair) and a creation timestamp. These attributes of a component key cannot be changed after creation (in the case of ECDH keys, two additional parameters are part of a component key's constituting data[^ecdh-paramters]).
=======
An OpenPGP certificate usually contains multiple component keys. Component keys serve in one of two roles: either as an "OpenPGP primary key" or as an "OpenPGP subkey."
OpenPGP component keys logically consist of an [asymmetric cryptographic keypair](asymmetric_key_pair) and a creation timestamp. Once created, these attributes of a component key remain fixed (for ECDH keys, two additional parameters are part of a component key's constitutive data[^ecdh-parameters]).
>>>>>>> refs/remotes/origin/tammi-ch4
[^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.
@ -62,8 +68,15 @@ OpenPGP component keys consist of an [asymmetric cryptographic keypair](asymmetr
An OpenPGP component key
```
<<<<<<< HEAD
Component key representations that include private key material also contain metadata that specifies the password protection scheme for the private key material.
=======
Component keys containing 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
>>>>>>> refs/remotes/origin/tammi-ch4
For each OpenPGP component key, an *OpenPGP fingerprint* can be generated. This fingerprint is derived from the combination of the public key material and creation timestamp (and ECDH parameters, if applicable).
```{figure} diag/Fingerprint.png
@ -71,20 +84,27 @@ For each OpenPGP component key, an *OpenPGP fingerprint* can be generated. This
Every OpenPGP component key is identifiable by a unique fingerprint.
```
<<<<<<< HEAD
The fingerprint of our example component OpenPGP key is `AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3` [^keyid].
=======
The fingerprint of our example OpenPGP component key is `C0A5 8384 A438 E5A1 4F73 7124 26A4 D45D BAEE F4A3 9E6B 30B0 9D55 13F9 78AC CA94`[^keyid].
>>>>>>> refs/remotes/origin/tammi-ch4
[^keyid]: In OpenPGP version 4, the rightmost 64 bit were sometimes used as a shorter identifier, called "Key ID".
E.g., an OpenPGP version 4 certificate with the fingerprint `B3D2 7B09 FBA4 1235 2B41 8972 C8B8 6AC4 2455 4239` might be referred to by the 64 bit Key ID `C8B8 6AC4 2455 4239` or styled as `0xC8B86AC424554239`.
Historically, even shorter 32 bit identifiers have sometimes been used, like this: `2455 4239`, or `0x24554239`. You may still see such identifiers in very old documents about PGP. However, 32 bit identifiers have [been unfit for purpose for a long time](https://evil32.com/). At some point, 32 bit identifiers were called "short Key ID", while 64 bit identifiers were called "long Key ID".
[^keyid]: In OpenPGP version 4, the rightmost 64 bits were sometimes used as a shorter identifier, called "Key ID."
For example, an OpenPGP version 4 certificate with the fingerprint `B3D2 7B09 FBA4 1235 2B41 8972 C8B8 6AC4 2455 4239` might be referenced by the 64-bit Key ID `C8B8 6AC4 2455 4239` or formatted as `0xC8B86AC424554239`.
Historically, even shorter 32-bit identifiers were used, like this: `2455 4239`, or `0x24554239`. Such identifiers still appear in very old documents about PGP. However, [32-bit identifiers have been long deemed unfit for purpose](https://evil32.com/). At one point, 32-bit identifiers were called "short Key ID," while 64-bit identifiers were referred to as "long Key ID."
Component keys are used in one of two roles: either as "OpenPGP primary key," or as an "OpenPGP subkey".
<<<<<<< HEAD
#### Primary key
=======
>>>>>>> refs/remotes/origin/tammi-ch4
The OpenPGP primary key is a distinct component key that serves a central role in an OpenPGP certificate:
- Its fingerprint is used as the unique identifier for the full OpenPGP certificate.
- It is used for lifecycle operations, such as adding or invalidating subkeys or identities in a certificate.
- Its fingerprint acts as the unique identifier for the entire OpenPGP certificate.
- It facilitates lifecycle operations, such as adding or invalidating subkeys or identities within a certificate.
```{admonition} Terminology
:class: note
@ -96,7 +116,11 @@ In the RFC, the OpenPGP primary key is occasionally referred to as "top-level ke
In addition to the primary key, modern OpenPGP certificates usually contain several subkeys, although they are not technically required.
<<<<<<< HEAD
Subkeys have the same structure as the primary key, but they are used in a different role. Subkeys are cryptographically linked with the primary key (more on this below).
=======
Subkeys have the same structural attributes as the primary key but fulfill a different role. Subkeys are cryptographically linked with the primary key (more on this in {numref}`binding_subkeys`).
>>>>>>> refs/remotes/origin/tammi-ch4
```{figure} diag/Subkeys.png
:name: Certificate with subkeys