ch4: extend "naming"

book/source/04-certificates.md

@@ -507,19 +507,25 @@ Disadvantages/risks of minimizing certificates:
 
 ### Fingerprints and beyond: "Naming" certificates in user-facing contexts 
 
-#### Version 4
+Certificates in OpenPGP have traditionally often been "named" using hexadecimal strings of varying length.
 
-With OpenPGP version 4 certificates, it was customary that user-facing software used 20 byte *fingerprints* as an identifier for the certificate. Or alternatively, shortened *Key ID* variants of the fingerprint. Both were represented in hexadecimal format, sometimes with whitespace to group the identifier into blocks for easier readability.
+For example, a business card might have shown the hexadecimal fingerprint of a person's OpenPGP certificate to facilitate secure communication. Over time, different formats and lengths for these identifiers have been used.
+
+This section outlines the various ways in which certificates can be named, and their properties.
+
+#### Fingerprints and Key IDs in Version 4
+
+With OpenPGP version 4 certificates, it was customary that user-facing software used 20 byte (160 bit) *fingerprints* as an identifier for the certificate. Or alternatively, the 8 byte (64 bit) *Key ID* variant of the fingerprint. Both were represented in hexadecimal format, sometimes with whitespace to group the identifier into blocks for easier readability.
 
 For example, in workflows to accept a certificate for a communication partner, or during third-party certification of an identity, users were shown hexadecimal representations of a fingerprint. Users were asked to manually verify that the fingerprint corresponds to the expected certificate.
 
-#### Version 6
+#### Fingerprints in Version 6
 
-The OpenPGP version 6 standard uses 32 byte fingerprints, but explicitly defines no format for displaying those fingerprints in a human-readable form. The standard [recommends strongly against](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-fingerprint-usability) using version 6 fingerprints as identifiers in user-facing workflows.
+The OpenPGP version 6 standard uses 32 byte (256 bit) fingerprints, but explicitly defines no format for displaying those fingerprints in a human-readable form. The standard [recommends strongly against](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-fingerprint-usability) using version 6 fingerprints as identifiers in user-facing workflows.
 
 Instead, "mechanical fingerprint transfer and comparison" should be preferred, wherever possible. The reasoning is that humans tend to be bad at comparing high-entropy data (in addition, many users are probably put off by being asked to compare long hexadecimal strings).
 
-#### Use in APIs
+#### Use of Fingerprints and Key IDs in APIs
 
 However, both Fingerprints and Key IDs may (and usually *must*) be used, programmatically, by software that handles OpenPGP data, to address specific certificates. This is equally true for OpenPGP version 6.
 
@@ -527,6 +533,24 @@ Note that regardless of the OpenPGP version, software that relies on 8-byte Key
 
 The historical 4-byte "short Key IDs" format should not be used anywhere, anymore (finding collisions in a 32-bit keyspace has been [trivial for a long time](https://evil32.com/)).
 
+#### Looking up certificates by email
+
+Searching OpenPGP certificates by email is a use case that often arises. For example, when composing an email to a new contact, the sender may want to find the OpenPGP certificate for that contact.
+
+Different mechanisms allow certificate lookup by email, for example:
+
+- [Web Key Directory](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/) (WKD)
+- 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)
+- Traditional-style OpenPGP keyservers (today, most of these run the [Hockeypuck](https://github.com/hockeypuck/hockeypuck) software)
+
+Their properties differ:
+
+- 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.
+- The *keys.openpgp.org* service is a "verifying" keyserver: the keyserver software only published 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.
+- *Traditional 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]).
+
+[^hip1]: <https://github.com/hockeypuck/hockeypuck/issues/136>
+
 (cert-freshness)=
 ### Certificate freshness: Triggering updates with expiration
 
@@ -544,7 +568,7 @@ Third-party certifications, which are signatures made by other certificates, ove
 
 OpenPGP software can inspect that graph, and coupled with trust data and a trust anchor (which usually is the certificate holder's own key), can infer whether the target certificate is genuine.
 
-Third-party certifications are published as part of the target certificate to facilitate the process of certificate authentication. Unfortunately, as a side-effect of this approach it's feasible to reconstruct the entire social graph of all people issuing certifications. The certification's signature creation time can be used to deduct whether the ceritifate owner attended a Key Signing Party (and if it was public where was it) and whom they interacted with.
+Third-party certifications are published as part of the target certificate to facilitate the process of certificate authentication. Unfortunately, as a side effect of this approach, it's feasible to reconstruct the entire social graph of all people issuing certifications. The certification's signature creation time can be used to deduct whether the certificate owner attended a Key Signing Party (and if it was public, where it was held) and whom they interacted with.
 
 (unbound_user_ids)=
 ### Adding unbound User IDs to a certificate