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

More refinements

Browse source
This commit is contained in:
Paul Schaub 2023-11-08 13:10:40 +01:00
parent ed75ebbecd
commit eb2ab7beff
Signed by: vanitasvitae
GPG key ID: 62BEE9264BF17311
1 changed files with 8 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -4,6 +4,8 @@
Signature verification in the OpenPGP protocol is a complex process. Signature verification in the OpenPGP protocol is a complex process.
Some signatures can be verified standalone, while others require the verification of a chain-like structure of other signatures, mostly on the issuers certificate. 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. 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. 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 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).
@ -17,6 +19,8 @@ For example, a data signature over an email body may be issued by a subkey only
Similarly, certification signatures over third-party certificates require the issuer key to carry a self-signature authorizing it to **C**ertify other keys. 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. 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).
## When are signatures valid? ## When are signatures valid?
@ -29,27 +33,23 @@ First and foremost, a signature must be cryptographically correct, meaning the s
### Temporal validity ### Temporal validity
A signature is valid only for a constrained period of time. A signature is valid only for a constrained period of time.
A hard, lower constraint for the validity period is the creation time of the signature. A lower constraint for the validity period is the creation time of the signature.
An upper constraint might be its expiration time. An upper constraint might be its expiration time.
When checking a signature for validity, a reference time is defined. 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 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. 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, signatures on a certificate form a chain, or rather a tree of signatures, originating from the certificates primary key down to signatures issued by the certificate. Futhermore, when verifying a signature which is not self-authorizing, other signatures on the certificate need to verified as well to establish authorization.
In order to verify, whether a signature is valid, the whole signature chain must be checked, taking expiration dates, capabilities and revocations into account.
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. 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.
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. 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, the 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. 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.
```{include} mermaid/09-sigtree.md ```{include} mermaid/09-sigtree.md
``` ```
- Validity as a tree of signatures
## Which signatures take precedence? ## Which signatures take precedence?
An OpenPGP certificate can have multiple signatures with conflicting information in them. An OpenPGP certificate can have multiple signatures with conflicting information in them.
@ -74,11 +74,10 @@ For each certificate, there is at most one "active" direct-key signature, for ea
TODO: Direct-Key Signaures can be revoked, canceling them, meaning an older one might get active? TODO: Direct-Key Signaures can be revoked, canceling them, meaning an older one might get active?
## Complexity of the packet format ## Complexity of the packet format
Unfortunately, the OpenPGP packet format allows for quite a lot of flexibility when composing certificates. 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. 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. 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. Clients might apply different heuristics to figure out, which User-ID actually qualifies as the primary User-ID here.