vanitasvitae
/
openpgp-notes
mirror of https://codeberg.org/openpgp/notes.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

rework former 18.2 and 18.3 into new 18.3 on merging and updating certificates

This commit is contained in:
Tammi L. Coles 2024-02-08 16:13:18 +01:00
parent a23321f3b0
commit 6d0deb643b
1 changed files with 54 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

105
book/source/adv/certificates.md
View File

@ -64,65 +64,68 @@ By understanding the mechanisms and semantics of revocation, OpenPGP users and i
[^undo-revocations]: While some revocations can be reverted, undoing revocations is an uncommon workflow. Unlike expirations, which are commonly undone by extending the expiration time.
(append-only)=
## Certificates are effectively append-only data structures
OpenPGP certificates act as *append-only data structures*, in practice. 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.
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 decentral and 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, [Web Key Directory](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/) (WKD) and [Autocrypt](https://en.wikipedia.org/wiki/Autocrypt).
Different users' OpenPGP software may obtain different views of a particular certificate, over time. Individual users' OpenPGP instances have to reconcile and store a combined version of the possibly disparate elements they 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.
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 times 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 associated with a certificate may compound, and a certificate can become too large for convenient handling, even in the course of normal operations (for example, a certificate may receive very many legitimate third-party certifications). If such a problem arises, then by definition, the certificate holder cannot address it: remember 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[^tpc-privacy].
[^tpc-privacy]: The two parties to a certification (the issuer and the target of the certification) may prefer not to publish their mutual association. Also see {ref}`social-graph-metadata-leak`.
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 it is preferable to only use a subset of the available elements of a certificate. We discuss this in the section {ref}`minimization`.
(certificate-merging)=
## Merging
## 18.3 Merging and updating certificates
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.
OpenPGP's design as a decentralized and distributed system poses unique challenges and considerations for certificate management. This section explores strategies for merging certificates, handling unauthenticated information, and the implications of OpenPGP's append-only data structure on certificate validity and trust.
For example, Bob's OpenPGP software may have a local copy of Alice's certificate, and obtain a different version of Alice's certificate from a keyserver. The goal of the implementation is to add new information about Alice's certificate, if any, to the local copy. Alice may have added a new identity, replaced a subkey with a new subkey, or revoked some components of her certificate. Or, Alice may have revoked her certificate, signaling that she doesn't want communication partners to use that certificate anymore. All of these updates could be crucial for Bob to be aware of.
### Strategies for merging certificates
Merging two versions of a certificate involves making decisions about which packets should be kept. The versions of the certificate will typically contain some packets that are identical. No duplicates of the exact same packet should be stored in the merged version of the certificate. Additionally, if the newly obtained copy contains packets that are in fact entirely unrelated to the certificate, those should not be retained (a third party may have included unrelated packets, either by mistake, or with malicious intent).
Merging certificates in OpenPGP involves reconciling various pieces of information from different sources to construct a unified and up-to-date view of a certificate. This process is crucial when different copies of a certificate, each potentially containing unique data, need to be consolidated into a single, coherent certificate view.
For example, Bob’s OpenPGP software may have a local copy of Alice’s certificate, and obtain a different version of Alice’s certificate from a keyserver. The goal of the implementation is to add new information about Alice’s certificate, if any, to the local copy. Alice may have added a new identity, replaced a subkey with a new subkey, or revoked some components of her certificate. Or, Alice may have revoked her certificate, signaling that she doesn’t want communication partners to use that certificate anymore. All of these updates could be crucial for Bob to be aware of.
Key strategies for effective certificate merging include:
- **Timestamp verification**: Compare the timestamps on certificate components from different sources. Retain the most recent information, such as the latest revocation status or key expiration dates, to ensure the certificate view is current.
- **Signature validation**: Verify the signatures on each component of the certificate. Only incorporate components with valid signatures into the merged view, discarding any data that cannot be authenticated.
- **Conflict resolution**: When conflicting information is present (e.g., differing subkey sets from two sources), prioritize data from more reliable or directly obtained sources, such as WKD or a direct exchange with the certificate owner.
- **Revocation checks**: Pay special attention to revocation signatures. A revocation signature supersedes all other information about the revoked component, marking it as invalid regardless of other data.
Implementing these strategies helps OpenPGP software and users to manage the complexities of certificate information distributed across the decentralized OpenPGP ecosystem, ensuring that the operational view of a certificate is both comprehensive and accurate.
### Handling unauthenticated information
For information that *is* related to the certificate, but not bound to it by a self-signature, there is no generally correct approach. The receiving implementation must revolve these cases, possibly in a context-specific manner. Such cases include:
In the OpenPGP ecosystem, certificates often accumulate information that is not directly authenticated by the certificate owner, such as third-party certifications or subkeys. Handling this unauthenticated information requires careful consideration to maintain the trustworthiness of the certificate.
- Third-party certifications. These could be valuable information, where a third party attests that the association of an identity to a certificate is valid. On the other hand, they could also be a type of spam.
- Subpackets in the unhashed area of a signature packet. Again, these could contain information that is useful to the recipient. However, the data could also be either useless, or even misleading/harmful.
For information that *is* related to the certificate but not bound to it by a self-signature, implementations need to navigate these cases thoughtfully, often in a context-specific manner. Challenges include:
- **Third-party certifications**, which may either be valuable endorsements of an identity’s association with a certificate or could serve as spam.
- **Subpackets in the unhashed area of a signature packet**, which could contain either useful or potentially misleading information.
The key is to balance the inclusion of potentially valuable third-party information with the risk of incorporating misleading or harmful data. Strategies may include user-configurable trust settings, software that prioritizes data verified by trusted sources, and mechanisms for users to manually verify or reject unauthenticated information.
(append-only)=
### OpenPGP certificates as append-only data structures
OpenPGP certificates act as *append-only data structures*, in practice. Once packets are associated with a certificate and published, they cannot be "recalled." This ensures the integrity and auditability of certificate changes over time. Third parties, including other users and keyservers, may keep and distribute copies of these packets.
Invalidation of components, achieved by adding new metadata such as expiration times or revocation signatures, does not remove packets from the certificate. Instead, it semantically "removes" the component's validity, allowing implementations to omit these invalid elements from their operational view of the certificate.
### Reasoning about append-only properties in a distributed system
The decentralized nature of OpenPGP allows users to share and receive certificate information through various mechanisms, including keyservers, manual handling, [Web Key Directory](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/) (WKD), and [Autocrypt](https://en.wikipedia.org/wiki/Autocrypt). This can lead to different users having different views of a certificate at any given time.
These differing views necessitate a process within OpenPGP software to reconcile and store a combined version of the certificate elements obtained from disparate sources. This aspect underlines the importance of assuming a defensive posture when reasoning about the validity and completeness of certificate information in OpenPGP's distributed environment.
When considering edge cases within this distributed system, it's prudent to "assume the worst." For instance:
- Recipients may not obtain updates to a certificate in a timely manner, for various reasons including, but not limited to, interference by malicious actors. This delay in receiving updates could lead to the use of outdated or compromised keys, undermining the security of communications.
- Data associated with a certificate may compound over time, leading to a certificate that is too large for convenient handling. This situation can arise when a certificate accumulates a significant number of legitimate third-party certifications. In such cases, the certificate holder is limited in their ability to manage the certificate's size, as the OpenPGP standard does not allow for the direct removal of existing packets.
### Differing views of a certificate
Variability in certificate views among OpenPGP users highlights the system's inherent complexity and the challenges in ensuring all parties have an accurate, up-to-date understanding of a certificate's status. Defensive practices, such as regular certificate updates and careful consideration of certificate expiration and revocation, are vital in navigating these challenges.
Different OpenPGP implementations may handle these challenges in various ways, emphasizing the need for users to understand the potential for discrepancies and adopt practices that ensure the security and reliability of their cryptographic communications.
The diversity of certificate views, influenced by distributed third-party certifications, underscores the complexity of managing privacy and trust within OpenPGP. Users must navigate these challenges with an understanding that not all certificate information may be equally available or desirable to share widely, emphasizing a cautious approach to certificate data management[^tpc-privacy]..
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]. This approach not only helps in naturally eliminating unused keys but also enforces periodical checks on the primary key, thereby promoting a consistent and up-to-date view of the certificate across different users.
[^tpc-privacy]: The two parties to a certification (the issuer and the target of the certification) may prefer not to publish their mutual association. Also see {ref}`social-graph-metadata-leak`.
[^mgorny]: See, for example, [here](https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/): "Expiration times really serve two purposes: naturally eliminating unused keys, and enforcing periodical checks on the primary key."
(minimization)=
## Certificate minimization