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

Extract TODOs as tickets

Browse source 
Signed-off-by: David Runge <dave@sleepmap.de>
This commit is contained in:
David Runge 2023-12-12 20:07:18 +01:00
parent 910b4f9976
commit a17a3a30f2
No known key found for this signature in database
GPG key ID: 90D4B9641E092971
14 changed files with 21 additions and 147 deletions
Download patch file Download diff file Expand all files Collapse all files

1
book/source/adv/certificates.md
View file

@ -108,6 +108,7 @@ As a general tendency, it is desirable for OpenPGP users to have the most comple
However, there are contexts in which it is preferable to only use a subset of the available elements of a certificate. We discuss this in the section {ref}`cert-mini`.
(certificate-merging)=
## Merging
As described above, OpenPGP certificates are effectively [append-only](append-only) data structures. As part of the practical realization of this fact, OpenPGP software needs to *merge* different copies of a certificate.

6
book/source/adv/decryption.md
View file

@ -27,9 +27,3 @@ This is done by creating a normal PKESK packet for the recipient, but setting th
A recipient of such a message that does not find a PKESK addressed specifically to any of their keys, can then try to decrypt any anonymous PKESK packets using any of their encryption subkeys.
To reduce the number of keys to try, the recipient can skip all secret keys which do not share the public-key algorithm stated in the PKESK packet.
```{admonition} TODO
:class: warning
When did the decryption succeed? Describe quick check of the check sum and decryption of first few bytes of the SEIPD as test strategies.
```

5
book/source/adv/encryption.md
View file

@ -26,8 +26,7 @@ If the lowest common denominator of symmetric encryption algorithms preferred by
## AEAD modes in v2 SEIPD: GCM
```{admonition} TODO
:class: warning
```{note}
Produce text around discussion: https://mailarchive.ietf.org/arch/msg/openpgp/ZTYD5VJsG1k2jJBbn5zIAf5o7d4/
This section is still about to be written.
```

14
book/source/adv/signing_components.md
View file

@ -49,13 +49,7 @@ In addition to these {term}`subpackets<OpenPGP Signature Subpacket>`, {term}`sel
### Remove or revoke a User ID
Since {term}`OpenPGP certificates<OpenPGP certificate>` are often distributed by the means of {term}`key servers<Key Server>`, new {term}`signatures<OpenPGP Signature Packet>` on a {term}`certificate<OpenPGP Certificate>` are often "merged" into existing copies of the {term}`certificate<OpenPGP Certificate>` locally by the recipient.
```{admonition} TODO
:class: warning
Link to the "Merging" section in chapter 4, once merged.
```
Since {term}`OpenPGP certificates<OpenPGP certificate>` are often distributed by the means of {term}`key servers<Key Server>`, new {term}`signatures<OpenPGP Signature Packet>` on a {term}`certificate<OpenPGP Certificate>` are often "[merged](certificate-merging)" into existing copies of the {term}`certificate<OpenPGP Certificate>` locally by the recipient.
This integration process means it is practically impossible to directly remove {term}`signatures<OpenPGP Signature Packet>` or {term}`User IDs<User ID>` from a {term}`certificate<OpenPGP Certificate>`, as there is no way to communicate the intention of {term}`packet<OpenPGP Signature Packet>` deletion to the recipient.
@ -110,12 +104,6 @@ In {term}`Subkey Revocation signatures<Subkey Revocation Signature Packet>`, the
Note that a value of `32` is not applicable in these {term}`signatures<OpenPGP Signature Packet>`.
```{admonition} TODO
:class: warning
Research and explain hardness in the context of subkey revocations. What does a hard subkey revocation express concretely?
```
### Revoke a certificate
Users may find themselves needing to revoke their entire {term}`OpenPGP certificate`, rendering it unusable. This could be for various reasons, such as migrating to a new {term}`certificate<OpenPGP certificate>` or in response to a compromise of the {term}`certificate<OpenPGP certificate>`'s {term}`secret key material<Private Key Material>`.

18
book/source/adv/verification.md
View file

@ -80,12 +80,6 @@ Alternatively, there can be competing qualifying signatures of different types,
Depending on how a certificate is "located," different metadata from possible candidate signatures "shadow" one another. The RFC [states](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-notes-on-self-signatures) that when a certificate is "located" by the OpenPGP software "via an identity", then the metadata associated with that identity takes precedence over more global metadata, such as that associated with the certificate's primary key, with a direct key signature.
```{admonition} TODO
:class: warning
Replace hash algorithm preferences with AEAD preferences for a more realistic example.
```
For example, the latest direct key signature could list "SHA512, SHA384" as hash algorithm preferences, while the latest self-certification of the User ID "Bob" could list only "SHA256."
For yet another User ID "Bobby," the self-signature could list no hash algorithm preferences at all.
If the user wants to compose a signed message using the associated OpenPGP key they need to figure out which preferences to use.
@ -106,22 +100,10 @@ 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} TODO
:class: warning
Have a table that lists which signatures take precedence in which cases.
```
There can be more than one signature on a component. As an example, there are 3 direct key signatures (e.g., because the key's expiry has been extended two times).
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} 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.
```
## Complexity of the packet format
OpenPGP certificates can contain complex preference settings. Additionally, the OpenPGP packet format allows a lot of flexibility when storing certificates in TPK format.