From 61ada929e7c33b931bf25b1ff1dc53cb9a3dca4e Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 22 Nov 2023 17:50:36 +0100 Subject: [PATCH] ch4: process feedback from wiktor --- book/source/04-certificates.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 0b1e197..73651a1 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -310,7 +310,7 @@ The popular [SKS keyserver network experienced certificate flooding firsthand](h 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. -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. +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. @@ -318,7 +318,7 @@ We have to distinguish the "packet level" information about a certificate from a #### 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). +OpenPGP is a thoroughly distributed system. Users can 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. @@ -326,10 +326,18 @@ In practice, this means that various OpenPGP users may have differing views of a 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: +One mechanism that addresses a part of this issue is *expiration*: By setting their certificates to expire after an appropriate interval, certificate holders can force their communication partners to refresh their certificate, e.g. from a keyserver[^mgorny]. + +[^mgorny]: See, for example, [here](https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/): "Expiration dates really serve two purposes: naturally eliminating unused keys, and enforcing periodical checks on the primary key." + +Good practices, like setting appropriate expiration times, can mitigate the complexity of the inherently distributed nature of certificates. + +However, such mitigations by definition cannot address all possible cases of outdated certificate information in a decentralized, asynchronous system such as OpenPGP. So a defensive approach is generally appropriate when reasoning about the view of certificates that different actors have. + +When thinking about edge cases, it's useful to "assume the worst." For example: - 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. +- Data 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