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

minor edits

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

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

@ -8,10 +8,10 @@ SPDX-License-Identifier: CC-BY-SA-4.0
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:
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 within the issuer's certificate.
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?
@ -34,6 +34,7 @@ This is especially the case with signatures created by dedicated signing subkeys
Lastly, signatures can be invalidated by revocations.
### Well-formedness of signatures
There is a number of criteria, that a signature must fulfill in order 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.
@ -51,7 +52,6 @@ Unknown subpackets which are not marked as critical do not have an effect on whe
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.
- 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.
@ -84,7 +84,7 @@ 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.
On the other hand, to verify a data signature over a text document, an implementation needs to verify not only the data signature itself, but also the binding signature (and back-signature) of the signing subkey which qualifies the signing subkey.
```{figure} mermaid/09-sigtree.png
:name: fig-signature-verification-signature-tree
@ -164,7 +164,7 @@ For example, there might be multiple subkey binding signatures for the same subk
In general, for each category of signatures, only that with the latest signature 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.
In this case, depending on how a key is "addressed", different attributes from both candidates "shadow" another.
In this case, depending on how a key is "addressed," different attributes from both candidates "shadow" another.
```{admonition} TODO
:class: warning
@ -173,17 +173,17 @@ Replace hash algorithm preferences with AEAD preferences for a more realistic ex
```
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.
The specification recommends, that implementations decide which signature takes precedence by the way the certificate is "addressed".
The specification recommends that implementations decide which signature takes precedence by the way the certificate is "addressed."
```{figure} drawio/narrow-interpretation.png
Preferences are sourced from signatures on different components, depending on how the key is addressed.
```
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.
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.
@ -197,8 +197,8 @@ 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).
In general, for each component, only the newest self-signature is "in effect", and older signatures are "shadowed".
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).
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.
```{admonition} TODO
@ -210,7 +210,7 @@ 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.
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.
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.