ch4: feedback from wiktor

book/source/04-certificates.md

@@ -9,7 +9,7 @@ The concept of "(cryptographic) keys" plays a central role, when looking at Open
 
 ### Private vs. public keys
 
-First, without additional context, the word "key" can refer either to public, or to private asymmetric key material (or even to symmetric keys, but those don't play a role in OpenPGP certificates).
+First, without additional context, the word "key" can refer either to public, or to private asymmetric key material (or even to symmetric keys, which can be used to encrypt private key material in OpenPGP keys).
 
 ### Layers of "keys," in OpenPGP
 
@@ -28,7 +28,7 @@ An OpenPGP certificate (or "OpenPGP key") is a collection of an arbitrary number
 
 - Component OpenPGP keys,
 - Identity information,
-- Other metadata.
+- Other metadata (this includes connections between the certificate's elements).
 
 We sometimes collectively refer to component keys and identity information as the "components" of a certificate.
 
@@ -45,20 +45,20 @@ OpenPGP certificates are typically long-lived and may be changed (typically by t
 
 ### OpenPGP component keys
 
-An OpenPGP certificate usually contains multiple component keys.
+An OpenPGP certificate usually contains multiple OpenPGP component keys.
 
-Each OpenPGP component key is a thin layer of OpenPGP metadata (and framing) added to an [asymmetric cryptographic keypair](asymmetric_key_pair).
+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]).
+
+[^ecdh-paramters]: 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 part of the component key's constituting and immutable properties. Those parameters define a hash function and a symmetric encryption algorithm.
 
 ```{figure} diag/Component_Key.svg
 
 An OpenPGP component key
 ```
 
-In addition to the cryptographic key pair, an OpenPGP component key contains a key creation timestamp.
-
 Component key representations that include private key material also contain metadata that specifies the password protection scheme for the private key material.
 
-For each OpenPGP component key, an *OpenPGP fingerprint* can be derived from the combination of the public key material and creation timestamp (plus additional algorithm parameters, in the case of [ECDH Keys](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-part-for-ecd)):
+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).
 
 ```{figure} diag/Fingerprint.png
 
@@ -88,7 +88,7 @@ In the RFC, the OpenPGP primary key is also sometimes referred to as "top-level
 
 #### Subkeys
 
-In addition to the primary key, modern OpenPGP certificates usually contain a number of "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).
 
 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).
 
@@ -114,7 +114,7 @@ By convention, only the primary key is allowed to perform "certification" operat
 
 ```{note}
 
-It is considered good practice to have separate component keys for each type of operation: to allow only *Certification* operations with the primary key, and to use separate *Signing*, *Encryption* and *Authentication* subkeys [^key-flag-sharing].
+It is considered good practice to have separate component keys for each type of operation: to allow only *Certification* operations with the primary key, and to use separate *Signing*, *Encryption* and *Authentication* subkeys (independently: with most algorithms, encryption can't be shared with the other capabilities[^key-flag-sharing]).
 ```
 
 [^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.
@@ -126,7 +126,7 @@ It is considered good practice to have separate component keys for each type of
 
 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.
 
-Often, identities in a User ID consist of a string that is composed of a name and an email address.
+Often, identities in a User ID consist of a string that is composed of a name and an email address (this string must be UTF-8 encoded).
 
 ```{figure} diag/user_id.png
 
@@ -144,6 +144,7 @@ User IDs are associated with preference settings (such as preferred encryption a
 
 [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.
 
+The OpenPGP standard currently only defines one format to store in User Attributes: an [image](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-the-image-attribute-subpack), "presumably (but not required to be) that of the key owner".
 
 ### Linking the components of an OpenPGP certificate
 
@@ -161,6 +162,13 @@ So while anyone can still unilaterally store unrelated subkeys and identity clai
 
 (Conversely, it's easy for a third party to leave out packets when passing on an OpenPGP certificate. An attacker can, for example, choose to omit revocation packets. The recipient of such a partial copy has no way to notice the omission, without access to a different source for the certificate that contains the revocation packet.)
 
+Note, though, that there are some cases where third parties do add packets to certificates, which are not "bound" by the certificate's owner:
+
+- [Third-party certifications](third_party_cert) are traditionally added to the certificate that they make a statement about (which can in some cases cause problems[^flooding]),
+- OpenPGP software may add [unbound identity data](unbound_user_ids), locally.
+
+[^flooding]: Storing third-party identity certifications in the target OpenPGP certificate is convenient for consumers: it is easy to find all relevant certifications in one central location. However, when third parties can unilaterally add certifications, this opens an avenue for denial-of-service attacks by flooding. The SKS network of OpenPGP key servers [allowed and experienced this problem](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html).
+
 #### Binding subkeys to an OpenPGP certificate
 
 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".
@@ -196,7 +204,7 @@ This additional "Primary Key Binding" Signature is informally called a "back sig
 
 For example, the User ID `Alice Adams <alice@example.org>` may be associated with Alice's certificate `AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6  7F33 00F9 FB0E C457 378C D29F 1026 98B3`.
 
-Alice can link a User ID to her OpenPGP certificate with a cryptographic signature. To link a User ID, a signature of the type `PositiveCertification` is created. The signature is issued using the primary (secret) key.
+Alice can link a User ID to her OpenPGP certificate with a cryptographic signature. To link a User ID, a self-signature is created (usually with the signature type [PositiveCertification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-positive-cert)). This signature is issued by the primary key.
 
 ```{figure} diag/user_id_certification.png
 ---
@@ -204,11 +212,23 @@ Alice can link a User ID to her OpenPGP certificate with a cryptographic signatu
 Linking a User ID to an OpenPGP certificate
 ```
 
-
+(third_party_cert)=
 ## Third party (identity) certifications
 
+```{admonition} TODO
+:class: warning
+
+This section only contains notes and still needs to be written
+```
+
 ## Revocations
 
+```{admonition} TODO
+:class: warning
+
+This section only contains notes and still 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
@@ -216,6 +236,12 @@ Note: certification signatures [can be made irrevocable](https://www.ietf.org/ar
 
 ## Advanced topics
 
+```{admonition} TODO
+:class: warning
+
+This section only contains notes and still needs to be written
+```
+
 ### Certificate Management / Evolution of a certificate over time
 
 Minimized versions, merging, effective "append only" semantics, ...
@@ -235,14 +261,21 @@ Minimized versions, merging, effective "append only" semantics, ...
 
 ### Best Practices regarding Key Freshness
 
+```{admonition} TODO
+:class: warning
+
 - Expiry
 - Subkey rotation
 
+Wiktor suggests to check: https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/ for important material
+```
+
 ### Metadata Leak of Social Graph
 
+(unbound_user_ids)=
 ### Adding unbound User IDs to a certificate
 
-Some OpenPGP subsystems may add User IDs to a certificate, which are not bound to the primary key by the certificate's owner. This can be useful to store local identity information (e.g. sequoia's public store).
+Some OpenPGP subsystems may add User IDs to a certificate, which are not bound to the primary key by the certificate's owner. This can be useful to store local identity information (e.g., Sequoia's public store attaches "pet-names" to certificates, in this way).
 
 ## Zooming in: Packet structure
 
@@ -363,7 +396,7 @@ This concludes the Public Key section of the packet. The remaining data follows
 - `s2k_usage: 0x00`: Specified that the secret-key data is not encrypted
 - `ed25519_secret`: [Algorithm-specific representation](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-part-for-ed2) of the secret key data (the format is based on the value of `pk_algo`)
 
-[^CTB]: Sequoia uses the term "CTB" (Cipher Type Byte) to refer to the RFC's "Packet Tag"
+[^CTB]: Sequoia uses the term "CTB" (Cipher Type Byte) to refer to the RFC's ["Packet Tag"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-packet-headers)
 
 ```{tip}
 
@@ -618,7 +651,7 @@ In the following examples, we will look at OpenPGP private keys only. The corres
 
 ### Subkeys
 
-From here on, we'll look at the dumps in shorter format (you can see more detail by copying the certificates into the web-dumper at https://dump.sequoia-pgp.org/ and checking the "HexDump" checkbox).
+From here on, we'll look at the dumps in shorter format (you can see more detail by copying the certificates into the ["Sequoia OpenPGP Packet dumper"](https://dump.sequoia-pgp.org/) and checking the "HexDump" checkbox).
 
 ### User IDs