From 8712e97f8e9b736d86b7ea6caf8a86f47276c10c Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 3 Dec 2023 23:16:20 +0100 Subject: [PATCH] fix terminology --- 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 b00799d..c537fec 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -347,7 +347,7 @@ By contrast, a soft revocation leaves the revoked component or signature valid b Hard revocations address the following problem: If a private key was compromised, then the attacker can issue signatures using that key. This means, the attacker could issue a signature dated before the revocation, impersonating the owner of the key. A recipient of that signature would mistakenly consider this signature valid if the issuing key has been soft revoked. This is a problem. To counteract this problem, it is reasonable to clearly mark compromised keys as suspect at any point in time. That's what hard revocations do. -On the other hand, if the subkey was merely retired, and the certificate holder moved to a different subkey, then the signatures in the past, made by the retired key, are still correct. +On the other hand, if the subkey was merely retired, and the certificate holder moved to a different subkey, then the signatures in the past, made by the retired key, are still valid. (append-only)= ### Certificates are effectively append-only data structures