From b71b19c62a62d0851b2315007d864099faa1f8fe Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 3 Dec 2023 20:21:23 +0100 Subject: [PATCH] normalize keyserver style naming --- book/source/04-certificates.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index ac5c396..475c0a4 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -542,7 +542,7 @@ 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) +- SKS-style OpenPGP keyservers (today, most of these run the [Hockeypuck](https://github.com/hockeypuck/hockeypuck) software) Their properties differ, also see {ref}`distribution`. @@ -593,7 +593,7 @@ Different mechanisms for discovering certificates, and updating certificate data - 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]). +- *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]). (cert-flooding)= ### Third-party certification flooding