From a23f65282b49a07139f56ef086a793265b9e56b2 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 6 Dec 2023 10:47:53 +0100 Subject: [PATCH] input from david --- book/source/04-certificates.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 1df8625..e23dbbf 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -381,7 +381,7 @@ However, such mitigations by definition cannot address all possible cases of out 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. If such a problem arises, then by definition, the certificate holder cannot address it: remember that the certificate holder cannot "recall" existing packets. +- 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 @@ -560,7 +560,7 @@ Different mechanisms allow certificate lookup by email, for example: - The [keys.openpgp.org](https://keys.openpgp.org/) "verifying keyserver" (also known as ["hagrid"](https://gitlab.com/keys.openpgp.org/hagrid), the name of the server software it runs) - SKS-style OpenPGP keyservers (today, most of these run the [Hockeypuck](https://github.com/hockeypuck/hockeypuck) software) -Their properties differ, also see {ref}`distribution`. +Their properties differ, for more see {ref}`distribution`. (cert-freshness)= ### Certificate freshness: Triggering updates with an expiration time @@ -582,7 +582,7 @@ These certifications form the back-bone of the OpenPGP trust-model called the We OpenPGP software can inspect that graph. Based on the certification data in the graph and a set of trust anchors, it can infer whether a target certificate is legitimate. -The trust anchor is usually the certificate holder's own key, but a user may designate additional certificates of organizations they are connected to as trust anchors. +The trust anchor is usually the certificate holder's own key, but a user may designate additional certificates of entities they are connected to as trust anchors. Third-party certifications can be published as part of the target certificate to facilitate the process of certificate authentication. Unfortunately, a side effect of this approach is that it's feasible to reconstruct the entire social graph of all people issuing certifications. In addition, the signature creation time of certifications can be used to deduce whether the certificate owner attended a Key Signing Party (and if it was public, where it was held) and whom they interacted with. @@ -594,7 +594,7 @@ So, there is some tension between the goals of (unbound_user_ids)= ### Adding unbound, local, User IDs to a certificate -Some OpenPGP subsystems may add User IDs to a certificate, which are not bound to the primary key by the certificate's owner. This can be useful to store local identity information (e.g., Sequoia's public store attaches ["pet-names"][PET] to certificates, in this way). +Some OpenPGP software may add User IDs to a certificate, which are not bound to the primary key by the certificate's owner. This can be useful to store local identity information (e.g., Sequoia's public store attaches ["pet-names"][PET] to certificates, in this way). [PET]: https://sequoia-pgp.org/blog/2023/04/08/sequoia-sq/#an-address-book-style-trust-model @@ -606,7 +606,7 @@ To prevent accidental publication of these local User IDs (e.g. to public keyser Different mechanisms for discovering certificates, and updating certificate data exist in the OpenPGP space: -- A *Web Key Directory* service is operated by the entity that controls the domain name of the email in question. This means that WKD is decentralized, and the reliability of OpenPGP certificates may vary depending on the organization that operates a particular WKD instance. +- A *Web Key Directory* service is based on a well-known location on a webserver, serving certificates in a specific format. A WKD server is operated by the entity that controls the DNS domain of an email-based identity of a certificate. This means that WKD is inherently decentralized, and the reliability of OpenPGP certificates may vary depending on the organization that operates a particular WKD instance. - The *keys.openpgp.org* service is a "verifying" keyserver: the keyserver software only publishes identity components (which include email addresses) after sending a verification email to that address, and receiving opt-in consent by the user of the email address. This service makes a different tradeoff: it is centralized, and relying on it to correctly perform the verification step requires trust in the operator. The tradeoff allows the service to only list identity information with the consent of the owner of that identity, and to prevent "enumeration" of the certificates and identities it stores (that is: third parties cannot obtain a list of email addresses in the service's database). By design, this service allows easy publication of revocations without requiring publication of any identity components. - *SKS-style keyservers* act as a distributed synchronizing database, which accepts certificate information without verification (TODO: does the network handle third party signatures? If so, how?[^hip1]).