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)