From 420e15e8c8965261d28d15bdaab9069a3b270170 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 7 Nov 2023 21:35:09 +0100 Subject: [PATCH] remove seemingly stray text --- book/source/08-signing_components.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index 298844e..3963f83 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -269,7 +269,7 @@ The structure of a certification revocation is as follows: For User ID revocations, the value of the reason subpacket can either be `0` (no reason specified) or `32`, signaling that the User ID is no longer valid. The latter would result in a soft revocation, while a reason code of `0` is considered a hard revocation. Omitting the reason packet altogether is also equivalent to a hard revocation. -It is recommended to issue User ID certifications using a reason code `32` and to do certificate revocations using a direct-key signature. +It is recommended to issue User ID revocations using a reason code `32`. (binding_subkeys)= #### Add a Subkey @@ -310,6 +310,7 @@ Values `1` (key superseded) and `3` (key retired and no longer used) are soft re #### Revoke a Certificate A user might want to revoke their entire certificate, rendering it unusable. + Depending on the circumstances, they might either want to revoke it softly, e.g. in case of migration to a new certificate, or they want to issue a hard revocation, e.g. in case of secret key material compromise. A soft-revoked certificate can be re-validated at a later point in time, by issuing a new certification, while a hard revocation is typically permanent. The recommended way to revoke a certificate is by issuing a `KeyRevocation` signature (type 0x20).