From 1335d5568fa1ace6b4e22cc5b469b7a74dcbf51e Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 7 Nov 2023 21:13:34 +0100 Subject: [PATCH] edits --- book/source/08-signing_components.md | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index d3b0746..298844e 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -73,6 +73,12 @@ Typical use-cases for revocations are marking certificates or individual subkeys A revocation signature can either be hard or soft. A soft revocation of a certificate invalidates it from the revocation signature's creation time onwards. This means signatures issued before the revocation remain intact. A hard revocation, by contrast, invalidates the certificate retroactively, rendering all issued signatures invalid, regardless of creation time. Soft revocations are typically used whenever a key or User ID is retired or superseded gracefully, while hard revocations can, for example, signal compromise of secret key material. +```{note} +OpenPGP certificates act as append-only data structures, in practice. Elements of a certiciate can not be removed from the copies on key servers and the OpenPGP systems of third parties, once published. Implementations usually merge all available components and signatures. + +Revocations are used as a mechanism to mark components or signatures as invalid. +``` + ## Self-signatures: Linking the components of a certificate So far we've looked at the components in an OpenPGP certificate, but certificates actually contain another set of elements, which bind the components together, and add metadata to them. @@ -113,9 +119,15 @@ Linking an OpenPGP subkey to the primary key with a binding signature The [Signature packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-signature-packet-tag-2) that binds the subkey to the primary key has the signature type [SubkeyBinding](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-subkey-binding-signature-si). -In order to specify an expiration time for the subkey, a key expiration time subpacket can be included. Note, that the validity of the subkey is bounded by that of the primary key, meaning an expired primary key causes the subkey to be invalidated, no matter the subkey expiration time. +In order to specify an expiration time for the subkey, a key expiration time subpacket can be included. -Note, that a subkey cannot be "older" than the primary key. The value of the subkeys creation date MUST be greater than that of the primary key. +```{note} +The validity of a subkey is bounded by that of the primary key, meaning an expired primary key causes the subkey to be invalidated, no matter the subkey expiration time. + +It's legal for a subkey to not have an explicit expiry time. In that case, its expiration date is implicitly the same as the expiration date of the primary key. + +A subkey cannot be "older" than the primary key. The value of the subkeys creation date MUST be greater than that of the primary key. +``` ### Special case: Binding signing subkeys to a certificate @@ -181,7 +193,9 @@ A soft revocation invalidates the target certificate beginning with the revocati Contrary, a hard revocation cannot be re-validated. Furthermore, a hard-revoked certificate is invalidated retroactively. +```{note} A missing revocation reason subpacket is equivalent with a hard revocation reason. +``` (third_party_cert)= ## Third-party certifications: Making statements about other people's certificates and identities @@ -290,12 +304,12 @@ The structure of such a signature is rather minimal: | Issuer Fingerprint | Hashed | True or false | Strongly Recommended | The primary key is the issuer | | Reason for Revocation | Hashed | True | False | Decides over soft / hard revocation | -In `SubkeyRevocation` signatures, the reason subpacket cannot have value `32`, but instead may be from the range of `0-3`. +In `SubkeyRevocation` signatures, the [reason subpacket](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-reason-for-revocation) cannot have value `32`, but instead may be from the range of `0-3`. Values `1` (key superseded) and `3` (key retired and no longer used) are soft reasons, while `0` (no reason) and `2` (key compromised) are considered hard. #### Revoke a Certificate -A user might want to revoke their whole certificate, rendering it unusable. +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). @@ -307,11 +321,11 @@ The structure of a key revocation signature is similar to that of a `Certificati | Issuer Fingerprint | Hashed | True or false | Strongly Recommended | The primary key is the issuer | | Reason for Revocation | Hashed | True | False | Decides over soft / hard revocation | -For `KeyRevocation` signatures, the same constraints as for `SubkeyRevocation` signatures apply to the reason subpacket. +For `KeyRevocation` signatures, the same constraints as for `SubkeyRevocation` signatures apply to the [reason subpacket](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-reason-for-revocation). #### Common Subpackets -There are some subpackets that are expected to be included in any type of signature. +There are some subpackets that are expected to be included in all types of signatures. * **Signature Creation Time**: Every OpenPGP signature MUST contain a Signature Creation Time subpacket (2) containing the timestamp at which the signature was made. This packet MUST be present in the hashed area of the signature and SHOULD be marked as critical.