From 058b7b5ebc6cda69326bb330e19bfaa2f1af324e Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 15 Nov 2023 19:02:41 +0100 Subject: [PATCH] Align styling of "direct key" with RFC --- book/source/09-verification.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/book/source/09-verification.md b/book/source/09-verification.md index 63ff073..b2741bb 100644 --- a/book/source/09-verification.md +++ b/book/source/09-verification.md @@ -50,9 +50,9 @@ The same reference time must be used when verifying additional qualifying signat 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 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). +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). ### Signature qualification @@ -78,14 +78,14 @@ On the other hand, in order to verify a data signature over a text document, an When determining preferences of a key, different signatures can 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. -At the same time, the specification states, that signature subpackets on the direct-key signature of the OpenPGP keys primary key apply to the whole key (therefore also to the signing subkey). +At the same time, the specification states, that signature subpackets on the direct key signature of the OpenPGP keys primary key apply to the whole key (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 of 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. +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. +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 -Attributes from the primary key's Direct-Key signature apply to the whole certificate, but can be shadowed by binding signatures. +Attributes from the primary key's direct key signature apply to the whole certificate, but can be shadowed by binding signatures. ``` 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). @@ -128,14 +128,14 @@ There might be more than one candidate for such a signature. 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 precendence. -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. ``` TODO: 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 User ID "Bob" could list "SHA256" only. 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 precendence by the way the certificate is "addressed". @@ -147,19 +147,19 @@ Preferrences are sourced from different component signatures, depending on how t 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 impementation 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. +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. But it gets more complicated still. Algorithm preferences can also "live" on subkey binding signatures, so if the certificate has a dedicated signing subkey, there is yet another signature which could take precendence. -Preferences from the subkey binding signature take precendence over the direct-key signature, but not over self-certifications on the User ID. +Preferences from the subkey binding signature take precendence over the direct key signature, but not over self-certifications on the User ID. TODO: Have a table that lists which signatures take precendence in which cases. -There can be more than one signature on a component. For example, there could be 3 direct-key signatures, e.g. because the user extended the lifespan of their key 2 times already. +There can be more than one signature on a component. For example, there could be 3 direct key signatures, e.g. because the user extended the lifespan of their key 2 times already. 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. -TODO: Direct-Key Signaures can be revoked, canceling them, meaning an older one might get active? +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 signatures can be revoked, canceling them, meaning an older one might get active? ## Complexity of the packet format