diff --git a/book/source/06-certifications.md b/book/source/06-certifications.md
index d394bd2..353a538 100644
--- a/book/source/06-certifications.md
+++ b/book/source/06-certifications.md
@@ -61,18 +61,18 @@ Typical use-cases for revocations are marking certificates or individual subkeys
 
 ## Signature Subpackets
 
-A cryptographic signature alone is often not expressive enough to fulfil certain use-cases.
+A cryptographic signature alone is often not expressive enough to serve certain use-cases.
 For this reason, the OpenPGP protocol introduced signature subpackets with rfc4880.
 These are well-defined data structures that can be placed as subelements into signature packets, which give additional context and meaning to a signature.
-Typical examples are the issuer fingerprint subpacket, which contains the fingerprint of the issuer key, or the  key flags subpacket which states, what purpose a component key is intended for.
+Typical examples are the issuer fingerprint subpacket, which contains the fingerprint of the issuer key, or the key flags subpacket which states, what purpose a component key is intended for.
 
 Signature subpackets can reside in two different areas of a signature packet.
 Subpackets in the *hashed area* are incorporated in the digest calculation that is done during signature calculation and are therefore covered by the cryptographic signature.
-Hashed subpackets are *authenticated*.
-If a subpacket is placed in the *unhashed area* instead, it is not included in the signature calculation procedure.
+In other words; hashed subpackets are *authenticated*.
+If a subpacket is placed in the *unhashed area* instead, it is not included in the signature calculation procedure and is therefore not protected against tampering.
 The unhashed area can be used to retroactively add, change or remove subpackets from a signature without invalidating it.
 
-Due to the fact that the unhashed area doesn't provide any cryptographic guarantees, it is only intended for advisory packets, or packets that self-authenticate (e.g. issuer key ID / issuer fingerprint subpackets, whose "correctness" can be proven by successfully verifying the signature using the referenced issuer key).
+Due to the fact that the unhashed area doesn't provide any cryptographic guarantees, it is only intended for advisory packets, or packets that self-authenticate (e.g. the issuer fingerprint subpacket, whose "correctness" can be proven by successfully verifying the signature using the referenced issuer key).
 In most cases, signature subpackets are simply added into the hashed area.
 
 Since the hashed and unhashed areas of a signature are just lists of subpackets, in principle they allow duplicates of the same subpacket, which might lead to conflicts.