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

Complexity, complexity, complexity...

Browse source
This commit is contained in:
Paul Schaub 2023-11-08 16:20:07 +01:00 • committed by Heiko Schaefer
parent 89f776e6f3
commit 6388d5c33b
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 32 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -20,9 +20,13 @@ A signature might be correct, but still disqualify as a valid signature.
Put mathematically, the set of valid signatures is a subset of the set of correct signatures. Put mathematically, the set of valid signatures is a subset of the set of correct signatures.
The validity of a correct signature is additionally constrained by a number of conditions: 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 notations.
* temporal validity
Most signatures have a limited validity period, constrained by the signature creation- and expiration time. 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 another valid signature in order to be considered valid.
* revocation
Lastly, signatures can be invalidated by revocations. Lastly, signatures can be invalidated by revocations.
### Temporal validity ### Temporal validity
@ -44,10 +48,15 @@ Typically, self-qualifying signatures are self-signatures, meaning signatures is
Examples for self-qualifying signatures are direct-key self-signatures (0x1F), User-ID self-certifications (0x10-0x13), key-revocation self-signatures (0x20), certification revocation self-signatures (0x30) or signatures used to bind or revoke subkeys (0x18, 0x19, 0x28). Examples for self-qualifying signatures are direct-key self-signatures (0x1F), User-ID self-certifications (0x10-0x13), key-revocation self-signatures (0x20), certification revocation self-signatures (0x30) or signatures used to bind or revoke subkeys (0x18, 0x19, 0x28).
Examples for signatures which are not self-qualifying are data signatures (0x00, 0x01) and signatures issued over third-party certificates, such as third-party direct-key signatures (0x1F) or key-revocations (0x20), third-party certification or revocation signatures (0x10-0x13, 0x30). Examples for signatures which are not self-qualifying are data signatures (0x00, 0x01) and signatures issued over third-party certificates, such as third-party direct-key signatures (0x1F) or key-revocations (0x20), third-party certification or revocation signatures (0x10-0x13, 0x30).
To verify such signatures, it is not sufficient to only look at the signature itself.
### 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.
This qualification typically comes via another self-signature on the key itself. 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.
For example, a data signature over an email body may be issued by a subkey only if that subkey is validly bound to the users certificate via a subkey binding signature, and that binding signature needs to contain a key flags subpacket marking the subkey as **S**igning capable. For example, a data signature over an email body may be issued by a subkey only if that subkey is validly bound to the users certificate via a subkey binding signature, and that binding signature needs to contain a key flags subpacket marking the subkey as **S**igning capable.
Similarly, certification signatures over third-party certificates require the issuer key to carry a self-signature qualifying it to **C**ertify other keys. Similarly, certification signatures over third-party certificates require the issuer key to carry a self-signature qualifying it to **C**ertify other keys.
@ -60,6 +69,9 @@ On the other hand, in order to verify a data signature over a text document, an
```{include} mermaid/09-sigtree.md ```{include} mermaid/09-sigtree.md
``` ```
### Attribute Shadowing
TODO
### Revocations ### Revocations
A signature might be *disqualified* by the presence of a revocation signature. A signature might be *disqualified* by the presence of a revocation signature.
@ -70,7 +82,21 @@ TODO: Give guidance, which revocations need to be considered for different types
## Which signatures take precedence? ## Which signatures take precedence?
An OpenPGP certificate can have multiple signatures with conflicting information in them. An OpenPGP certificate or component can have multiple signatures with conflicting information attached to it.
When verifying a non-self-qualifying signature, an implementation needs to identify self-qualifying signatures on the certificate to qualify that signature.
There might be more than one candidate for such a signature.
For example, there might be multiple subkey binding signatures for the same subkey.
In general, for each category of signatures, only that with the latest signature creation time is considered and takes precendence.
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.
In this case, depending on how a key is "addressed", different attributes from both candidates "shadow" another.
```
TODO: Replace hash algorithm preferences with AEAD preferences for a more realistic example.
```
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 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. 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. If the user wants to compose a signed message using the associated OpenPGP key, they need to figure out, which preferences to use.