From 98ec25786e59345e8f1ad7146abdf42f419cc19a Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 25 Nov 2023 20:15:11 +0100 Subject: [PATCH] ch9: fix admonition syntax --- book/source/09-verification.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/book/source/09-verification.md b/book/source/09-verification.md index 44e5826..4d495ab 100644 --- a/book/source/09-verification.md +++ b/book/source/09-verification.md @@ -127,8 +127,7 @@ In other words; If there are three binding signatures `A, B, C` for a subkey, wh An example for how certificate validity can change with time. ``` -```{admonition} -:class: note +```{note} Signature shadowing is not to be mistaken with attribute shadowing. ``` @@ -148,8 +147,8 @@ 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. 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} -:class: todo +```{admonition} TODO +:class: warning Give guidance, which revocations need to be considered for different types of signatures ``` @@ -167,8 +166,8 @@ In general, for each category of signatures, only that with the latest signature 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} -:class: todo +```{admonition} TODO +:class: warning Replace hash algorithm preferences with AEAD preferences for a more realistic example. ``` @@ -192,8 +191,8 @@ 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. Preferences from the subkey binding signature take precedence over the direct key signature, but not over self-certifications on the User ID. -```{admonition} -:class: todo +```{admonition} TODO +:class: warning Have a table that lists which signatures take precedence in which cases. ``` @@ -202,8 +201,8 @@ There can be more than one signature on a component. As an example, there are 3 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} -:class: todo +```{admonition} TODO +:class: warning direct key signatures can be revoked, [canceling them](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.2.3.10-4), meaning an older direct-key signature might become active again? The text of the spec is confusing here. ```