move up and improve section on distribution mechanisms for certificates

book/source/adv/certificates.md

@@ -198,53 +198,77 @@ gpg --export-options export-minimal,export-clean,no-export-attributes \
 
 The process significantly reduces the certificate size from 152,322 bytes to just 3,771 bytes, demonstrating a substantial decrease in size by over 40 times. Such minimization is particularly crucial in contexts with strict size limitations, like embedding certificate data in email headers.
 
-## Fingerprints and beyond: "Naming" certificates in user-facing contexts
+## Identifying certificates: Fingerprints and Key IDs
 
-Certificates in OpenPGP have traditionally often been "named" using hexadecimal strings of varying length.
+OpenPGP certificates are uniquely identified through fingerprints and Key IDs, derived from the public key material. Over time, OpenPGP's approach to identifying certificates through fingerprints and key IDs has adapted to meet increasing demands for more secure and efficient certificate management.
 
-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 delves into the evolution of these identifiers, their practical application across various platforms, and their critical role in facilitating the lookup of OpenPGP certificates by email. By serving as reliable methods for distinguishing and referencing certificates, fingerprints and Key IDs are instrumental in the verification, distribution, and management of OpenPGP certificates within the cryptographic community.
 
-This section outlines the various ways in which certificates can be named, and their properties.
+### Version differences in fingerprints
 
-### Fingerprints and Key IDs in Version 4
+The development of fingerprints within the OpenPGP framework reflects ongoing efforts to bolster security measures and align with current cryptographic standards. Initially, fingerprints were shorter and derived using less secure hashing algorithms. As cryptographic standards advanced, the need for longer, more secure fingerprints became apparent, leading to the adoption of longer hash functions to generate these identifiers.
 
-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.
+- **Version 4 fingerprints**: OpenPGP version 4 introduced 20-byte (160-bit) fingerprints, generated using the SHA-1 hashing algorithm. These fingerprints became the standard for identifying certificates, with their hexadecimal representation commonly used in various user workflows. Activities such as verifying a new contact's certificate or issuing third-party certifications often required manual comparison of these fingerprints, highlighting their centrality to OpenPGP's trust-building processes.
 
-Workflows such as
+- **Version 6 fingerprints**: The OpenPGP version 6 standards transition to 32-byte (256-bit) fingerprints, enhancing security through the use of stronger hash functions. However, due to the challenges humans face in comparing high-entropy data, [version 6 explicitly recommends against using these longer fingerprints](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-fingerprint-usability) in user-facing contexts, advocating instead for "mechanical fingerprint transfer and comparison" whenever possible. This shift underscores the evolving considerations around the usability and security of certificate identifiers[^schuermann].
 
-- accepting a certificate for a communication partner, or
-- issuing a third-party certification for an identity,
+[^schuermann]: See "An Empirical Study of Textual Key-Fingerprint Representations" [<https://www.ibr.cs.tu-bs.de/papers/schuermann-usenix2016.pdf>](https://www.ibr.cs.tu-bs.de/papers/schuermann-usenix2016.pdf)
 
-required users to manually compare the 40 character long hexadecimal representation of a fingerprint against a reference source for that fingerprint.
+### Practical use of fingerprints and Key IDs in software
 
-### Fingerprints in Version 6
+Fingerprints and Key IDs play a pivotal role in the programmatic interaction with OpenPGP certificates. Software that handles OpenPGP data relies on these identifiers to precisely address and manage specific certificates. This utility extends across all versions of OpenPGP, including version 6, underscoring the indispensable nature of these identifiers in both user-facing contexts and behind-the-scenes operations.
 
-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.
+While Key IDs offer a shorthand method for identifying certificates, they come with security caveats. The 8-byte Key IDs are susceptible to collisions, and applications must be prepared to handle such scenarios gracefully. The use of 4-byte "short Key IDs" is strongly discouraged due to [the triviality of generating collisions within a 32-bit keyspace](https://evil32.com/), posing significant security risks.
 
-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[^schuermann] (in addition, many users are probably put off by being asked to compare long hexadecimal strings).
-
-[^schuermann]: See "An Empirical Study of Textual Key-Fingerprint Representations" <https://www.ibr.cs.tu-bs.de/papers/schuermann-usenix2016.pdf>
-
-### 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.
-
-Note that regardless of the OpenPGP version, software that relies on 8-byte Key IDs should not assume that Key IDs are unique. It is trivial to generate collisions for 8-byte Key IDs, so applications must be able to handle Key ID collisions gracefully.
-
-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/)).
+In essence, fingerprints and Key IDs are crucial for software to programmatically address specific OpenPGP certificates, balancing between the need for precise identification and the challenges posed by potential security vulnerabilities associated with Key IDs.
 
 (certificate-lookup-by-email)=
