From 6f220c9f398fd1f285c4390cc7057cd0f358c317 Mon Sep 17 00:00:00 2001 From: Paul Schaub Date: Sun, 5 Nov 2023 17:59:32 +0100 Subject: [PATCH] Feverish signature precedence thought --- book/source/09-verification.md | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/book/source/09-verification.md b/book/source/09-verification.md index b6d8b38..c9423db 100644 --- a/book/source/09-verification.md +++ b/book/source/09-verification.md @@ -27,3 +27,36 @@ Furthermore, the signature might not be valid in the first place, due to a missi - Validity as a tree of signatures ## Which signatures take precedence? + +An OpenPGP certificate can have multiple signatures with conflicting information in them. +For example, the latest direct-key signature could list "SHA512, SHA384" as hash algorithm preferences, while the latest self-certification of User-ID "Bob" could list "SHA256" only. +For yet another User-ID "Bobby", the self-signature could list no hash algorithm preferences at all. +If the user wants to compose a signed message using the associated OpenPGP key, they need to figure out, which preferences to use. +The specification recommends, that implementations decide which signature takes precendence by the way the certificate is "addressed". +If the user wants to write an email as "Bob", it should consider the signature on "Bob", so SHA256 should be used as hash algorithm. +If instead the user wants to write as "Bobby", the impementation should inspect the self-certification on "Bobby" instead. +However, since this signature does not carry any hash algorithm preferences subpacket, the implementation must fall back to the direct-key signature instead. +The same is true, if the certificate is used without any User-ID as sender. + +But it gets more complicated still. +Algorithm preferences can also "live" on subkey binding signatures, so if the certificate has a dedicated signing subkey, there is yet another signature which could take precendence. +Preferences from the subkey binding signature take precendence over the direct-key signature, but not over self-certifications on the User-ID. + +TODO: Have a table that lists which signatures take precendence in which cases. + +There can be more than one signature on a component. For example, there could be 3 direct-key signatures, e.g. because the user extended the lifespan of their key 2 times already. +In general, for each component, only the newest self-signature is "in effect", and older signatures are "shadowed". +For each certificate, there is at most one "active" direct-key signature, for each User-ID at most one active self-certification and for each subkey exactly one subkey binding. +TODO: Direct-Key Signaures can be revoked, canceling them, meaning an older one might get active? + +## +Unfortunately, the OpenPGP packet format allows for quite a lot of flexibility when composing certificates. +User-ID packets for example, are not fixed with regards to their position, which means that an attacker (or canonicalizer) can change the order in which User-IDs appear in the certificates packet sequence. + + + +As a concrete example, consider a certificate with multiple User-IDs, all marked as primary. Or equaly, a certificate with multiple User-IDs of which none is marked as primary. +Clients might apply different heuristics to figure out, which User-ID actually qualifies as the primary User-ID here. + +You might wonder, which signature on the primary key takes precendence in case of multiple signature candidates with conflicting signature subpackets. +