mirror of
https://codeberg.org/openpgp/notes.git
synced 2025-09-10 11:49:40 +02:00
ch9: fix admonition syntax
This commit is contained in:
parent
02146bbe96
commit
98ec25786e
1 changed files with 9 additions and 10 deletions
|
@ -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.
|
||||
```
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue