ch4: minor edits

book/source/04-certificates.md

@@ -158,15 +158,15 @@ Internally, an OpenPGP certificate consists of a sequence of OpenPGP packets. Th
 
 However, the owner of a certificate doesn't want a third party to add subkeys (or add identity claims) to their certificate, pretending that the certificate owner put those components there.
 
-To prevent malicious addition of components, OpenPGP uses cryptographic signatures. These signatures show that components have been added by the owner of the OpenPGP certificate (the main part of this linking is done by the primary key of the certificate).
+To prevent malicious addition of components, OpenPGP uses cryptographic signatures. These signatures show that components have been added by the owner of the OpenPGP certificate (these linking signatures are issued by the primary key of the certificate).
 
 So while anyone can still unilaterally store unrelated subkeys and identity claims in an OpenPGP certificate dataset, OpenPGP implementations that read this file should discard components that don't have a valid cryptographic connection with the certificate.
 
 (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:
+Note, though, that there are some cases where third parties legitimately add "unbound" packets to certificates (that is: packets that are not signed 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]),
+- [Third-party certifications](third_party_cert) are traditionally added to the certificate that they make a statement about (this can cause problems in systems that unconditionally accept and include such certifications[^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).
@@ -184,9 +184,9 @@ Linking an OpenPGP subkey to the primary key with a binding signature
 
 The [Signature packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-signature-packet-tag-2) that binds the subkey to the primary key has the signature type [SubkeyBinding](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-subkey-binding-signature-si).
 
-##### Binding signing subkeys
+##### Binding signing subkeys to an OpenPGP certificate
 
-Binding subkeys that have the "signing" key flag is a special case:
+Binding subkeys with the "signing" key flag is a special case:
 
 When binding a signing subkey to a primary key, it is not sufficient that the "primary key wants to be associated with the subkey." In addition, the subkey must signal that it "wants to be associated with that primary key."
 
@@ -220,7 +220,7 @@ Linking a User ID to an OpenPGP certificate
 ```{admonition} TODO
 :class: warning
 
-This section only contains notes and still needs to be written
+This section needs writing
 ```
 
 ## Revocations