diff --git a/book/source/09-verification.md b/book/source/09-verification.md
index f5fd5b0..c02c09a 100644
--- a/book/source/09-verification.md
+++ b/book/source/09-verification.md
@@ -9,7 +9,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0
 Signature verification in the OpenPGP protocol is a complex process.
 Many factors influence the validity of a signature.
 
-Firstly, its expiration date: A signature can be valid at one point in time and expired a second later.
+Firstly, its expiration time: A signature can be valid at one point in time and expired a second later.
 
 Signatures can be invalid due to the absence or presence of other signatures (e.g., revocations).
 Some signatures can be verified standalone, while others require the verification of a chain-like structure of signatures, mostly within the issuer's certificate.
diff --git a/book/source/17a-adv-certificates.md b/book/source/17a-adv-certificates.md
index 6df5a0e..a48488e 100644
--- a/book/source/17a-adv-certificates.md
+++ b/book/source/17a-adv-certificates.md
@@ -87,7 +87,7 @@ There are various potential problems associated with this fact: Users may not be
 
 One mechanism that addresses a part of this issue is *expiration*: By setting their certificates to expire after an appropriate interval, certificate holders can force their communication partners to refresh their certificate, e.g. from a keyserver[^mgorny].
 
-[^mgorny]: See, for example, [here](https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/): "Expiration dates really serve two purposes: naturally eliminating unused keys, and enforcing periodical checks on the primary key."
+[^mgorny]: See, for example, [here](https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/): "Expiration times really serve two purposes: naturally eliminating unused keys, and enforcing periodical checks on the primary key."
 
 Good practices, like setting appropriate expiration times, can mitigate the complexity of the inherently distributed nature of certificates.
 
diff --git a/book/source/17b-adv-private.md b/book/source/17b-adv-private.md
index 80dbab5..dc4e1cc 100644
--- a/book/source/17b-adv-private.md
+++ b/book/source/17b-adv-private.md
@@ -23,7 +23,7 @@ While private keystore operations require component keys, they do not require ac
 ```{note}
 The third design option, involving the storage of full TSKs in the private key subsystem, can cause "split brain" problems.
 
-For example, a private keystore might contain a TSK with outdated certificate metadata, marking the certificate as expired, while the updated version in the local public keystore could indicate an extended expiration date. 
+For example, a private keystore might contain a TSK with outdated certificate metadata, marking the certificate as expired, while the updated version in the local public keystore could indicate an extended expiration time. 
 
 This problem was notably present in GnuPG 1.x, which held separate TSK copies in its private store component. Similarly, the current design of Thunderbird's OpenPGP subsystem can lead to users experiencing such issues.
 ```