diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md
index ff37d56..a4af29e 100644
--- a/book/source/08-signing_components.md
+++ b/book/source/08-signing_components.md
@@ -105,24 +105,23 @@ Legally, a subkey may not have a specified expiry time. In such cases, its expir
 ```
 
 (bind_subkey_sign)=
-### Special case: Binding signing subkeys to a certificate
+### Special case: Binding signing subkeys
 
-To bind subkeys with the "signing" key flag to a certificate is a special case. For the most part, it works the same as binding other types of subkeys, but there is one additional requirement:
+Binding subkeys that possess the *signing* key flag to a certificate represents a unique scenario. While similar to the binding process of other subkeys, there is an additional, critical requirement: mutual association.
 
-To bind a signing-capable 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."
+That is, to bind a signing-capable subkey to a primary key, it is insufficient that the "primary key wants to be associated with the subkey." The subkey must explicitly signal that it "wants to be associated with the primary key."
 
-Otherwise, Alice could "adopt" Bob's signing subkey and convincingly claim that she made signatures that were in fact issued by Bob.
-This is to prevent an attack where the attacker "adopts" the victims signing subkey as their own in order to claim ownership over documents which were in fact signed by the victim.
-In contrast to the [subkey binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-subkey-binding) (type ID `0x18`), which is issued by the certificate's primary key, the [primary key binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-primary-binding) (type ID `0x19`) is instead created by the subkey (informally also called an embedded "back signature").
+This mutual binding is crucial for security. Without it, an individual (e.g., Alice) could falsely claim a connection to another person’s (e.g., Bob's) signing subkey. To prevent such scenarios, where an attacker might wrongfully "adopt" a victim's signing subkey, a dual-layer of signatures is used:
+
+- the [subkey binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-subkey-binding) (type ID `0x18`), which is issued by the certificate's primary key
+- the [primary key binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-primary-binding) (type ID `0x19`), created by the subkey itself. This is informally known as an embedded "back signature," because the subkey's signature points back to the primary key.
 
 ```{figure} diag/subkey_binding_signatur_for_signing_sk.png
 
 Linking an OpenPGP signing subkey to the primary key with a binding signature, and an embedded primary key binding signature
 ```
 
-The additional [*primary key binding*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-primary-binding) signature (type 0x19) is informally called a "back signature" (because the subkey uses the signature to point "back" to the primary key).
-
-The *primary key binding signature* is "embedded" as subpacket data in the *subkey binding signature* which connects the signing subkey to the primary key.
+The back signature signifies the mutuality of the subkey's association with the primary key and is embedded within the subkey binding signature, reinforcing the authenticity of the binding.
 
 (bind_ident)=
 ### Binding identities to a certificate