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

Section about self-authorizing signatures

Browse source
This commit is contained in:
Paul Schaub 2023-11-08 12:53:33 +01:00 • committed by Heiko Schaefer
parent 3276ab79d7
commit 6061b037e4
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 17 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -6,7 +6,22 @@ SPDX-License-Identifier: CC-BY-SA-4.0
(verification_chapter)= (verification_chapter)=
# Verification # Verification
- Self-authenticating data (unhashed subpackets) 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.
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.
## When are signatures valid? ## When are signatures valid?
@ -63,7 +78,7 @@ In general, for each component, only the newest self-signature is "in effect", a
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. 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.
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
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.