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

initial draft of "append only" section

Browse source
This commit is contained in:
Heiko Schaefer 2023-11-17 18:03:10 +01:00
parent 1e6eaf5d3b
commit 83d14fa5de
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 31 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

37
book/source/04-certificates.md
View file

@ -306,14 +306,39 @@ The popular [SKS keyserver network experienced certificate flooding firsthand](h
## Advanced topics
(append-only)=
### Certificates are effectively "append only" data structures
### Certificates are effectively append-only data structures
```{admonition} TODO
:class: warning
OpenPGP certificates act as *append-only data structures*, in practice. By this, we mean that packets that are associated with a certificate cannot be "recalled", once they were published. Third parties (such as other users, or keyservers) may keep and/or distribute copies of those packets.
- write
- find places in the text that should link to this section (this concept has been hinted at in more than one place, i think)
```
While it is not possible to "remove" elements, once they were publicly associated with an OpenPGP certificate, it is possible to invalidate them by adding new metadata to the certificate. This new metadata could set an *expiration time* on a component, or explicitly *revoke* that component. In both cases, no packets are removed from the certificate.
Invalidation resembles removal of a component in a semantical sense. The component is not a valid element of the certificate anymore, at least starting from some point in time. Implementations that handle the certificate may omit the invalid component in their representation.
We have to distinguish the "packet level" information about a certificate from an application-level view of that certificate. The two may differ.
#### Reasoning about append-only properties in a distributed system
OpenPGP is a thoroughly distributed system. Users can and do obtain and transmit certificate information about their own, as well as other users', certificates using a broad range of mechanisms. These mechanisms include keyservers, manual handling, WKD and [autocrypt](https://en.wikipedia.org/wiki/Autocrypt).
User's OpenPGP software may obtain different views of a particular certificate, over time. These systems have to reconcile and store a combined version of the possibly disparate elements they may obtain from different sources.
In practice, this means that various OpenPGP users may have differing views of any given certificate. For various reasons, not all users will be in possession of a fully up-to date and complete version of a certificate.
There are various potential problems associated with this fact: Users may not be aware that a component has been invalidated by the certificate holder. Revocations may not have been propagated to some third party. So for example, they may not be aware that the certificate holder has rotated their encryption subkey to a new one, and doesn't want to receive messages encrypted to the previous encryption subkey.
A defensive approach to this fact of distributed system is to "assume the worst". There are different ways of thinking about this:
- Recipients may not obtain updates to a certificate in a timely manner (this could happen for various reasons, including, but not limited to, interference by malicious actors).
- Data that is associated with a certificate may compound, and can become too large for convenient handling. If such a problem arises, then by definition, the certificate holder cannot address it: recall that the certificate holder cannot "recall" existing packets.
#### Differing "views" of a certificate exist
Another way to think about this discussion is that different OpenPGP users may have a different view of any certificate. There is a notional "canonical" version of the certificate, but we cannot assume that every user has exactly this copy. Besides propagation of elements that the certificate holder has linked to a certificate, third-party certifications are by design a distributed mechanism. A third-party certification is issued by a third party, and may or may not be distributed widely by them, or by the certificate holder. Not distributing third-party certifications widely is a workflow that may be entirely appropriate for some use cases.
As a general tendency, it is desirable for OpenPGP users to have the most complete possible view of all certificates that they interact with.
However, there are contexts in which implementations may prefer to handle only a subset of the elements of a certificate. We discuss this in the section
{ref}`cert-mini`.
(append-only)=
### Merging