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

Progress

Browse source
This commit is contained in:
Paul Schaub 2023-11-08 14:36:04 +01:00 • committed by Heiko Schaefer
parent 3727176d76
commit 39c79709bd
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 39 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -7,54 +7,66 @@ 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.
## Self-authorizing and non-self-authorizing signatures
We will call the former category *self-authorizing* signatures.
Typically, self-authorizing signatures are self-signatures, meaning signatures issued by an OpenPGP key over its own components.
Examples for self-authorizing 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-authorizing 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.
The reason is, that the issuer (sub-) key needs to be authorized to create such a signature.
This authorization typically comes via another self-signature on the key itself.
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 authorizing it to **C**ertify other keys.
Self-authorizing signatures have no such limitations.
For example, a certificate consisting only of a primary key and a single key-revocation self-signature contains everything needed to verify the revocation, as key-revocation self-signatures are self-authorizing.
This construct is referred to as a [revocation certificate](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-openpgp-v6-revocation-certi).
Signatures can be invalid due to the absence or presence of other signatures.
A signature can be valid at one point in time and invalid merely a second later.
## When are signatures valid?
There is a difference between signature *correctness* and *validity*.
As a necessary condition, a valid signature must be cryptographically correct, meaning the signature, as well as the signed information must be intact.
However, there is a difference between signature *correctness* and *validity*.
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.
The validity of a signature is constrained by a number of conditions.
First and foremost, a signature must be cryptographically correct, meaning the signature, as well as the signed information must be intact.
The validity of a correct signature is additionally constrained by a number of conditions:
Most signatures have a limited validity period, constrained by the signature creation- and expiration time.
Furthermore, some signatures need to be *qualified* by another valid signature in order to be considered valid.
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 upper constraint might be its expiration 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.
An upper constraint might be the signatures expiration 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.
For the signature to qualify as valid, it needs to be effective, in other words, the reference time must fall into the period from signature creation to signature expiration.
Futhermore, when verifying a signature which is not self-authorizing, other signatures on the certificate need to verified as well to establish authorization.
The same reference time must be used when verifying additional qualifying signatures.
For example, in order to verify a data signature over a text document, an implementation would need to verify not only the data signature itself, but also the binding signature (and back-signature) of the signing subkey, as well as the direct-key signature on the primary key of the issuer certificate.
### Self-qualifying and non-self-qualifying signatures
The signature might be invalidated by corruption of the text document, corruption of the data signature packet, expiration or revocation of the primary or signing subkey, or revocation/expiration of the primary User ID.
Furthermore, a non-self-authorizing signature might not be valid in the first place, due to a missing subkey binding signature, or a missing `SIGN_DATA` keyflag on the subkey binding signature. In this case, the signature is not authorized.
Some signatures can be verified on their own, while others require the verification of additional signatures on the issuer certificate. We will call the former category *self-qualifying* signatures.
Typically, self-qualifying signatures are self-signatures, meaning signatures issued by an OpenPGP key over its own components.
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).
To verify such 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.
This qualification typically comes via another self-signature on the key itself.
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.
Self-qualifying signatures have no such limitations.
For example, a certificate consisting only of a primary key and a single key-revocation self-signature contains everything needed to verify the revocation, as key-revocation self-signatures are self-qualifying.
This construct is referred to as a [revocation certificate](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-openpgp-v6-revocation-certi).
On the other hand, in order to verify a data signature over a text document, an implementation would need to verify not only the data signature itself, but also the binding signature (and back-signature) of the signing subkey, which qualify the signing subkey.
```{include} mermaid/09-sigtree.md
```
### Revocations
A signature might be *disqualified* by the presence of a revocation signature.
Revocations can be limited in scope, e.g. a subkey-revocation signature only revokes a single subkey.
Moreover, revocations can also be constrained to a certain validity period by including a soft revocation reason and expiration time in the revocation signature.
TODO: Give guidance, which revocations need to be considered for different types of signatures
## Which signatures take precedence?
An OpenPGP certificate can have multiple signatures with conflicting information in them.