vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2025-09-10 19:59:40 +02:00
Code Issues Projects Releases Packages Wiki Activity

ch9: fix admonition syntax

Browse source
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
1 changed files with 9 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

19
book/source/09-verification.md
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. An example for how certificate validity can change with time.
``` ```
```{admonition} ```{note}
:class: note
Signature shadowing is not to be mistaken with attribute shadowing. 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. 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. 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} ```{admonition} TODO
:class: todo :class: warning
Give guidance, which revocations need to be considered for different types of signatures 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. 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. In this case, depending on how a key is "addressed", different attributes from both candidates "shadow" another.
```{admonition} ```{admonition} TODO
:class: todo :class: warning
Replace hash algorithm preferences with AEAD preferences for a more realistic example. 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. 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. Preferences from the subkey binding signature take precedence over the direct key signature, but not over self-certifications on the User ID.
```{admonition} ```{admonition} TODO
:class: todo :class: warning
Have a table that lists which signatures take precedence in which cases. 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". 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. 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} ```{admonition} TODO
:class: 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. 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.
``` ```