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

edits for clarity

Browse source
This commit is contained in:
Heiko Schaefer 2023-11-26 17:45:25 +01:00
parent 1a280ab499
commit f446b12548
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 96 additions and 63 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -7,80 +7,97 @@ SPDX-License-Identifier: CC-BY-SA-4.0
# Signature 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.
Most importantly, its expiration date:
A signature can be valid at one point in time and invalid merely a second later.
Many factors influence the validity of a signature.
Firstly, its expiration date: A signature can be valid at one point in time and expired 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 signatures, mostly within the issuer's certificate.
## When are signatures valid?
As a necessary condition, a valid signature must be [cryptographically correct](sig-verify), 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 cryptographically correct, but still not qualify as a *valid* signature.
As a necessary condition, a valid signature must be [cryptographically correct](sig-verify). This means that both the signature and its signed input data must be intact.
However, there is a difference between signature *correctness* and *validity*:
A signature may be cryptographically correct, but still not qualify as a *valid* signature.
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:
* **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 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 accepted 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 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.
* **Well-formedness**: Signature packets need to be well-formed, meaning they must contain the required signature subpackets in the proper subpacket area and must not contain unknown critical subpackets or unknown critical notations[^unknown-critical]. Some implementations additionally apply a policy that constrains accepted hash algorithms, cryptographic 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 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.
[^unknown-critical]: Note that this implies that a signature might be considered valid by one implementation and be rejected by another, based on the set of subpackets and notations each implementation is aware of.
### Well-formedness of signatures
There is a number of criteria, that a signature must fulfill in order to be considered well-formed:
There are a number of criteria that a signature must fulfill to be considered well-formed:
- Each signature MUST have a signature creation time subpacket in its hashed subpacket area. A signature with only a unhashed creation time - or none at all - is not well-formed.
- The signature cannot be older than the key that issued it.
- Analogous, a signature with a creation time in the future needs to be rejected as well.
- A well-formed signature needs to carry an Issuer Fingerprint subpacket, or an Issuer KeyID subpacket.
It is generally recommended to place those in the hashed area of the signature, but a receiving implementation may also accept signatures which only contain unhashed copies of these subpackets.
- A signature disqualifies as well-formed, if it contains subpackets unknown to the implementation, which are marked as critical.
Unknown subpackets which are not marked as critical do not have an effect on whether the signature is well-formed.
- The same applies to notations. Critical, unknown notations result render the signature malformed.
- Each signature MUST have a signature creation time subpacket in its hashed subpacket area. A signature with only an unhashed creation time - or none at all - is not well-formed.
- The signature cannot be older than the component key that issued it.
- Analogously, a signature with a creation time in the future needs to be rejected as well.
- A well-formed signature needs to carry an Issuer Fingerprint subpacket, or an Issuer KeyID subpacket. It is generally recommended to place Issuer subpackets in the hashed area of the signature, but a receiving implementation may also accept signatures which only contain unhashed copies of these subpackets.
- A signature disqualifies as well-formed if it contains subpackets which are marked as critical, but unknown to the receiving implementation. Unknown subpackets which are not marked as critical do not have an effect on whether the signature is well-formed.
- The same applies to notations. Unknown notations that are marked as critical render the signature malformed.
(temporal-validity)=
### Temporal validity
A signature is valid only for a constrained period of time:
- The creation time of the signature acts as a lower bound for the validity. A signature only becomes valid after its creation time. Hard revocation signatures are an exception: They are by definition valid at any point in time, and have no lower temporal bound.
- The creation time of the signature acts as a lower bound for the validity. A signature only becomes valid at its creation time. Hard revocation signatures are an exception: They are by definition valid at any point in time, and have no lower temporal bound.
- If present, the signature's expiration time acts as a natural upper bound for its validity.
When checking a signature for validity, a reference time is used.
This can be the current time during validation, or a point in time that relates to the signature that is getting checked.
For example, when checking a signature in an email, the reference time might be the signature creation time, or the time of receipt for the email.
When checking a signature for validity, a reference time is used. The validity of the signature is evaluated at that reference time.
The reference time can be:
- the current time during validation, or
- another point in time that is significant to the signature that is validated. For example, when checking the signature of an email, the reference time might be the signature creation time, or the time of receipt of the email.
For the signature to qualify as valid, it needs to be in effect. In other words, the reference time must fall into the period between signature creation and signature expiration.
The same reference time must be used when verifying additional qualifying signatures.
The same reference time must be used when verifying required qualifying signatures, if any.
### Self-qualifying and non-self-qualifying signatures
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`).
Typically, self-qualifying signatures are self-signatures, meaning signatures issued by an OpenPGP primary key for the components in its certificate.
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
- self-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`),
- third-party key-revocations (`0x20`),
- third-party certification (`0x10`-`0x13`), or
- third-party certification revocation signatures (`0x30`).
### Signature qualification
To verify non-self-qualifying signatures, it is required to look at more than just the signature itself.
The reason is, that the issuer (sub-) key needs to be qualified to create such a signature (e.g. because a specific key-flag is required).
This qualification typically emerges via a self-signature on the key itself.
To verify non-self-qualifying signatures, it is necessary to look at more than just the signature itself.
This is required because the issuing component key needs to be qualified to create such a signature (e.g., because a specific capability key flag is required). The qualification typically emerges via a self-signature on the key itself.
In short, 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 issuer's certificate via a subkey binding signature. That binding signature needs to contain a *key flags* subpacket that marks the subkey as *signing* capable.
Similarly, certification signatures over third-party certificates require the issuer key to carry a self-signature with the *certification* key flag.
Similarly, certification signatures over third-party certificates require the issuer key to carry a valid self-signature with the *certification* key flag.
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).
@ -90,16 +107,17 @@ On the other hand, to verify a data signature over a text document, an implement
:name: fig-signature-verification-signature-tree
:alt: Depicts a diagrammatic representation of a certificate and a data signature. Arrows between the primary key and other components of the certificate show, how signatures bind the certificate together. In this example, they form a tree of signatures, which all need to be verified in order for the data signature to be valid.
Tree of signatures
Tree of signatures that qualify a data signature
```
### Attribute shadowing
When determining preferences of a key, several signatures may have to be inspected.
For example, when using a signing subkey to generate a data signature, the implementation might want to check for hash algorithm preferences on the subkey binding signature.
However, the RFC [states](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.2.3.10-2), that signature subpackets on the direct key signature of the OpenPGP certificate's primary key (which also may contain preferences) apply to the entire OpenPGP key (therefore also to the signing subkey).
When determining the preferences of a key, several signatures may have to be inspected.
In this case, the implementation uses the preferences from the subkey binding signature, but if no such subpacket is found on the latest binding signature, it falls back to the preferences of the direct key signature.
For example, when using a signing subkey to generate a data signature, an implementation might want to check for hash algorithm preferences on the subkey binding signature.
However, the RFC [states](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.2.3.10-2) that signature subpackets in a direct key signature (which may also contain preferences) on the OpenPGP certificate's primary key apply to the entire OpenPGP key, and therefore also to the signing subkey.
In this case, the implementation uses the preferences from the subkey binding signature, but if no such subpacket is found on the latest binding signature, it falls back to the preferences from the direct key signature.
This is called attribute shadowing, since direct key signature subpackets apply to all subkeys, but are shadowed by binding signature subpackets.
```{figure} drawio/attribute-shadowing.png
@ -112,13 +130,23 @@ Inheritance and Shadowing of Attributes
```{admonition} Note
:class: note
Attribute shadowing should only be used for algorithm preferences, since there are subpacket types where shadowing makes no sense (e.g. key expiration time subpackets).
Attribute shadowing is relatively straightforward to reason about when used for algorithm preferences. For other subpacket types, shadowing may be confusing, and/or the semantics underspecified (e.g. for key expiration time subpackets).
```
### Signature shadowing
When inspecting signatures on a component of an OpenPGP certificate, of the signatures that are in effect for each function, only the newest is considered.
In other words; If there are three binding signatures `A, B, C` for a subkey, where `A` was created at `t0`, `B` at `t1` and `C` at `t3` with `t0 < t1 < t2 < t3`, at `t2` an implementation only needs to consider `B`, as `C` is not yet in effect. `A` is shadowed, because it is older than `B`.
In other words:
- If there are three binding signatures `A, B, C` for a subkey,
- where:
- `A` was created at `t0`,
- `B` at `t1`, and
- `C` at `t3`, with
- `t0 < t1 < t2 < t3`.
- Then at `t2`, an implementation only needs to consider signature `B`,
- because `C` is not yet in effect, and
- `A` is shadowed, because it is older than `B`.
```{figure} drawio/cert-validity-subkey.png
:name: fig-signature-verification-subkey-validity
@ -129,10 +157,10 @@ An example for how certificate validity can change with time.
```{note}
Signature shadowing is not to be mistaken with attribute shadowing.
Signature shadowing should not be confused with attribute shadowing.
```
As attribute and signature shadowing can occur in combination, it is not always obvious, which properties a key has at a given time.
As attribute and signature shadowing can occur in combination, it is not always obvious which properties a key has at a given time.
```{figure} drawio/dk-attributes-and-shadowing.png
:name: fig-signature-verification-signature-shadowing
@ -143,27 +171,28 @@ Signatures shadow one another, based on reference time.
### 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.
A signature can 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.
```{admonition} TODO
:class: warning
Give guidance, which revocations need to be considered for different types of signatures
Give guidance which revocations need to be considered for different types of signatures
```
## Which signatures take precedence?
An OpenPGP certificate or component can have multiple signatures with conflicting information attached to it.
Multiple signatures can be attached to an OpenPGP certificate or component. These signatures can contain conflicting information.
When verifying a non-self-qualifying signature, an implementation needs to consider self-qualifying signatures on the issuer's certificate for qualification.
When verifying a signature that is not self-qualifying, an implementation needs to consider self-qualifying signatures on the issuer's certificate for qualification.
There might be several signatures per component.
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 precedence.
For example, there could be multiple subkey binding signatures for one subkey.
In general, for each category of signatures, only the signature with the latest creation time is considered and takes precedence.
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.
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.
```{admonition} TODO
@ -172,9 +201,10 @@ In this case, depending on how a key is "addressed," different attributes from b
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 the User ID "Bob" could list only "SHA256."
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.
The specification recommends that implementations decide which signature takes precedence by the way the certificate is "addressed."
```{figure} drawio/narrow-interpretation.png
@ -185,7 +215,7 @@ Preferences are sourced from signatures on different components, depending on ho
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 implementation 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.
The same is true if the certificate is used without any User ID as sender.
To complicate things further:
Algorithm preferences can also be stated on subkey binding signatures, so if the certificate has a dedicated signing subkey, there is yet another signature which could take precedence.
@ -197,7 +227,7 @@ Preferences from the subkey binding signature take precedence over the direct ke
Have a table that lists which signatures take precedence in which cases.
```
There can be more than one signature on a component. As an example, there are 3 direct key signatures (e.g., due to extending the key's expiry two times).
There can be more than one signature on a component. As an example, there are 3 direct key signatures (e.g., because the key's expiry has been extended two times).
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.
@ -209,8 +239,11 @@ direct key signatures can be revoked, [canceling them](https://www.ietf.org/arch
## Complexity of the packet format
Unfortunately, the OpenPGP packet format allows a lot of flexibility when composing certificates.
User ID packets, for example, are not fixed in regard to their position, which means that an attacker (or an implementations internal certificate canonicalization procedure) can change the order in which User IDs appear in the certificate's packet sequence.
OpenPGP certificates can contain complex preference settings. Additionally, the OpenPGP packet format allows a lot of flexibility when storing certificates in TPK format.
As a concrete example, consider a certificate with multiple User IDs, all marked as primary. Or equally, 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.
User ID packets, for example, do not have a fixed position in a TPK. This means an attacker (or an implementation-internal certificate canonicalization procedure) can change the order in which User IDs appear in the certificate's packet sequence.
As a concrete example, consider a certificate with multiple User IDs, all marked as primary. Or similarly, 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.
Such subtle changes to the representation of a certificate can lead to different preference settings being deduced, by different OpenPGP implementations.