-### Looking up certificates by email
+### Certificate lookup by email using fingerprints and Key IDs
 
-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.
+A common use case of fingerprints and Key IDs, crucial for day-to-day secure communications, is locating an OpenPGP certificate associated with an email address. 
 
-Different mechanisms allow certificate lookup by email, for example:
+- **[Web Key Directory (WKD)](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/)** and **[Hagrid](https://keys.openpgp.org/)** exemplify systems that leverage these identifiers for secure and privacy-respecting certificate lookup by email, enhancing the reliability of encrypted email communications.
 
-- [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)
-- SKS-style OpenPGP keyservers (today, most of these run the [Hockeypuck](https://github.com/hockeypuck/hockeypuck) software)
+- **SKS-style keyservers** represent a more traditional approach to certificate distribution. Despite their age, these keyservers continue to play a role in the OpenPGP ecosystem. Today, most of these run the [Hockeypuck](https://github.com/hockeypuck/hockeypuck) software, which helps secure the keyserver infrastructure. SKS-style keyservers use fingerprints and Key IDs for certificate indexing and retrieval, underscoring the universal applicability of these identifiers in enhancing email security across various platforms.
 
-Their properties differ, for more see [](certificate-distribution).
+While their properties differ, these mechanisms showcase the indispensable role of fingerprints and Key IDs in facilitating secure email exchanges within the OpenPGP ecosystem.
+
+(certificate-distribution)=
+## Distribution mechanisms for certificates
+
+The OpenPGP ecosystem employs various mechanisms for the distribution and retrieval of certificates, each with its unique infrastructure, operational model, and set of advantages and challenges. This section explores these mechanisms, providing insights into how they support the broader objectives of certificate management, including security, privacy, and usability.
+
+### Web Key Directory (WKD)
+
+The Web Key Directory (WKD) offers a decentralized solution for the distribution of OpenPGP certificates, enabling domain owners to host OpenPGP keys on their own web servers. This approach provides a direct, user-friendly method for retrieving certificates based on email addresses, aligning with OpenPGP's trust and privacy principles.
+
+- **Decentralization and domain control**: WKD's decentralized framework allows for the hosting of certificates in a well-known location on a webserver, managed by the entity controlling the DNS domain of an email-based identity. This model empowers domain owners with direct control over the certificates associated with their domain, enhancing security and trustworthiness. The decentralization aspect ensures that the reliability and availability of OpenPGP certificates can vary depending on the organization operating each WKD instance, allowing for tailored security practices and policies.
+
+- **Privacy and autonomy**: By facilitating a method of certificate distribution that does not rely on centralized keyserver networks, WKD inherently supports privacy by minimizing exposure to third-party tracking or control. Users and domain owners can manage certificate distribution autonomously, providing a privacy-centric alternative to traditional keyservers.
+
+- **Seamless integration with email systems**: WKD leverages the existing infrastructure of email addresses and domain names for smooth integration with email clients. This supports the automatic discovery and retrieval of certificates, streamlining the process for end-users. Such seamless integration ensures that certificates are always current, making secure communication more accessible and manageable.
+
+### keys.openpgp.org (Hagrid)
+
+Hagrid, the software powering the keys.openpgp.org service, represents a paradigm shift in keyserver design, focusing on verifying user identities and safeguarding privacy. This "verifying" keyserver model is distinctive for its approach to managing identity components associated with OpenPGP certificates.
+
+- **Trust and verification**: Hagrid introduces a rigorous verification process, wherein identity components (including email addresses) are only published after the keyserver has sent a verification email to the address in question and received explicit opt-in consent from the user. This verification mechanism ensures that all published certificates are authentically linked to their claimed identities, significantly mitigating risks of impersonation and unauthorized certificate publication.
+
+- **Centralization and privacy considerations**: Unlike traditional, decentralized keyservers, Hagrid operates on a centralized model, which necessitates trust in the operator to accurately perform verification steps. However, this centralization facilitates a trade-off that enhances privacy: Hagrid prevents the "enumeration" of certificates and identities, meaning third parties cannot simply list or query all email addresses stored in the service's database. This feature is critical for user privacy and control over personal information in the digital space.
+
+- **User control and anti-spam measures**: By implementing a model that publishes identity information solely with user consent, Hagrid empowers users with unparalleled control over their digital identities. This approach not only protects users' privacy but also contributes to a cleaner, more reliable directory of certificates, devoid of spam and irrelevant data. Furthermore, Hagrid's design simplifies the publication of revocations, enabling users to easily update or invalidate their certificates without necessitating the publication of additional identity components.
+
+### SKS-style keyservers: Challenges and solutions
+
+SKS-style keyservers have historically facilitated the exchange of OpenPGP certificates within a distributed, unverified database framework. While instrumental in the OpenPGP ecosystem, this model has encountered significant challenges, particularly related to security and privacy.
+
+- **Security and privacy concerns**: The openness of SKS-style keyservers has exposed them to certificate flooding attacks, where attackers inundate a key with excessive, often malicious, signatures. This not only disrupts operational efficiency but also raises privacy concerns, as these servers indiscriminately distribute third-party certifications and identity packets, potentially without the certificate owner's consent.
+
+- **Adaptive responses and Hockeypuck's role**: In response, the OpenPGP community has sought solutions to these vulnerabilities. Hockeypuck, an advanced keyserver software, exemplifies these efforts by aiming to enhance security and data integrity, directly addressing the limitations of the traditional SKS architecture. One notable discussion within the community ([GitHub issue #136](https://github.com/hockeypuck/hockeypuck/issues/136)) focuses on proposals like HIP-1, aiming to provide key owners with more control over their certificates on keyservers, thus mitigating risks such as certificate flooding.
+
+- **Evolving towards more secure models**: This transition from SKS-style servers to more controlled, secure models signifies a broader shift within the OpenPGP community. Newer mechanisms like WKD and Hagrid illustrate this evolution, offering more privacy-respecting and user-centric approaches to certificate distribution. Hagrid, in particular, introduces a verifying keyserver model that only distributes verified identity information, a stark contrast to the traditional SKS system's approach.
+
+The progression from SKS-style keyservers to innovative solutions like Hockeypuck and Hagrid demonstrates the OpenPGP community's commitment to safeguarding the OpenPGP ecosystem against evolving threats, ensuring a more secure and reliable infrastructure for certificate distribution.
 
 (certificate-freshness)=
 ## Certificate freshness: Triggering updates with an expiration time
@@ -286,17 +310,6 @@ Sequoia additionally certifies these "local, third party, User IDs" with a local
 To prevent accidental publication of these local User IDs (e.g. to public keyservers), Sequoia marks these binding signatures as "local" artifacts using [Exportable Certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-exportable-certification) subpackets to mark them as non-exportable.
 
 (certificate-distribution)=
-## Certificate distribution mechanisms
-
-Different mechanisms for discovering certificates, and updating certificate data exist in the OpenPGP space:
-
-- 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. The SKS network handles third-party signatures, additional changes to their handling are pending[^hip1].
-
-[^hip1]: <https://github.com/hockeypuck/hockeypuck/issues/136>
-
-One central difference between hockeypuck and hagrid (the software that runs the *keys.openpgp.org* service) is that hockeypuck distributes identity packets and third-party certifications that have indeterminate validity, while hagrid does not.
 
 (keyserver-flooding)=
 ## Third-party certification flooding