ch9: fix admonition syntax

This commit is contained in:
Heiko Schaefer 2023-11-25 20:15:11 +01:00
parent 02146bbe96
commit 98ec25786e
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB

View file

@ -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.
```