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

ch4: update links from 4880 to crypto-refresh

Browse source
This commit is contained in:
Heiko Schaefer 2023-10-01 13:59:54 +02:00
parent 2640c84181
commit 47867b32f4
No known key found for this signature in database
GPG key ID: 4A849A1904CCBD7D
1 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -97,7 +97,7 @@ Each component key (this includes the primary key, and all subkeys) has a marker
#### Key Flags: defining what operations a component key can perform
Each component key has ["Key Flags"](https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.21) that specify which types of operation the key can perform.
Each component key has ["Key Flags"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#key-flags) that specify which types of operation the key can perform.
The commonly used flags are:
@ -147,7 +147,7 @@ So while anyone can still unilaterally put subkeys and identity claims into a fi
#### "Binding" subkeys to an OpenPGP certificate
Linking a subkey to an OpenPGP certificate is done with a ["Subkey Binding Signature"](https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.1). Such a signature signals that the "primary key wants to be associated with the subkey".
Linking a subkey to an OpenPGP certificate is done with a ["Subkey Binding Signature"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-subkey-binding). Such a signature signals that the "primary key wants to be associated with the subkey".
The subkey binding signature also adds metadata.
@ -237,9 +237,9 @@ An OpenPGP certificate/key consists of a number of elements, many of them option
As a consequence, some elements of OpenPGP certificates/keys represent "private" (sometimes referred to as "secret") key material, while other elements represent "public" key material. Yet other elements contain metadata, and finally there are elements that serve as glue ("binding") between the various other elements of a certificate.
To hand out copies of one's OpenPGP key to third parties, implementations can generate a "certificate" / "public key" representation ([Transferable Public Keys](https://tools.ietf.org/html/rfc4880#section-11.1) in the RFC), which consists of all the elements of the certificate, except for the private key material (and the optional [S2K configuration](https://tools.ietf.org/html/rfc4880#section-3.7.2.1)).
To hand out copies of one's OpenPGP key to third parties, implementations can generate a "certificate" / "public key" representation ([Transferable Public Keys](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#transferable-public-keys) in the RFC), which consists of all the elements of the certificate, except for the private key material (and the optional [S2K configuration](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-string-to-key-s2k-specifier)).
The counterpart is called [Transferable Secret Keys](https://tools.ietf.org/html/rfc4880#section-11.2) in the RFC. That is, an OpenPGP key that includes private key material.
The counterpart is called [Transferable Secret Keys](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#transferable-secret-keys) in the RFC. That is, an OpenPGP certificate that includes private key material.
### A minimal OpenPGP key
@ -360,8 +360,8 @@ Signature Packet, new CTB, 2 header bytes + 131 bytes
We see that the key consists of two packets:
* First, a [*"Secret-Key Packet"*](https://tools.ietf.org/html/rfc4880#section-5.5.1.3), which contains the actual cryptographic key data. Note: the "Secret-Key" Packet contains both the private and the public part of the key. We also see in the output that this packet is "Unencrypted" (i.e. not password-protected).
* Second, a [*"Signature Packet"*](https://tools.ietf.org/html/rfc4880#section-5.2) of type 0x1F, *"Signature directly on a key"*. This packet *"binds the information in the Signature subpackets to the key"*. Each entry under "Signature Packet -> Hashed area" is one Signature subpacket, including for example information about algorithm preferences (*"Symmetric algo preferences"* and *"Hash preferences"*).
* First, a [*"Secret-Key Packet"*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#seckey), which contains the actual cryptographic key data. Note: the "Secret-Key" Packet contains both the private and the public part of the key. We also see in the output that this packet is "Unencrypted" (i.e. not password-protected).
* Second, a [*"Direct Key Signature"*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-direct-key) (type 0x1F), *"Signature directly on a key"*. This packet *"binds the information in the Signature subpackets to the key"*. Each entry under "Signature Packet -> Hashed area" is one Signature subpacket, including for example information about algorithm preferences (*"Symmetric algo preferences"* and *"Hash preferences"*).
```{figure} diag/key-minimal.png
---
@ -495,7 +495,7 @@ In the following examples, we will look at OpenPGP private keys only. The corres
User IDs are a mechanism for attaching *identities* to an OpenPGP certificate. Typically, a User ID will contain a name and an email address.
To look into these, we'll make a certificate that has one [User ID](https://tools.ietf.org/html/rfc4880#section-5.11). User IDs are *"intended to represent the name and email address of the key holder"*. A certificate can have multiple User IDs associated with it.
To look into these, we'll make a certificate that has one [User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#uid). User IDs are *"intended to represent the name and email address of the key holder"*. A certificate can have multiple User IDs associated with it.
```
let (cert, _) = CertBuilder::new()
@ -689,8 +689,8 @@ Instead of two sections, as before, we see four sections in this certificate:
* First, a "Secret-Key Packet,"
* then a "Signature Packet" (these two packets are the same as above).
* Third, a [*"User ID Packet"*](https://tools.ietf.org/html/rfc4880#section-5.11), which contains the name and email address we used
* Finally, a [*"Signature Packet"*](https://tools.ietf.org/html/rfc4880#section-5.2) of type 0x13, *"Positive certification of a User ID and Public-Key packet"*. This is a cryptographic artifact that "binds the User ID packet and the Key packet together", i.e. it certifies that the owner of the key wants this User ID associated with their key. (Only the person who controls the private part of this key can create this signature packet. The signature serves as proof that the owner of the key has added this User ID to the certificate)
* Third, a [*"User ID Packet"*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#uid), which contains the name and email address we used
* Finally, a [*"Positive Certification Signature"*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-positive-cert) (type 0x13), *"Positive certification of a User ID and Public-Key packet"*. This is a cryptographic artifact that "binds the User ID packet and the Key packet together", i.e. it certifies that the owner of the key wants this User ID associated with their key. (Only the person who controls the private part of this key can create this signature packet. The signature serves as proof that the owner of the key has added this User ID to the certificate)
### Subkeys