From 4f73c0a9173e2536b2549b0ec1a34ef745f3775d Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Fri, 8 Dec 2023 00:06:40 +0100 Subject: [PATCH] minor edit --- book/source/09-verification.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/book/source/09-verification.md b/book/source/09-verification.md index e4b8ddb..eac6965 100644 --- a/book/source/09-verification.md +++ b/book/source/09-verification.md @@ -93,7 +93,7 @@ This is required because the issuing component key needs to be qualified to crea In short, a chain of valid signatures from the signature itself to the primary key of the issuer certificate needs to be established. -For example, a data signature over an email body may be issued by a subkey only if that subkey is validly bound to the issuer's certificate via a subkey binding signature. That binding signature needs to contain a *key flags* subpacket that marks the subkey as *signing* capable. +For example, a subkey may issue a data signature over an email body only if that subkey is validly bound to the issuer's certificate via a subkey binding signature. That binding signature needs to contain a *key flags* subpacket that marks the subkey as *signing* capable. Similarly, certification signatures over third-party certificates require the issuer key to carry a valid self-signature with the *certification* key flag. Self-qualifying signatures have no such limitations. @@ -192,6 +192,7 @@ When verifying a signature that is not self-qualifying, an implementation needs There may be several signatures per component. For example, there could be multiple subkey binding signatures for one subkey. + In general, for each category of signatures, only the signature with the latest creation time is considered and takes precedence. Alternatively, there might be competing qualifying signatures of different types, e.g., a direct key signature and a self-certification signature on a primary User ID.