More refinements

book/source/09-verification.md

@@ -4,6 +4,8 @@
 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.
 
+## 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).
@@ -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.
 
 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?
 
@@ -29,27 +33,23 @@ First and foremost, a signature must be cryptographically correct, meaning the s
 ### Temporal validity
 
 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.
 
 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, 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.
-In order to verify, whether a signature is valid, the whole signature chain must be checked, taking expiration dates, capabilities and revocations into account.
+Futhermore, when verifying a signature which is not self-authorizing, other signatures on the certificate need to verified as well to establish authorization.
 
 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.
-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
 ```
 
-
-- Validity as a tree of signatures
-
 ## Which signatures take precedence?
 
 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?
 
 ## Complexity of the packet format
+
 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.
 
-
-
 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.