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

Small changes

Browse source
This commit is contained in:
Paul Schaub 2023-11-09 17:22:14 +01:00 • committed by Heiko Schaefer
parent 6388d5c33b
commit 5ab4546144
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 13 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

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

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