From 5ab4546144e6b470153d50ef6c72ecdfb61973a1 Mon Sep 17 00:00:00 2001 From: Paul Schaub Date: Thu, 9 Nov 2023 17:22:14 +0100 Subject: [PATCH] Small changes --- book/source/09-verification.md | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/book/source/09-verification.md b/book/source/09-verification.md index 364b351..2f0cc30 100644 --- a/book/source/09-verification.md +++ b/book/source/09-verification.md @@ -7,10 +7,11 @@ SPDX-License-Identifier: CC-BY-SA-4.0 # Verification Signature verification in the OpenPGP protocol is a complex process. -There are lots of different factors that can influence the validity of a signature. -Some signatures can be verified standalone, while others require the verification of a chain-like structure of other signatures, mostly on the issuers certificate. -Signatures can be invalid due to the absence or presence of other signatures. +There are lots of different factors that can influence the validity of a signature, most importantly its expiration date. A signature can be valid at one point in time and invalid merely 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 other signatures, mostly on the issuers certificate. + ## When are signatures valid? @@ -21,19 +22,23 @@ Put mathematically, the set of valid signatures is a subset of the set of correc The validity of a correct signature is additionally constrained by a number of conditions: * well-formedness - Signatures need to be well-formed, meaning they must contain required signature subpackets in the proper subpacket area and must not contain unknown critical subpackets or notations. + Signatures need to be well-formed, meaning they must contain required signature subpackets in the proper subpacket area and must not contain unknown critical subpackets or unknown critical notations. +Note: This also means, that a signature might be considered valid by one implementation and be rejected by another. +Some implementations further apply a policy when verifying signatures, putting constraints on used hash- and key algorithms and key strengths. * temporal validity Most signatures have a limited validity period, constrained by the signature creation- and expiration time. * qualification - Furthermore, some signatures need to be *qualified* by another valid signature in order to be considered valid. + Furthermore, some signatures need to be *qualified* by other valid signatures in order to be considered valid. +This is especially the case with signatures created by dedicated signing subkeys, where, in addition to the signature itself, the subkeys binding signature(s) must be verified. * revocation Lastly, signatures can be invalidated by revocations. ### Temporal validity A signature is valid only for a constrained period of time. -A lower constraint for the validity period is the creation time of the signature. An exception from this rule are hard revocation signatures, where this lower constraint is dropped. +A lower constraint for the validity period is the creation time of the signature, meaning a signature only becomes valid after its creation timestamp. An upper constraint might be the signatures expiration time. +A special case are hard revocation signatures, where the lower constraint is dropped, so hard revocations are valid since the dawn of time. When checking a signature for validity, a reference time is defined. For an email that might be the signature creation time itself, or the reception date. @@ -52,7 +57,7 @@ Examples for signatures which are not self-qualifying are data signatures (0x00, ### Signature qualification To verify non-self-qualifying signatures, it is not sufficient to only look at the signature itself. -The reason is, that the issuer (sub-) key needs to be qualified to create such a signature. +The reason is, that the issuer (sub-) key needs to be qualified to create such a signature (e.g. because a special key-flag is required). This qualification typically comes via another self-signature on the key itself. Instead, a chain of valid signatures from the signature itself to the primary key of the issuer certificate needs to be established. @@ -70,6 +75,7 @@ On the other hand, in order to verify a data signature over a text document, an ``` ### Attribute Shadowing + TODO ### Revocations