From eb782f61ba2f2fd51d67548b8f54e9e57d7b3976 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 3 Dec 2023 22:52:16 +0100 Subject: [PATCH] Clarify text --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index daf8b3f..2f6f6ff 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -320,7 +320,7 @@ Using the expiration mechanism is useful for two reasons: - Expiration of a certificate means that it cannot be used anymore. This forces users of that certificate (or their OpenPGP software) to poll for updates for it. For example, from a keyserver. - It is a passive way for certificates to "time out," e.g., if their owner loses control over them, or isn't able to broadcast a revocation, for any reason. -Component keys use *Key Expiration Time* subpackets for expressing the expiration time. Identity components rely on the expiration of their binding signature. If a binding signature expires, the binding becomes invalid, and the component is considered expired. +Component keys use *Key Expiration Time* subpackets for expressing the expiration time. Identity components rely on the [*signature expiration time*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#signature-expiration-subpacket) subpacket of their binding signature. If a binding signature expires, the binding becomes invalid, and the component is considered expired. #### Revocation