vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2025-09-10 11:49:40 +02:00
Code Issues Projects Releases Packages Wiki Activity

Feverish signature precedence thought

Browse source
This commit is contained in:
Paul Schaub 2023-11-05 17:59:32 +01:00 • committed by Heiko Schaefer
parent bac7d8cf16
commit 6f220c9f39
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 33 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

33
book/source/09-verification.md
View file

@ -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.