mark "TODO"-blocks with admonition markup

(also see https://codeberg.org/openpgp/notes/issues/3)
This commit is contained in:
Heiko Schaefer 2023-09-26 13:22:12 +02:00
parent c72432af4b
commit 225e3c3a8d
No known key found for this signature in database
GPG key ID: 4A849A1904CCBD7D
7 changed files with 40 additions and 11 deletions

View file

@ -1,9 +1,10 @@
# Cryptographic concepts/terms # Cryptographic concepts/terms
``` ```{admonition} TODO
Lars suggests that we should have a chapter where we introduce cryptographic terms that we use, and give short definitions (without getting into how specific algorithms work) :class: warning
This would be a good place to introduce visualizations for cryptographic primitives - Introduce cryptographic primitives/terms at a very superficial level
- Introduce visualizations for cryptographic primitives
``` ```
## Public-key cryptography ## Public-key cryptography
@ -45,17 +46,24 @@ OpenPGP makes heavy use of public-key cryptography. However, for historical reas
So when reading the RFC, or other documentation, you will encounter the term "secret key," instead of the more common "private key." So when reading the RFC, or other documentation, you will encounter the term "secret key," instead of the more common "private key."
### Symmetric encryption ## Symmetric encryption
https://en.wikipedia.org/wiki/Symmetric-key_algorithm https://en.wikipedia.org/wiki/Symmetric-key_algorithm
[TODO: visualization?] ```{admonition} TODO
:class: warning
#### Symmetric cryptography in OpenPGP - visualization?
```
### Symmetric cryptography in OpenPGP
Symmetric encryption is a core concept in OpenPGP. It usually comes up involving the term "session key." Symmetric encryption is a core concept in OpenPGP. It usually comes up involving the term "session key."
"Session keys" in OpenPGP are symmetric cryptographic keys. "Session keys" in OpenPGP are symmetric cryptographic keys.
## Hashing
## Cryptographic signatures ## Cryptographic signatures
## AEAD

View file

@ -1,7 +1,9 @@
(private_key_chapter)= (private_key_chapter)=
# Private keys # Private keys
``` ```{admonition} TODO
:class: warning
- Consistently consider private key material as a separate thing from Certificates? (like in pkcs#11?) - Consistently consider private key material as a separate thing from Certificates? (like in pkcs#11?)
``` ```

View file

@ -1,2 +1,13 @@
(signing_data)= (signing_data)=
# Signatures over data # Signatures over data
```{admonition} TODO
:class: warning
Add content, including:
- Signature of a binary document
- Signature of a canonical text document
- "The signature is calculated over the text data with its line endings converted to `<CR><LF>`"
```

View file

@ -1,6 +1,8 @@
# Signature "internals" # Signature "internals"
``` ```{admonition} TODO
:class: warning
- Subpackets and how to make sense of them - Subpackets and how to make sense of them
- "Negotiating" signature hash algorithm based on recipients preference subpackets - "Negotiating" signature hash algorithm based on recipients preference subpackets
- Explore viability of having multiple signatures, e.g. v4+v6? - Explore viability of having multiple signatures, e.g. v4+v6?

View file

@ -1,7 +1,9 @@
(decryption_chapter)= (decryption_chapter)=
# Decryption # Decryption
``` ```{admonition} TODO
:class: warning
- using expired certificate? - using expired certificate?
- using revoked certificate? - using revoked certificate?
- using expired subkey? - using expired subkey?

View file

@ -1,5 +1,7 @@
# Migration from v4 to v6 # Migration from v4 to v6
``` ```{admonition} TODO
:class: warning
Also see: https://wiki.gnupg.org/OpenPGPEmailSummit202305Notes Also see: https://wiki.gnupg.org/OpenPGPEmailSummit202305Notes
``` ```

View file

@ -1,6 +1,8 @@
# Algorithms and Policy # Algorithms and Policy
``` ```{admonition} TODO
:class: warning
- What algorithms are trustworthy? -> Depend on regulatory bodies like the BSI? - What algorithms are trustworthy? -> Depend on regulatory bodies like the BSI?
- How to decide, when to deprecate / reject algorithms (how to be competent) - How to decide, when to deprecate / reject algorithms (how to be competent)
- Transitioning from one set of algorithms to another (Interoperability) - Transitioning from one set of algorithms to another (Interoperability)