From 3f38d588f546fd6e36016888ae16174e2b7fd87d Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Fri, 27 Oct 2023 09:26:13 +0200
Subject: [PATCH 01/26] edit ch17

---
 book/source/17-zoom_certificates.md | 68 +++++++++++++++++------------
 1 file changed, 39 insertions(+), 29 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 78dc2a5..d4d123a 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -6,15 +6,15 @@ SPDX-License-Identifier: CC-BY-SA-4.0
 (zoom_certificates)=
 # Zooming in: Packet structure of certificates and keys
 
-Now that we've established these concepts, and the components that OpenPGP certificates consist of, let's look at the internal details of an example certificate.
+Now that we've established the concepts and  components that make up OpenPGP certificates , let's look at the internal details of an example certificate.
 
 ## A very minimal OpenPGP certificate
 
-First, we'll look at a very minimal version of a "public key" variant of [](alice_priv). That is, an OpenPGP certificate (which doesn't contain private key material).
+In this section, we will examine a very minimal version of a "public key" variant of [Alice's OpenPGP key](alice_priv), specifically an OpenPGP certificate that excludes private key material.
 
-In this section, we use the Sequoia-PGP tool `sq` to handle and transform our example OpenPGP key, and to inspect internal OpenPGP packet data.
+To achieve this, we will use the Sequoia-PGP tool `sq` to handle and transform our example OpenPGP key, as well as to inspect internal OpenPGP packet data.
 
-Starting from [Alice's OpenPGP "private key"](alice_priv), we first produce the corresponding "public key", or certificate:
+Starting from [Alice's OpenPGP private key](alice_priv), we first produce the corresponding public key/certificate using the following command:
 
 ```text
 $ sq key extract-cert alice.priv > alice.pub
@@ -23,13 +23,15 @@ $ sq key extract-cert alice.priv > alice.pub
 (split_alice)=
 ### Splitting the OpenPGP certificate into packets
 
-One way to produce a very minimal version of Alice's certificate is to split the data in `alice.pub` into its component packets, and join only the relevant ones back together into a new variant.
+To create a very minimal version of Alice's certificate, we will split the data in `alice.pub` into its component packets and reassemble only the relevant ones back into a new variant.
+
+Execute the following command to achieve this:
 
 ```text
 $ sq packet split alice.pub
 ```
 
-With this command, `sq` generates a set of files, each containing an individual OpenPGP packet of the original full certificate in `alice.pub`:
+With this command, `sq` generates a set of files, each containing an individual OpenPGP packet extracted from the original full certificate in `alice.pub`:
 
 ```text
 alice.pub-0--PublicKey
@@ -50,22 +52,28 @@ alice.pub-9--Signature
 Overview of the packets in Alice's OpenPGP certificate 
 ```
 
-### Joining packets into an OpenPGP certificate
+This process allows us to focus on the specific packets within Alice's OpenPGP certificate.
 
-For our first step, we'll use just the first two of the packets of Alice's certificate, and join them together as a very minimal certificate:
+### Assembling packets into an OpenPGP certificate
+
+In this step, we'll merge the first two packets of Alice's certificate to create a very minimal certificate:
+
+Execute the following:
 
 ```text
 $ sq packet join alice.pub-0--PublicKey alice.pub-1--Signature --output alice_minimal.pub
 ```
 
+This command combines the contents of `alice.pub-0--PublicKey` and `alice.pub-1--Signature` into a single file named `alice_minimal.pub`.
+
 ### Inspecting this certificate
 
 This version of Alice's certificate contains just two packets:
 
-- The [*Public-Key packet*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-public-key-packet-formats) for the primary key, and
-- A [*Direct Key Signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-direct-key) (a self-signature that binds metadata to the primary key).
+- the [*Public-Key packet*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-public-key-packet-formats) for the primary key, and
+- a [*Direct Key Signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-direct-key), which is a self-signature that binds metadata to the primary key.
 
-This is the shape of the packets we'll be looking at, in the following two sections:
+This is the shape of the packets we'll explore in the subsequent sections:
 
 ```{figure} diag/pubcert-minimal.png
 :width: 40%
@@ -83,9 +91,9 @@ This diagram needs adjustments about
 We could show repeat-copies of the individual packet visualization again, below for each packet-related section.
 ```
 
-In the real world, you won't usually encounter an OpenPGP certificate that is quite this minimal. However, this is technically a valid OpenPGP certificate (and we'll add more components to it, later in this section).
+In real-world scenarios, OpenPGP certificates are typically far more complex than this minimal example. However, this is indeed a valid OpenPGP certificate. In the following sections, we will introduce more components to this certificate, increasing its complexity and exploring their details.
 
-In ASCII-armored representation, this very minimal key looks like this:
+In ASCII-armored representation, this very minimal key appears as follows:
 
 ```text
 -----BEGIN PGP PUBLIC KEY BLOCK-----
@@ -99,18 +107,20 @@ gAIl6FM5SWuQxg12j0S07ExCOI5NPRDCrSnAV85mAXOzeIGeiVLPQ40oEal3CX/L
 -----END PGP PUBLIC KEY BLOCK-----
 ```
 
-We'll now decode this OpenPGP data, and inspect the two packets in detail.
+The output of `sq` is presented as a block of text. We will now decode this OpenPGP data and inspect the two packets it contains.
 
-To inspect the internal structure of the OpenPGP data, we run the Sequoia-PGP tool `sq`, using the `packet dump` subcommand. The output of `sq` is one block of text, but to discuss the content of each packet we'll break the output up into sections here:
+To achieve this, we will use the Sequoia-PGP tool `sq` and run the `packet dump` subcommand:
 
 ```text
 $ sq packet dump --hex alice_minimal.pub
 ```
 
+This will allow us to gain a detailed understanding of the packet contents.
+
 (public_key)=
 ### Public-Key packet
 
-The output now starts with a (primary) [Public-Key packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-public-key-packet-formats):
+The output begins with a (primary) [Public-Key packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-public-key-packet-formats):
 
 ```text
 Public-Key Packet, new CTB, 2 header bytes + 42 bytes
@@ -132,23 +142,23 @@ Public-Key Packet, new CTB, 2 header bytes + 42 bytes
     00000020  eb e7 42 e2 ab 47 f4 86  b3 ae 65 3e
 ```
 
-The Public-Key packet consists in large part of the actual cryptographic key data. Let's look at the packet field by field:
+The Public-Key packet consists primarily of the cryptographic key data. Let's look at the packet field by field:
 
-- `CTB: 0xc6`[^CTB]: The [packet type ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-packet-headers) for this packet. The binary representation of the value `0xc6` is `11000110`. Bits 7 and 6 show that the packet is in *OpenPGP packet format* (as opposed to in *Legacy packet format*). The remaining 6 bits encode the type ID's value: "6". This is the value for a Public-Key packet, as shown in the list of [packet type IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-packet-tags).
-- `length: 0x2a`: The remaining length of this packet.
+- `CTB: 0xc6`[^CTB]: This is the [packet type ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-packet-headers) for this packet. The binary representation of the value `0xc6` is `11000110`. The first two bits show that the packet is in *OpenPGP packet format* (as opposed to in *Legacy packet format*) and the remaining 6 bits encode the type ID value, which is "6." This type ID value corresponds to a Public-Key packet, as listed in the [packet type IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-packet-tags).
 
-The packet type id defines the semantics of the remaining data in the packet. We're looking at a Public-Key packet, which is a kind of [Key Material Packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-key-material-packets).
+- `length: 0x2a`: This indicates the remaining length of this packet. The packet type ID defines the semantics of the remaining data within the packet. In this case, it is a Public-Key packet, which is a kind of [Key Material Packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-key-material-packets).
 
-- `version: 0x06`: The key material is in version 6 format
+- `version: 0x06`: The key material is in version 6 format. This means that the next part of the packet adheres to the structure of [Version 6 Public Keys](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-version-6-public-keys).
 
-This means that the next part of the packet follows the structure of [Version 6 Public Keys](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-version-6-public-keys)
+- `creation_time: 0x6516eaa6`: This field represents the key's creation time. (See also [Time Fields](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-time-fields)).
 
-- `creation_time: 0x6516eaa6`: "The time that the key was created" (also see [Time Fields](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-time-fields))
-- `pk_algo: 0x1b`: "The public-key algorithm ID of this key" (decimal value 27, see the list of [Public-Key Algorithms](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-public-key-algorithms))
-- `public_len: 0x00000020`: "Octet count for the following public key material" (in this case, the length of the following `ed25519_public` field)
-- `ed25519_public`: [Algorithm-specific representation](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-part-for-ed2) of the public key material (the format is based on the value of `pk_algo`), in this case 32 bytes of Ed25519 public key
+- `pk_algo: 0x1b`: This corresponds to the key's public-key algorithm ID, which has a decimal value of 27. Refer to the list of [Public-Key Algorithms](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-public-key-algorithms)) for more details.
 
-[^CTB]: Sequoia uses the term CTB (Cipher Type Byte) to refer to the RFC's [packet type ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-packet-headers). In previous versions, the RFC called this field "Packet Tag".
+- `public_len: 0x00000020`: This section specifies the octet count for the subsequent public key material. In this case, it represents the length of the following `ed25519_public` field.
+
+- `ed25519_public`: This is the [algorithm-specific representation](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-part-for-ed2) of the public key material. The format is based on the value of `pk_algo`, which, in this case, is 32 bytes of Ed25519 public key data.
+
+[^CTB]: Sequoia uses the term CTB (Cipher Type Byte) to refer to the RFC's [packet type ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-packet-headers). In earlier RFC versions, this field was known as the "Packet Tag."
 
 ```{tip}
 
@@ -160,9 +170,9 @@ Note that the *Public-Key packet* contains only the public part of the key.
 (zooming_in_dks)=
 ### Direct Key Signature
 
-The next packet is a [*Direct Key Signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-direct-key), which is bound to the primary key (the file `alice.pub-1--Signature` contains this packet).
+The next packet in the certificate is a [*Direct Key Signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-direct-key), which plays a crucial role in binding specific information to the primary key. This signature is contained within the file `alice.pub-1--Signature`.
 
-This packet "binds the information in the signature subpackets to the key". Each entry under "Signature Packet -> Hashed area" is one signature subpacket, for example, including information about algorithm preferences (*symmetric algorithm preference* and *hash algorithm preferences*).
+This packet binds the information within the signature subpackets with the primary key. Each entry under "Signature Packet -> Hashed area" is one signature subpacket, for example, including information about algorithm preferences (*symmetric algorithm preference* and *hash algorithm preferences*).
 
 ```text
 Signature Packet, new CTB, 2 header bytes + 182 bytes

From 6283630e6c54755166791462e59918e0514937e0 Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Fri, 27 Oct 2023 09:45:26 +0200
Subject: [PATCH 02/26] edits to ch17 field-by-field explainer

---
 book/source/17-zoom_certificates.md | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index d4d123a..6d35cd3 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -172,7 +172,7 @@ Note that the *Public-Key packet* contains only the public part of the key.
 
 The next packet in the certificate is a [*Direct Key Signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-direct-key), which plays a crucial role in binding specific information to the primary key. This signature is contained within the file `alice.pub-1--Signature`.
 
-This packet binds the information within the signature subpackets with the primary key. Each entry under "Signature Packet -> Hashed area" is one signature subpacket, for example, including information about algorithm preferences (*symmetric algorithm preference* and *hash algorithm preferences*).
+This packet binds the data within the signature subpackets with the primary key. Each entry under "Signature Packet -> Hashed area" represents one signature subpacket, providing essential information such as  algorithm preferences, including *symmetric algorithm preference* and *hash algorithm preferences*.
 
 ```text
 Signature Packet, new CTB, 2 header bytes + 182 bytes
@@ -242,18 +242,23 @@ Signature Packet, new CTB, 2 header bytes + 182 bytes
     000000b0  54 01 f9 5f 81 41 90 0e
 ```
 
-Let’s look at the packet field by field:
+Let’s examine the packet field by field:
 
-- `CTB: 0xc2`: The Packet type ID for this packet. Bits 7 and 6 show that the packet is in “OpenPGP packet format” (as opposed to in “Legacy packet format”). The remaining 6 bits encode the type ID’s value: “2.” This is the value for a Signature packet.
-- `length: 0xb6`: The remaining length of this packet.
+- `CTB: 0xc2`: This field indicates the Packet type ID for this packet. Bits 7 and 6 show that the packet is in “OpenPGP packet format.” The remaining 6 bits encode the type ID’s value, which is “2” for a Signature packet.
 
-The packet type ID defines the semantics of the remaining data in the packet. We're looking at a [Signature packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#signature-packet), so the following data is interpreted accordingly.
+The packet type ID (`0xc2`) defines the semantics of the remaining data in the packet. In this case, as it indicates a [Signature packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#signature-packet), the following data is specific to this signature type.
 
-- `version: 0x06`: This is a version 6 signature (some of the following packet format is specific to this signature version).
-- `type: 0x1f`: The [Signature Type](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-signature-types)
-- `pk_algo: 0x1b`: Public-key algorithm ID (decimal 27, corresponds to [Ed25519](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-public-key-algorithms))
-- `hash_algo: 0x0a`: Hash algorithm ID (decimal 10, corresponds to [SHA2-512](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-hash-algorithms))
-- `hashed_area_len: 0x0000003d`: Length of the following hashed subpacket data
+- `length: 0xb6`: This field shows the remaining length of this packet. 
+
+- `version: 0x06`: This is a version 6 signature.
+
+- `type: 0x1f`: This indicates the [Signature Type](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-signature-types).
+
+- `pk_algo: 0x1b`: This specifies the Public-Key algorithm ID. In this case, decimal 27 corresponds to [Ed25519](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-public-key-algorithms)).
+
+- `hash_algo: 0x0a`: This specifies the hash algorithm ID. In this case, decimal 10 corresponds to [SHA2-512](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-hash-algorithms)).
+
+- `hashed_area_len: 0x0000003d`: This specifies the length of the following hashed subpacket data.
 
 The next part of this packet contains hashed subpacket data. A subpacket data set in an OpenPGP Signature contains a list of zero or more Signature subpackets.
 

From 199d0bb5e8bf42215ee41b8fb0463146f688e0ec Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Fri, 27 Oct 2023 11:05:18 +0200
Subject: [PATCH 03/26] reformat subpacket details to ease comprehension

---
 book/source/17-zoom_certificates.md | 70 ++++++++++++++++++++++-------
 1 file changed, 55 insertions(+), 15 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 6d35cd3..44a52ac 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -172,7 +172,7 @@ Note that the *Public-Key packet* contains only the public part of the key.
 
 The next packet in the certificate is a [*Direct Key Signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-direct-key), which plays a crucial role in binding specific information to the primary key. This signature is contained within the file `alice.pub-1--Signature`.
 
-This packet binds the data within the signature subpackets with the primary key. Each entry under "Signature Packet -> Hashed area" represents one signature subpacket, providing essential information such as  algorithm preferences, including *symmetric algorithm preference* and *hash algorithm preferences*.
+This packet binds the data within the signature subpackets with the primary key. Each entry under "Signature Packet -> Hashed area" is one signature subpacket, providing essential information such as algorithm preferences, including *symmetric algorithm preference* and *hash algorithm preferences*.
 
 ```text
 Signature Packet, new CTB, 2 header bytes + 182 bytes
@@ -242,7 +242,7 @@ Signature Packet, new CTB, 2 header bytes + 182 bytes
     000000b0  54 01 f9 5f 81 41 90 0e
 ```
 
-Let’s examine the packet field by field:
+Below is a field-by-field examination of the packet:
 
 - `CTB: 0xc2`: This field indicates the Packet type ID for this packet. Bits 7 and 6 show that the packet is in “OpenPGP packet format.” The remaining 6 bits encode the type ID’s value, which is “2” for a Signature packet.
 
@@ -254,29 +254,69 @@ The packet type ID (`0xc2`) defines the semantics of the remaining data in the p
 
 - `type: 0x1f`: This indicates the [Signature Type](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-signature-types).
 
-- `pk_algo: 0x1b`: This specifies the Public-Key algorithm ID. In this case, decimal 27 corresponds to [Ed25519](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-public-key-algorithms)).
+- `pk_algo: 0x1b`: This specifies the Public-Key algorithm ID, with decimal 27 corresponding to [Ed25519](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-public-key-algorithms)).
 
-- `hash_algo: 0x0a`: This specifies the hash algorithm ID. In this case, decimal 10 corresponds to [SHA2-512](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-hash-algorithms)).
+- `hash_algo: 0x0a`: This specifies the hash algorithm ID, with decimal 10 corresponding to [SHA2-512](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-hash-algorithms)).
 
 - `hashed_area_len: 0x0000003d`: This specifies the length of the following hashed subpacket data.
 
-The next part of this packet contains hashed subpacket data. A subpacket data set in an OpenPGP Signature contains a list of zero or more Signature subpackets.
+The next segment of this packet contains the hashed subpacket data. 
 
-There are two sets of subpacket data in a Signature: hashed, and unhashed. The difference is that the hashed subpackets are protected by the digital signature of this packet, while the unhashed subpackets are not.
+In OpenPGP Signatures, there are two sets of subpacket data: hashed and unhashed. Hashed subpackets are protected by the digital signature of the packet, while unhashed subpackets are not.
 
-The following subpacket data consists of sets of "subpacket length, subpacket type ID, data." We'll show the information for each subpacket as one line, starting with the [subpacket type description](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-signature-subpacket-specifi) (based on the subpacket type ID). Note that bit 7 of the subpacket type ID signals if that subpacket is ["critical"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#section-5.2.3.7-10).
+A subpacket data set in an OpenPGP Signature contains a list of zero or more Signature subpackets.
+
+
+The following subpacket data consists of sets of "subpacket length, subpacket type ID, data." Each subpacket is displayed as one line, starting with the [subpacket type description](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-signature-subpacket-specifi) (based on the subpacket type ID). Note that bit 7 of the subpacket type ID signals if that subpacket is ["critical."](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#section-5.2.3.7-10)
 
 ```{note}
-Critical here means: the receiver must be able to interpret the subpacket and is expected to fail, otherwise. Non-critical subpackets may be ignored by the receiver.
+Critical here means that the receiver must interpret the subpacket and is expected to fail, otherwise. Non-critical subpackets may be ignored by the receiver.
 ```
 
-- [Signature creation time](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#signature-creation-subpacket) (subpacket type 2, **critical**): `0x6516eaa6` (also see [Time Fields](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-time-fields))
-- [Key expiration time](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#key-expiration-subpacket) (subpacket type 9, **critical**): `0x05a48fbd` (defined as number of seconds after the key creation time)
-- [Preferred symmetric ciphers for v1 SEIPD](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#preferred-v1-seipd) (type 11): `0x09 0x07`. (These values [correspond to](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#symmetric-algos): *AES with 256-bit key* and *AES with 128-bit key*)
-- [Preferred hash algorithms](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#preferred-hashes-subpacket) (subpacket type 21): `0x0a 0x08`. (These values [correspond to](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-hash-algorithms): *SHA2-512* and *SHA2-256*)
-- [Key flags](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#key-flags) (subpacket type 27, **critical**): `0x01`. (This value [corresponds](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-key-flags) to the *certifications* key flag)
-- [Features](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#features-subpacket) (subpacket type 30): `0x01`. (This value [corresponds](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-features) to: *Symmetrically Encrypted Integrity Protected Data packet version 1*)
-- [Issuer fingerprint](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#issuer-fingerprint-subpacket) (subpacket type 33): `aaa18cbb254685c58358320563fd37b67f3300f9fb0ec457378cd29f102698b3` (this is the fingerprint of the component key that issued the signature in this packet. Not that here, the value is the primary key fingerprint of the certificate we're looking at.)
+The subpacket details are as follows:
+
+- [**Signature Creation Time**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#signature-creation-subpacket)
+  - Type: `2`
+  - Critical: `Yes`
+  - Value: `0x6516eaa6`
+  - Notes: See also [Time Fields](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-time-fields).
+
+- [**Key Expiration Time**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#key-expiration-subpacket)
+  - Type: `9`
+  - Critical: `Yes`
+  - Value: `0x05a48fbd`
+  - Notes: Defined as number of seconds after the key creation time.
+
+- [**Preferred Symmetric Ciphers for v1 SEIPD**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#preferred-v1-seipd)
+  - Type: `11`
+  - Critical: `No`
+  - Value: `0x09 0x07`
+  - Notes: Values correspond to *AES with 256-bit key* and *AES with 128-bit key*.
+
+- [**Preferred Hash Algorithms**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#preferred-hashes-subpacket)
+  - Type: `21`
+  - Critical: `No`
+  - Value: `0x0a 0x08`
+  - Notes: Values correspond to *SHA2-512* and *SHA2-256*.
+
+- [**Key Flags**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#key-flags)
+  - Type: `27`
+  - Critical: `Yes`
+  - Value: `0x01`
+  - Notes: Value corresponds to the *certifications* key flag.
+
+- [**Features**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#features-subpacket)
+  - Type: `30`
+  - Critical: `No`
+  - Value: `0x01`
+  - Notes: Value corresponds to: *Symmetrically Encrypted Integrity Protected Data packet version 1*.
+
+- [**Issuer Fingerprint**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#issuer-fingerprint-subpacket)
+  - Type: `33`
+  - Critical: `No`
+  - Value: `aaa18cbb254685c58358320563fd37b67f3300f9fb0ec457378cd29f102698b3`
+  - Notes: This is the fingerprint of the component key that issued the signature in this packet. Note that here, the value is the primary key fingerprint of the certificate we're looking at.
+
 
 The next part of this packet contains "unhashed subpacket data":
 

From c8b417ccdbbfb45310e84d59e7c3fc4c5e1bd59a Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Fri, 27 Oct 2023 11:59:39 +0200
Subject: [PATCH 04/26] finish direct key signature section

---
 book/source/17-zoom_certificates.md | 39 +++++++++++++++++------------
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 44a52ac..9ba1c4a 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -285,13 +285,13 @@ The subpacket details are as follows:
   - Type: `9`
   - Critical: `Yes`
   - Value: `0x05a48fbd`
-  - Notes: Defined as number of seconds after the key creation time.
+  - Notes: Defined as number of seconds after the key creation time
 
 - [**Preferred Symmetric Ciphers for v1 SEIPD**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#preferred-v1-seipd)
   - Type: `11`
   - Critical: `No`
   - Value: `0x09 0x07`
-  - Notes: Values correspond to *AES with 256-bit key* and *AES with 128-bit key*.
+  - Notes: Values correspond to *AES with 256-bit key* and *AES with 128-bit key*
 
 - [**Preferred Hash Algorithms**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#preferred-hashes-subpacket)
   - Type: `21`
@@ -309,34 +309,41 @@ The subpacket details are as follows:
   - Type: `30`
   - Critical: `No`
   - Value: `0x01`
-  - Notes: Value corresponds to: *Symmetrically Encrypted Integrity Protected Data packet version 1*.
+  - Notes: Value corresponds to *Symmetrically Encrypted Integrity Protected Data packet version 1*
 
 - [**Issuer Fingerprint**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#issuer-fingerprint-subpacket)
   - Type: `33`
   - Critical: `No`
   - Value: `aaa18cbb254685c58358320563fd37b67f3300f9fb0ec457378cd29f102698b3`
-  - Notes: This is the fingerprint of the component key that issued the signature in this packet. Note that here, the value is the primary key fingerprint of the certificate we're looking at.
+  - Notes: The fingerprint identifoes the component key that issued the signature in this packet. In this instance, the value is the primary key fingerprint of the certificate we're looking at.
 
+The next part of this packet contains unhashed subpacket data:
 
-The next part of this packet contains "unhashed subpacket data":
+- `unhashed_area_len: 0x0000000a`: length of the following unhashed subpacket data (value: 10 bytes).
 
-- `unhashed_area_len: 0x0000000a`: Length of the following unhashed subpacket data (value: 10 bytes).
+As above, the following subpacket data consists of sets of subpacket length, subpacket type id, and data. In this case, only one subpacket follows:
 
-As above, the following subpacket data consists of sets of "subpacket length, subpacket type id, data." In this case, only subpacket follows:
-
-- [Issuer Key ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#issuer-keyid-subpacket) (subpacket type 16): `aaa18cbb254685c5` (this is the shortened version 6 *Key ID* of the fingerprint of this certificate's primary key)
+- [**Issuer Key ID**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#issuer-keyid-subpacket)
+  - Type: `16`
+  - Critical: `No`
+  - Value: `aaa18cbb254685c5`
+  - Notes: This is the shortened version 6 *Key ID* of the fingerprint of this certificate's primary key.
 
 This concludes the unhashed subpacket data.
 
-- `digest_prefix: 0x6747`: "The left 16 bits of the signed hash value"
-- `salt_len, salt`: A random [salt value](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-advantages-of-salted-signat) (the size must be [matching for the hash algorithm](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#hash-algorithms-registry))
-- `ed25519_sig`: [Algorithm-specific](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-fields-for-ed2) representation of the signature (in this case: 64 bytes of Ed25519 signature)
+This next section shows additional components of the Direct Key Signature packet:
 
-The signature is calculated over a hash. The hash, in this case, is calculated over the following data (for details, see [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-computing-signatures) in the RFC):
+- `digest_prefix: 0x6747`: the left 16 bits of the signed hash value
 
-- The signature's salt
-- A serialized form of the primary key's public data
-- A serialized form of this direct key signature packet (up to, but excluding the unhashed area)
+- `salt_len, salt`: a random [salt value](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-advantages-of-salted-signat) with size [matching the hash algorithm](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#hash-algorithms-registry))
+
+- `ed25519_sig`: [algorithm-specific](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-fields-for-ed2) representation of the signature (here: 64 bytes of Ed25519 signature)
+
+The signature's hash is calculated over the following data (see [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-computing-signatures) in the RFC):
+
+- signature's salt
+- serialized primary key's public data
+- serialized direct key signature packet (excluding the unhashed area)
 
 
 (zoom_enc_subkey)=

From 1f8411caa66d537a49efed7bfc88b9d93d458265 Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Fri, 27 Oct 2023 14:17:25 +0200
Subject: [PATCH 05/26] edit encryption subkey

---
 book/source/17-zoom_certificates.md | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 9ba1c4a..68f1d3a 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -345,27 +345,26 @@ The signature's hash is calculated over the following data (see [Computing Signa
 - serialized primary key's public data
 - serialized direct key signature packet (excluding the unhashed area)
 
-
 (zoom_enc_subkey)=
 ## Encryption subkey
 
-Now we'll look at a subkey in Alice's certificate. An OpenPGP subkey, when it is linked to an OpenPGP certificate (via its primary key), consists of two elements:
+Let's now look at a subkey in Alice's OpenPGP certificate. A subkey, when linked to an OpenPGP certificate via its primary key, consists of two elements:
 
 - a key packet that contains the component key itself, and
-- a signature packet that links this component key to the primary key (and thus implicitly to the full OpenPGP certificate).
+- a signature packet that links this component key to the primary key and, implicitly, to the full OpenPGP certificate.
 
-In this section, we'll use the files that contain individual packets of Alice's certificate, which we split apart above. In this split representation of Alice's certificate, the encryption subkey happens to be stored in `alice.pub-4--PublicSubkey`, and the associated binding self-signature for the subkey in `alice.pub-5--Signature`.
+We will use the files containing individual packets of Alice's certificate, which we separated above. In this split representation, the encryption subkey is stored in `alice.pub-4--PublicSubkey`, while the associated binding self-signature is stored in `alice.pub-5--Signature`.
 
 ````{note}
-It's common to look at a packet dump for a full OpenPGP certificate, like this:
+It's common to look at a packet dump for a full OpenPGP certificate as shown below:
 
 ```text
 $ sq packet dump --hex alice.pub
 ```
 
-That command shows the details for the full series of packets in an OpenPGP certificate (recall the list of [packets of Alice's certificate](split_alice)). Finding a particular packet in that list can take a bit of focus and practice though.
+This command shows the details for the full series of packets in an OpenPGP certificate (refer to the list of [packets of Alice's certificate](split_alice)). Finding a particular packet in that list can take a bit of focus and practice though.
 
-In the following sections we're making it a bit easier for ourselves, and directly look at individual packets, from the files we created with `sq packet split`, above.
+In the following sections,we make it easier for ourselves by directly examining individual packets from the files we created with `sq packet split` above.
 ````
 
 ### Public-Subkey packet

From fb24639ea19a72d64ba6266440a2af454601bcc8 Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Fri, 27 Oct 2023 14:37:26 +0200
Subject: [PATCH 06/26] edit Public-Subkey packet

---
 book/source/17-zoom_certificates.md | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 68f1d3a..d35f8bb 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -369,7 +369,7 @@ In the following sections,we make it easier for ourselves by directly examining
 
 ### Public-Subkey packet
 
-First, we'll look at the *Public-Subkey packet* that contains the component key data of this subkey:
+We'll now look at the *Public-Subkey packet* that contains the component key data of this subkey:
 
 ```text
 $ sq packet dump --hex alice.pub-4--PublicSubkey
@@ -392,11 +392,12 @@ Public-Subkey Packet, new CTB, 2 header bytes + 42 bytes
   00000020  35 2a 46 01 f3 cc 00 f5  4a 09 3e 3f
 ```
 
-Notice that the structure of this *Public-Subkey packet* is the same as the *Public-Key Packet* of the primary key, [above](public_key). Only the content of the two packets differs in some points:
+Notice that the structure of this *Public-Subkey packet* mirrors the primary key's [*Public-Key packet*](public_key) above. However, there are notable differences between the two packets:
 
 - The packet type ID (`CTB`) in this packet shows type 14 ([*Public-Subkey packet*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-public-subkey-packet-tag-14)).
-- The `pk_algo` value is set to `0x19` (decimal 25), which [corresponds to](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-public-key-algorithms) X25519. Note that even though both the primary key and this subkey use a cryptographic mechanism based on Curve25519, this encryption key uses Curve 25519 in a different way (X25519 is a Diffie–Hellman function built out of Curve25519).
-- Accordingly, the public part of the cryptographic key pair is labeled with the corresponding name: `x25519_public`  (however, note that this difference only reflects the semantics of the field, which is implied by the value of `pk_algo`. The actual data consists of just 32 bytes of cryptographic key material, without any type information.)
+
+- The `pk_algo` value is set to `0x19` (decimal 25), which [corresponds to X25519](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-public-key-algorithms). Notably, though both the primary key and this subkey use a cryptographic mechanism based on Curve25519, the encryption key uses Curve 25519 in a different way: namely, X25519 is a Diffie–Hellman function constructed from Curve25519.
+- Accordingly, the public part of the cryptographic key pair is labeled `x25519_public`, as implied by the value (`0x19`) of `pk_algo`. However, the actual data is just 32 bytes of cryptographic key material, without any type information.
 
 ### Subkey binding signature
 

From b6da12d0eeb22a4a359f47f24673ecb02caf4d3f Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Fri, 27 Oct 2023 14:55:17 +0200
Subject: [PATCH 07/26] edit part 1 of subkey binding signature

---
 book/source/17-zoom_certificates.md | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index d35f8bb..3bcf2de 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -401,9 +401,9 @@ Notice that the structure of this *Public-Subkey packet* mirrors the primary key
 
 ### Subkey binding signature
 
-The subkey packet above by itself is disconnected from the OpenPGP certificate that it is a part of. The link between the subkey and the full OpenPGP key is made with a cryptographic signature, which is issued by the OpenPGP key's primary key.
+The aforementioned subkey packet is disconnected from the OpenPGP certificate to which it belongs. The link between the subkey and the complete OpenPGP key is made with a cryptographic signature, generated by primary key of the OpenPGP certificate.
 
-The type of signature that is used for this is called a *subkey binding signature*, because it "binds" (as in "connects") the subkey to the rest of the key.
+The type of signature is called a *subkey binding signature*, because it "binds" or connects the subkey to the rest of the key.
 
 ```{admonition} VISUAL
 :class: warning
@@ -420,9 +420,10 @@ Should this text go elsewhere?
 - 4.2.3?
 - ch 6?
 ```
-In addition to its core purpose of making the connection, this signature also contains additional metadata about the subkey. One reason why this metadata is in a binding signature (and not in the subkey packet) is that it may change over time. The subkey packet itself may not change over time. So metadata about the subkey that can change is stored in self-signatures: if the key holder wants to change some metadata (for example, the key's expiration time), they can issue a newer version of the same kind of signature. Receiving OpenPGP software will then understand that the newer self-signature supersedes the older signature, and that the metadata in the newer signature reflects the most current intent of the key holder.
 
-Note that this subkey binding signature packet is quite similar to the Direct Key Signature we discussed packet above. Both signatures perform the same function in terms of adding metadata to a component key. In particular, the hashed subpacket data contains many of the same pieces of metadata.
+The signature does more than just bind the subkey; it also carries additional metadata about the subkey. This metadata is in the binding signature, and not in the subkey packet, because it may change over time, while the subkey packet itself remains unchanged. This evolving metadata is stored in self-signatures: if the key holder wants to modify the metadata (for example, to change the key's expiration time), a newer version of the same signature type can be issued. The recipient OpenPGP software will recognize that the newer self-signature supersedes the older one, and that the metadata in the newer signature reflects the most current intent of the key holder.
+
+Note that this subkey binding signature packet is quite similar to the Direct Key Signature discussed above. Both signatures serve a similar purpose in adding metadata to a component key, particularly as the hashed subpacket data contains much of the metadata elements.
 
 ```text
 $ sq packet dump --hex alice.pub-5--Signature

From c2405f53efccfa30319dcfc599779af54ccffbd3 Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Fri, 27 Oct 2023 15:01:20 +0200
Subject: [PATCH 08/26] edit next part of subkex binding signature

---
 book/source/17-zoom_certificates.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 3bcf2de..b25c5a4 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -481,11 +481,11 @@ Signature Packet, new CTB, 2 header bytes + 171 bytes
     000000a0  41 36 1b 2b 60 09 f2 d9  19 f4 41 12 0b
 ```
 
-We'll go over this packet dump in less detail, since its structure mirrors the *Direct Key Signature* (described above) very closely.
+The analysis of this packet dump will be less extensive, given that its structure mirrors the *Direct Key Signature* explored above.
 
-The first difference is in the `type` field, showing that this signature is of type `0x18` ([Subkey Binding Signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-subkey-binding-signature-si)).
+One notable difference is the `type` field, showing that this signature is of type `0x18` ([Subkey Binding Signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-subkey-binding-signature-si)).
 
-The `pk_algo` of this signature is informed by the algorithm of the primary key (`0x1b`, corresponding to Ed25519). The signature in this packet is issued by the primary key, so by definition it uses the signing algorithm of the primary key (that is: the algorithm used to produce the cryptographic signature in this packet is entire independent of the `pk_algo` of the key material of this subkey itself, which uses the X25519 mechanism).
+The `pk_algo` value of this signature derives from the algorithm of the primary key (`0x1b`, corresponding to Ed25519). This signature is issued by the primary key, thus using the signing algorithm of the primary key. (The algorithm used to produce the cryptographic signature in this packet is entirely independent of the `pk_algo` of the key material of this subkey itself, which uses the X25519 mechanism.)
 
 As shown in the text at the top of this packet dump, the hashed subpacket data contains four pieces of information:
 

From 63fbd49dcf9317e5e51e0729c8aff49562ca55c4 Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Fri, 27 Oct 2023 16:20:48 +0200
Subject: [PATCH 09/26] edit subkey binding signature, correct comma placement

---
 book/source/17-zoom_certificates.md | 39 ++++++++++++++++-------------
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index b25c5a4..75da873 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -266,7 +266,6 @@ In OpenPGP Signatures, there are two sets of subpacket data: hashed and unhashed
 
 A subpacket data set in an OpenPGP Signature contains a list of zero or more Signature subpackets.
 
-
 The following subpacket data consists of sets of "subpacket length, subpacket type ID, data." Each subpacket is displayed as one line, starting with the [subpacket type description](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-signature-subpacket-specifi) (based on the subpacket type ID). Note that bit 7 of the subpacket type ID signals if that subpacket is ["critical."](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#section-5.2.3.7-10)
 
 ```{note}
@@ -339,11 +338,13 @@ This next section shows additional components of the Direct Key Signature packet
 
 - `ed25519_sig`: [algorithm-specific](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-fields-for-ed2) representation of the signature (here: 64 bytes of Ed25519 signature)
 
-The signature's hash is calculated over the following data (see [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-computing-signatures) in the RFC):
+The signature's hash is calculated from the following data:
 
-- signature's salt
-- serialized primary key's public data
-- serialized direct key signature packet (excluding the unhashed area)
+- the signature's salt
+- the serialized primary key's public data
+- the serialized direct key signature packet (excluding the unhashed area)
+
+Refer to [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-computing-signatures) in the RFC for more details.
 
 (zoom_enc_subkey)=
 ## Encryption subkey
@@ -489,22 +490,24 @@ The `pk_algo` value of this signature derives from the algorithm of the primary
 
 As shown in the text at the top of this packet dump, the hashed subpacket data contains four pieces of information:
 
-- Signature creation time: `2023-09-29 15:17:58 UTC` (**critical**)
-- Key expiration time: `P1095DT62781S` (**critical**)
-- Key flags: `EtEr` (**critical**) (encryption for communication, encryption for storage)
-- Issuer Fingerprint: `AAA18CBB254685C58358320563FD37B67F3300F9FB0EC457378CD29F102698B3`
+- signature creation time: `2023-09-29 15:17:58 UTC` (**critical**)
+- key expiration time: `P1095DT62781S` (**critical**)
+- key flags: `EtEr` (**critical**) (encryption for communication, encryption for storage)
+- issuer fingerprint: `AAA18CBB254685C58358320563FD37B67F3300F9FB0EC457378CD29F102698B3`
 
-The remainder of the packet has the same content as the *Direct Key Signature* above:
-- A 16 bit digest prefix
-- A salt value
-- The cryptographic signature itself
+The rest of the packet mirrors the *Direct Key Signature* discussed above:
+- a 16-bit digest prefix
+- a salt value 
+- the cryptographic signature itself
 
-The signature is calculated over a hash. The hash, in this case, is calculated over the following data (for details, see [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-computing-signatures) in the RFC):
+The signature is calculated over a hash. In this case, the hash is derived from the following data:
 
-- The signature's salt
-- A serialized form of the primary key's public data
-- A serialized form of the subkey's public data
-- A serialized form of this subkey binding signature packet (up to, but excluding the unhashed area)
+- the signature's salt 
+- the serialized primary key's public data 
+- the serialized subkey's public data
+- the serialized subkey binding signature packet (excluding the unhashed area)
+
+Refer to [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-computing-signatures) in the RFC for details.
 
 ## Signing subkey
 

From 580325dca49a76d785f1ea00f84ef8f70f595bb5 Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Fri, 27 Oct 2023 16:33:45 +0200
Subject: [PATCH 10/26] edit ## Adding an identity component

---
 book/source/17-zoom_certificates.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 75da873..3bd787f 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -624,11 +624,11 @@ Signature Packet, new CTB, 3 header bytes + 325 bytes
 (zooming_in_user_id)=
 ## Adding an identity component
 
-Now we'll look at an identity that is associated with Alice's certificate.
+In this section, we'll look at an identity associated with Alice's certificate.
 
-User IDs are a mechanism for connecting [identities](identity_components) with an OpenPGP certificate. Traditionally, User IDs contain a string that combines a name and an email address.
+User IDs are a mechanism for connecting [identities](identity_components) with an OpenPGP certificate. Typically, a User ID is a string combining a name and an email address.
 
-Like [above](zoom_enc_subkey), to look at the internal packet structure of this identity and its connection the OpenPGP certificate, we'll inspect the two individual packets that constitute the identity component, the [User ID packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-id-packet-tag-13), in the file `alice.pub-2--UserID`, and the certifying self-signature a [Positive certification of a User ID and Public-Key packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-positive-certification-of-a) in `alice.pub-3--Signature` (these packets are an excerpt of Alice's full OpenPGP private key).
+To understand the internal packet structure of this identity and its connection to the OpenPGP certificate, we'll examine two packets that constitute the identity component. One is the [User ID packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-id-packet-tag-13), located in the file `alice.pub-2--UserID`, which contains identity information. The other is a  certifying self-signature, specifically a [Positive certification of a User ID and Public-Key packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-positive-certification-of-a) located in the file `alice.pub-3--Signature`. This certification, issued after substantial verification of the identity claim, validates the association between the User ID and the certificate's public key. These packets are snippets from Alice's full OpenPGP private key.
 
 ### User ID packet
 

From a2b8f75ea299b0ceffea77d0dcf3081500d2d198 Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Fri, 27 Oct 2023 16:45:41 +0200
Subject: [PATCH 11/26] edit User ID packet

---
 book/source/17-zoom_certificates.md | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 3bd787f..ba6f8ab 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -632,7 +632,7 @@ To understand the internal packet structure of this identity and its connection
 
 ### User ID packet
 
-First, let's look at the User ID packet, which encodes an identity that Alice has connected to her OpenPGP certificate:
+First, let's look at the User ID packet, which encodes an identity that is associated with an OpenPGP certificate:
 
 ```text
 $ sq packet dump --hex alice.pub-2--UserID
@@ -645,11 +645,13 @@ User ID Packet, new CTB, 2 header bytes + 19 bytes
     00000010  2e 6f 72 67 3e
 ```
 
-- `CTB: 0xcd`: The Packet type ID for this packet. Bits 7 and 6 show that the packet is in “OpenPGP packet format” (as opposed to in “Legacy packet format”). The remaining 6 bits encode the type ID’s value: “13.” This is the value for a [User ID packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-id-packet-tag-13).
-- `length: 0x13`: The remaining length of this packet (here: 19 bytes).
-- `value`: 19 bytes of data that contain UTF-8 encoded text. The value corresponds to the string `<alice@example.org>`. With this identity component, Alice states that she uses (and has control of) this email address. Note that the email address is enclosed in `<` and `>` characters, following [RFC 2822](https://www.rfc-editor.org/rfc/rfc2822) conventions.
+- `CTB: 0xcd`: This is the Packet Type ID for this packet. Bits 7 and 6 show that the packet is in “OpenPGP packet format” (not “Legacy packet format”). The remaining 6 bits encode the type ID’s value: “13,” which is the value for a [User ID packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-id-packet-tag-13).
 
-So, a User ID packet is really just a string, marked as a User ID by the packet type id.
+- `length: 0x13`: This field shows the remaining length of the packet (here: 19 bytes).
+
+- `value`: This comprises 19 bytes of data that contain UTF-8 encoded text. The value corresponds to the string `<alice@example.org>`. With this identity component, Alice asserts usage and control over the specified email address. Note that the email address is enclosed in `<` and `>` characters, in line with the conventions of  [RFC 2822](https://www.rfc-editor.org/rfc/rfc2822).
+
+Essentially, a User ID packet is just a string marked as a User ID by the packet type ID.
 
 ### Linking the User ID with a certification self-signature
 

From a487db69964830747324709d84c98b659993b883 Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Fri, 27 Oct 2023 16:46:14 +0200
Subject: [PATCH 12/26] correct packet type ID capitalization

---
 book/source/17-zoom_certificates.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index ba6f8ab..3bdffa5 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -645,7 +645,7 @@ User ID Packet, new CTB, 2 header bytes + 19 bytes
     00000010  2e 6f 72 67 3e
 ```
 
-- `CTB: 0xcd`: This is the Packet Type ID for this packet. Bits 7 and 6 show that the packet is in “OpenPGP packet format” (not “Legacy packet format”). The remaining 6 bits encode the type ID’s value: “13,” which is the value for a [User ID packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-id-packet-tag-13).
+- `CTB: 0xcd`: This is the packet type ID for this packet. Bits 7 and 6 show that the packet is in “OpenPGP packet format” (not “Legacy packet format”). The remaining 6 bits encode the type ID’s value: “13,” which is the value for a [User ID packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-id-packet-tag-13).
 
 - `length: 0x13`: This field shows the remaining length of the packet (here: 19 bytes).
 

From 05d2e15feeb02e97102e58465ca4e18e9679266c Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Fri, 27 Oct 2023 17:17:47 +0200
Subject: [PATCH 13/26] finish current version of ch17, UserID+certification
 self-sig

---
 book/source/17-zoom_certificates.md | 36 +++++++++++++++--------------
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 3bdffa5..34125ec 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -655,9 +655,9 @@ Essentially, a User ID packet is just a string marked as a User ID by the packet
 
 ### Linking the User ID with a certification self-signature
 
-As above, when [linking a subkey](zoom_enc_subkey) to the OpenPGP certificate, a self-signature is used to connect this new component to the certificate.
+Similar to [linking a subkey](zoom_enc_subkey) to the OpenPGP certificate, a self-signature is used to connect this new component to the certificate.
 
-To bind identities to a certificate with a self-signature, one of the signature types `0x10` - `0x13` can be used. Here, the signature type `0x13` (*positive certification*) is used.
+To bind identities to a certificate with a self-signature, signature types `0x10` - `0x13` can be used. Here, the signature type `0x13` (*positive certification*) is used.
 
 ```text
 $ sq packet dump --hex alice.pub-3--Signature
@@ -732,13 +732,13 @@ Signature Packet, new CTB, 2 header bytes + 185 bytes
 ```
 
 
-We'll go over this packet dump in less detail, since its structure closely mirrors the [Direct Key Signature](zooming_in_dks) discussed above.
+Because this packet structure closely mirrors the [Direct Key Signature](zooming_in_dks) discussed above, we will cover this succinctly.
 
-We're again looking at a Signature packet. Its `type` is `0x13` ([corresponding](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-signature-types) to a *positive certification* signature).
+We're again looking at a Signature packet. Its `type` is `0x13` ([corresponding to a *positive certification* signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-signature-types)).
 
-The public key algorithm and hash function used for this signature are Ed25519 and SHA512.
+The designated public key algorithm and hash function for this signature are Ed25519 and SHA512, respectively.
 
-As shown in the text at the top of this packet dump, the hashed subpacket data contains the following metadata:
+As shown in the text atop this packet dump, the hashed subpacket data contains the following metadata:
 
 - Signature creation time: `2023-09-29 15:17:58 UTC` (**critical**)
 - Key expiration time: `P1095DT62781S` (**critical**)
@@ -747,16 +747,16 @@ As shown in the text at the top of this packet dump, the hashed subpacket data c
 - Primary User ID: `true` (**critical**)
 - Key flags: `C` (**critical**)
 - Features: `MDC`
-- Issuer Fingerprint: `AAA18CBB254685C58358320563FD37B67F3300F9FB0EC457378CD29F102698B3`
+- Issuer fingerprint: `AAA18CBB254685C58358320563FD37B67F3300F9FB0EC457378CD29F102698B3`
 
-This is a combination of metadata about the User ID itself (including defining this User ID as the *primary User ID* of this certificate), algorithm preferences that are associated with this identity, and settings that apply to the primary key.
+This is a combination of metadata about the User ID itself (designating this User ID as the *primary User ID* of this certificate), algorithm preferences for this identity, and settings that apply to the primary key.
 
 ````{note}
-For historical reasons, the self-signature that binds the primary User ID to the certificate also contains subpackets that apply not to the User ID, but to the primary key itself.
+Historically, the self-signature that binds the primary User ID to the certificate also contains subpackets relevant not to the User ID, but to the primary key itself.
 
 Setting key expiration time and key flags on the primary User ID self-signature is one mechanism to configure the primary key.
 
-The interaction between metadata on direct key signatures and User ID binding self-signatures [is subtle](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-notes-on-self-signatures), and there are changes between version 6 and version 4.
+The interaction between metadata on direct key signatures and User ID binding self-signatures [is subtle](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-notes-on-self-signatures), with changes between version 6 and version 4.
 
 
 ```{admonition} TODO
@@ -767,16 +767,18 @@ The interaction between metadata on direct key signatures and User ID binding se
 
 ````
 
-Followed, again, by the (informational) unhashed subpacket area.
+This section is followed, again, by the (informational) unhashed subpacket area.
 
-And finally, a salt value for the signature and the signature itself.
+Subsequently, we see a salt value for the signature and the signature itself.
 
-The signature is calculated over a hash. The hash, in this case, is calculated over the following data (for details, see [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-computing-signatures) in the RFC):
+The signature is calculated over a hash. The hash, in this case, is derived from the following data:
 
-- The signature's salt
-- A serialized form of the primary key's public data
-- A serialized form of the User ID
-- A serialized form of this self-signature packet (up to, but excluding the unhashed area)
+- the signature's salt
+- the serialized primary key's public data
+- the serialized User ID
+- the serialized self-signature packet (excluding the unhashed area)
+
+Refer to [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-computing-signatures) in the RFC for details.
 
 ## Certifications (Third Party Signatures)
 

From 2c57712c3b1af13ed0eed81cc7c9552d91ebd692 Mon Sep 17 00:00:00 2001
From: Heiko Schaefer <heiko@schaefer.name>
Date: Tue, 24 Oct 2023 15:00:52 +0200
Subject: [PATCH 14/26] fix title

---
 book/source/17-zoom_certificates.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 34125ec..2ba5db6 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -4,7 +4,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0
 -->
 
 (zoom_certificates)=
-# Zooming in: Packet structure of certificates and keys
+# Zooming in: Packet structure of certificates
 
 Now that we've established the concepts and  components that make up OpenPGP certificates , let's look at the internal details of an example certificate.
 

From a590637762f3a0b81b77da7601e20353701abfcf Mon Sep 17 00:00:00 2001
From: Heiko Schaefer <heiko@schaefer.name>
Date: Fri, 27 Oct 2023 23:34:41 +0200
Subject: [PATCH 15/26] fixes to Direct Key Signature section

---
 book/source/17-zoom_certificates.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 2ba5db6..ec445d1 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -246,10 +246,10 @@ Below is a field-by-field examination of the packet:
 
 - `CTB: 0xc2`: This field indicates the Packet type ID for this packet. Bits 7 and 6 show that the packet is in “OpenPGP packet format.” The remaining 6 bits encode the type ID’s value, which is “2” for a Signature packet.
 
-The packet type ID (`0xc2`) defines the semantics of the remaining data in the packet. In this case, as it indicates a [Signature packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#signature-packet), the following data is specific to this signature type.
-
 - `length: 0xb6`: This field shows the remaining length of this packet. 
 
+The packet type ID (“2”) defines the semantics of the remaining data in the packet. In this case, as it indicates a [Signature packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#signature-packet), the following data is specific to this packet type.
+
 - `version: 0x06`: This is a version 6 signature.
 
 - `type: 0x1f`: This indicates the [Signature Type](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-signature-types).

From 38f51396001ea3628579e48fe91d576e2b66cd22 Mon Sep 17 00:00:00 2001
From: Heiko Schaefer <heiko@schaefer.name>
Date: Fri, 27 Oct 2023 23:37:45 +0200
Subject: [PATCH 16/26] word fix

---
 book/source/17-zoom_certificates.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index ec445d1..72d3eb6 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -154,7 +154,7 @@ The Public-Key packet consists primarily of the cryptographic key data. Let's lo
 
 - `pk_algo: 0x1b`: This corresponds to the key's public-key algorithm ID, which has a decimal value of 27. Refer to the list of [Public-Key Algorithms](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-public-key-algorithms)) for more details.
 
-- `public_len: 0x00000020`: This section specifies the octet count for the subsequent public key material. In this case, it represents the length of the following `ed25519_public` field.
+- `public_len: 0x00000020`: This field specifies the octet count for the subsequent public key material. In this case, it represents the length of the following `ed25519_public` field.
 
 - `ed25519_public`: This is the [algorithm-specific representation](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-part-for-ed2) of the public key material. The format is based on the value of `pk_algo`, which, in this case, is 32 bytes of Ed25519 public key data.
 
@@ -776,7 +776,7 @@ The signature is calculated over a hash. The hash, in this case, is derived from
 - the signature's salt
 - the serialized primary key's public data
 - the serialized User ID
-- the serialized self-signature packet (excluding the unhashed area)
+  This section specifies- the serialized self-signature packet (excluding the unhashed area)
 
 Refer to [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-computing-signatures) in the RFC for details.
 

From 890f90c5f3e2f5fffb45ffd784d8c61847ea6513 Mon Sep 17 00:00:00 2001
From: Heiko Schaefer <heiko@schaefer.name>
Date: Fri, 27 Oct 2023 23:38:54 +0200
Subject: [PATCH 17/26] typo fix

---
 book/source/17-zoom_certificates.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 72d3eb6..6ac2d63 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -314,7 +314,7 @@ The subpacket details are as follows:
   - Type: `33`
   - Critical: `No`
   - Value: `aaa18cbb254685c58358320563fd37b67f3300f9fb0ec457378cd29f102698b3`
-  - Notes: The fingerprint identifoes the component key that issued the signature in this packet. In this instance, the value is the primary key fingerprint of the certificate we're looking at.
+  - Notes: The fingerprint identifies the component key that issued the signature in this packet. In this instance, the value is the primary key fingerprint of the certificate we're looking at.
 
 The next part of this packet contains unhashed subpacket data:
 

From a890aeddd5779b65a643ae4422b8bbf0d530ea01 Mon Sep 17 00:00:00 2001
From: Heiko Schaefer <heiko@schaefer.name>
Date: Fri, 27 Oct 2023 23:40:07 +0200
Subject: [PATCH 18/26] wording fix

---
 book/source/17-zoom_certificates.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 6ac2d63..7aa35d2 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -402,7 +402,7 @@ Notice that the structure of this *Public-Subkey packet* mirrors the primary key
 
 ### Subkey binding signature
 
-The aforementioned subkey packet is disconnected from the OpenPGP certificate to which it belongs. The link between the subkey and the complete OpenPGP key is made with a cryptographic signature, generated by primary key of the OpenPGP certificate.
+The aforementioned subkey packet is disconnected from the OpenPGP certificate to which it belongs. The link between the subkey and the complete OpenPGP certificate is made with a cryptographic signature, generated by primary key of the OpenPGP certificate.
 
 The type of signature is called a *subkey binding signature*, because it "binds" or connects the subkey to the rest of the key.
 

From 1612dfd5bab4f22ffb2f14da9772cef917df77df Mon Sep 17 00:00:00 2001
From: Heiko Schaefer <heiko@schaefer.name>
Date: Sat, 28 Oct 2023 01:47:40 +0200
Subject: [PATCH 19/26] wording fix

---
 book/source/17-zoom_certificates.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 7aa35d2..6ae2ac2 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -628,7 +628,7 @@ In this section, we'll look at an identity associated with Alice's certificate.
 
 User IDs are a mechanism for connecting [identities](identity_components) with an OpenPGP certificate. Typically, a User ID is a string combining a name and an email address.
 
-To understand the internal packet structure of this identity and its connection to the OpenPGP certificate, we'll examine two packets that constitute the identity component. One is the [User ID packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-id-packet-tag-13), located in the file `alice.pub-2--UserID`, which contains identity information. The other is a  certifying self-signature, specifically a [Positive certification of a User ID and Public-Key packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-positive-certification-of-a) located in the file `alice.pub-3--Signature`. This certification, issued after substantial verification of the identity claim, validates the association between the User ID and the certificate's public key. These packets are snippets from Alice's full OpenPGP private key.
+To understand the internal packet structure of this identity and its connection to the OpenPGP certificate, we'll examine two packets that constitute the identity component. One is the [User ID packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-id-packet-tag-13), located in the file `alice.pub-2--UserID`, which contains identity information. The other is a  certifying self-signature, specifically a [Positive certification of a User ID and Public-Key packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-positive-certification-of-a) located in the file `alice.pub-3--Signature`. This certification, issued after substantial verification of the identity claim, validates the association between the User ID and the certificate's public key. These packets are snippets from Alice's full OpenPGP certificate.
 
 ### User ID packet
 

From 543b1a8cc1e3f96bef0fca004567585badc86b19 Mon Sep 17 00:00:00 2001
From: Heiko Schaefer <heiko@schaefer.name>
Date: Sat, 28 Oct 2023 00:01:01 +0200
Subject: [PATCH 20/26] clearly mark different sections of packet discussions

---
 book/source/17-zoom_certificates.md | 21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 6ae2ac2..485a612 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -144,9 +144,17 @@ Public-Key Packet, new CTB, 2 header bytes + 42 bytes
 
 The Public-Key packet consists primarily of the cryptographic key data. Let's look at the packet field by field:
 
+**OpenPGP packet syntax**
+
+The first fields of a packet are governed by the general [Packet Syntax](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-packet-syntax):
+
 - `CTB: 0xc6`[^CTB]: This is the [packet type ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-packet-headers) for this packet. The binary representation of the value `0xc6` is `11000110`. The first two bits show that the packet is in *OpenPGP packet format* (as opposed to in *Legacy packet format*) and the remaining 6 bits encode the type ID value, which is "6." This type ID value corresponds to a Public-Key packet, as listed in the [packet type IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-packet-tags).
 
-- `length: 0x2a`: This indicates the remaining length of this packet. The packet type ID defines the semantics of the remaining data within the packet. In this case, it is a Public-Key packet, which is a kind of [Key Material Packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-key-material-packets).
+- `length: 0x2a`: This indicates the remaining length of this packet.
+
+**Public-Key packet syntax**
+
+The packet type ID ("6") defines the semantics of the following data within the packet. In this case, it is a Public-Key packet, which is a kind of [Key Material Packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-key-material-packets).
 
 - `version: 0x06`: The key material is in version 6 format. This means that the next part of the packet adheres to the structure of [Version 6 Public Keys](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-version-6-public-keys).
 
@@ -160,11 +168,6 @@ The Public-Key packet consists primarily of the cryptographic key data. Let's lo
 
 [^CTB]: Sequoia uses the term CTB (Cipher Type Byte) to refer to the RFC's [packet type ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-packet-headers). In earlier RFC versions, this field was known as the "Packet Tag."
 
-```{tip}
-
-The overall structure of OpenPGP packets is described in the [Packet Syntax](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-packet-syntax) chapter of the RFC.
-```
-
 Note that the *Public-Key packet* contains only the public part of the key.
 
 (zooming_in_dks)=
@@ -244,10 +247,16 @@ Signature Packet, new CTB, 2 header bytes + 182 bytes
 
 Below is a field-by-field examination of the packet:
 
+**OpenPGP packet syntax**
+
+The first fields of a packet are governed by the general [Packet Syntax](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-packet-syntax):
+
 - `CTB: 0xc2`: This field indicates the Packet type ID for this packet. Bits 7 and 6 show that the packet is in “OpenPGP packet format.” The remaining 6 bits encode the type ID’s value, which is “2” for a Signature packet.
 
 - `length: 0xb6`: This field shows the remaining length of this packet. 
 
+**Signature packet syntax**
+
 The packet type ID (“2”) defines the semantics of the remaining data in the packet. In this case, as it indicates a [Signature packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#signature-packet), the following data is specific to this packet type.
 
 - `version: 0x06`: This is a version 6 signature.

From 33cab7b59a4affed3cca05b52dc8e325ab5d0656 Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Thu, 2 Nov 2023 10:17:49 +0100
Subject: [PATCH 21/26] change period to colon

---
 book/source/17-zoom_certificates.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 485a612..acac0d1 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -257,7 +257,7 @@ The first fields of a packet are governed by the general [Packet Syntax](https:/
 
 **Signature packet syntax**
 
-The packet type ID (“2”) defines the semantics of the remaining data in the packet. In this case, as it indicates a [Signature packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#signature-packet), the following data is specific to this packet type.
+The packet type ID (“2”) defines the semantics of the remaining data in the packet. In this case, as it indicates a [Signature packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#signature-packet), the following data is specific to this packet type:
 
 - `version: 0x06`: This is a version 6 signature.
 

From a6516a949c890a0f9bed0e8be4e7593a26cf3e5c Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Thu, 2 Nov 2023 12:38:25 +0100
Subject: [PATCH 22/26] resolve
 https://codeberg.org/openpgp/notes/pulls/91#issuecomment-1305908

---
 book/source/17-zoom_certificates.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index acac0d1..9a6a3cb 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -339,7 +339,7 @@ As above, the following subpacket data consists of sets of subpacket length, sub
 
 This concludes the unhashed subpacket data.
 
-This next section shows additional components of the Direct Key Signature packet:
+This next section shows the remaining fields of this signature packet, which relate to the cryptographic digital signature:
 
 - `digest_prefix: 0x6747`: the left 16 bits of the signed hash value
 

From e20658c249ac85cb825da8597638123a1c3e96ff Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Thu, 2 Nov 2023 12:46:02 +0100
Subject: [PATCH 23/26] resolve
 https://codeberg.org/openpgp/notes/pulls/91#issuecomment-1310156

---
 book/source/17-zoom_certificates.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 9a6a3cb..6ce27be 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -433,7 +433,7 @@ Should this text go elsewhere?
 
 The signature does more than just bind the subkey; it also carries additional metadata about the subkey. This metadata is in the binding signature, and not in the subkey packet, because it may change over time, while the subkey packet itself remains unchanged. This evolving metadata is stored in self-signatures: if the key holder wants to modify the metadata (for example, to change the key's expiration time), a newer version of the same signature type can be issued. The recipient OpenPGP software will recognize that the newer self-signature supersedes the older one, and that the metadata in the newer signature reflects the most current intent of the key holder.
 
-Note that this subkey binding signature packet is quite similar to the Direct Key Signature discussed above. Both signatures serve a similar purpose in adding metadata to a component key, particularly as the hashed subpacket data contains much of the metadata elements.
+Note that this subkey binding signature packet is quite similar to the Direct Key Signature discussed above. Both signatures serve a similar purpose in adding metadata to a component key, particularly as the hashed subpacket data contains much of the same metadata elements.
 
 ```text
 $ sq packet dump --hex alice.pub-5--Signature

From 00270a07e57a541cbcc583f6c31425ccf0cb76d3 Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Thu, 2 Nov 2023 13:07:45 +0100
Subject: [PATCH 24/26] remove extra space

---
 book/source/17-zoom_certificates.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 6ce27be..65051b9 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -6,7 +6,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0
 (zoom_certificates)=
 # Zooming in: Packet structure of certificates
 
-Now that we've established the concepts and  components that make up OpenPGP certificates , let's look at the internal details of an example certificate.
+Now that we've established the concepts and components that make up OpenPGP certificates , let's look at the internal details of an example certificate.
 
 ## A very minimal OpenPGP certificate
 

From 43faca00e31458deeeba3162738f484fc04f3618 Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Thu, 2 Nov 2023 13:44:28 +0100
Subject: [PATCH 25/26] correct for hash digest, move reference

---
 book/source/17-zoom_certificates.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index 65051b9..a672861 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -6,7 +6,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0
 (zoom_certificates)=
 # Zooming in: Packet structure of certificates
 
-Now that we've established the concepts and components that make up OpenPGP certificates , let's look at the internal details of an example certificate.
+Now that we've established the concepts and components that make up OpenPGP certificates, let's look at the internal details of an example certificate.
 
 ## A very minimal OpenPGP certificate
 
@@ -341,19 +341,19 @@ This concludes the unhashed subpacket data.
 
 This next section shows the remaining fields of this signature packet, which relate to the cryptographic digital signature:
 
-- `digest_prefix: 0x6747`: the left 16 bits of the signed hash value
+- `digest_prefix: 0x6747`: the left 16 bits of the signed hash digest
 
 - `salt_len, salt`: a random [salt value](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-advantages-of-salted-signat) with size [matching the hash algorithm](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#hash-algorithms-registry))
 
 - `ed25519_sig`: [algorithm-specific](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-fields-for-ed2) representation of the signature (here: 64 bytes of Ed25519 signature)
 
-The signature's hash is calculated from the following data:
+The hash digest is calculated from the following data (see [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-computing-signatures) in the RFC):
 
 - the signature's salt
 - the serialized primary key's public data
 - the serialized direct key signature packet (excluding the unhashed area)
 
-Refer to [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-computing-signatures) in the RFC for more details.
+The signature is derived from this hash digest.
 
 (zoom_enc_subkey)=
 ## Encryption subkey
@@ -509,7 +509,7 @@ The rest of the packet mirrors the *Direct Key Signature* discussed above:
 - a salt value 
 - the cryptographic signature itself
 
-The signature is calculated over a hash. In this case, the hash is derived from the following data:
+The signature is calculated over a hash digest. In this case, the hash digest is derived from the following data:
 
 - the signature's salt 
 - the serialized primary key's public data 

From 333a8862ac99f829072954e15356f7e8daa4d6c4 Mon Sep 17 00:00:00 2001
From: "Tammi L. Coles" <tlcoles@gmail.com>
Date: Thu, 2 Nov 2023 13:47:20 +0100
Subject: [PATCH 26/26] change to calculated

---
 book/source/17-zoom_certificates.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/book/source/17-zoom_certificates.md b/book/source/17-zoom_certificates.md
index a672861..1aa15a8 100644
--- a/book/source/17-zoom_certificates.md
+++ b/book/source/17-zoom_certificates.md
@@ -353,7 +353,7 @@ The hash digest is calculated from the following data (see [Computing Signatures
 - the serialized primary key's public data
 - the serialized direct key signature packet (excluding the unhashed area)
 
-The signature is derived from this hash digest.
+The signature is calculated from this hash digest.
 
 (zoom_enc_subkey)=
 ## Encryption subkey