book/source/adv/certificates.md

@@ -281,42 +281,80 @@ Once the expiration time is reached, third parties, or ideally their OpenPGP sof
 
 After the update, the updated copy of the certificate will usually have a fresh expiration time. The same procedure will repeat once that new expiration time has been reached.
 
-## Challenges in certificate management
-
-The management of OpenPGP certificates encompasses various challenges, ranging from security vulnerabilities to privacy concerns. This section addresses some of the most significant challenges and the responses developed by the OpenPGP community to mitigate these issues.
-
-(keyserver-flooding)=
-### Third-party certification flooding and responses
-
-Traditionally, OpenPGP keyservers have accepted both components bound to certificates by self-signatures and third party identity certifications. Third-party certifications are essential in the OpenPGP trust model, enabling users to validate the link between a public key and its owner's identity. However, this system has been exploited through certificate flooding attacks, significantly affecting certificate management.
-
-#### Certificate flooding: Risks and impacts
-
-Certificate flooding is a form of digital vandalism. It involves bombarding a certificate with excessive third-party signatures, grossly expanding the certificate's size to make it cumbersome and impractical for users. This can hinder OpenPGP software functionality, opening the door to potential denial-of-service attacks, rendering the certificate non-functional, or significantly impeding its operation. 
-
-The popular SKS keyserver network experienced certificate flooding firsthand. The 2019 incident, [detailed by security researcher Daniel Kahn Gillmor on his blog](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html), highlights the severe operational challenges posed by such attacks within the OpenPGP ecosystem. 
-
-(support-for-1pa3pc)=
-#### Modern responses: 1pa3pc and keyserver design considerations
-
-The OpenPGP community has evolved strategies to counter certificate flooding, notably through the development of First-Party Attested Third-Party Certifications (1pa3pc). This approach enables certificate owners to explicitly approve specific third-party certifications, enhancing control over their certificates and mitigating flooding risks. 
-
-Keyserver designs have adapted to these challenges. For example, the keys.openpgp.org (KOO) service, designed with [GDPR compliance](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation) and flooding resistance in mind, only serves identity components after explicit user consent via email verification. It doesn't distribute third-party certifications by default, avoiding flooding. 
-
-Furthermore, KOO, Hockeypuck keyserver software, and Sequoia's `sq` command-line tool have plans to support or already support 1pa3pc, demonstrating the community's proactive stance on enhancing certificate security. See how [KOO supports 1pa3pc](https://gitlab.com/keys.openpgp.org/hagrid/-/commit/39c0e12ac64588220d36bada6497d8396f5915b3), [Hockeypuck's statement on "HIP 1: Regaining control over public key identity with authenticated key management"](https://github.com/hockeypuck/hockeypuck/wiki/HIP-1:-Regaining-control-over-public-key-identity-with-authenticated-key-management) and [Sequoia's support](https://man.archlinux.org/man/sq-key-attest-certifications.1)).
-
 (social-graph-metadata-leak)=
-### Metadata leak of social graph
+## Metadata leak of Social Graph
 
-The OpenPGP Web of Trust, built on third-party certifications, allows OpenPGP software to analyze trust relationships by inspecting the certification graph. This graph, along with designated trust anchors — usually the certificate holder's own key or other trusted entities' certificates — helps infer the legitimacy of a target certificate. 
+Third-party certifications are signatures over identity components made by other users.
 
-However, this model inadvertently risks exposing users' social graphs, revealing who trusts whom and potentially sensitive interaction patterns based on certification patterns and signature timestamps. Such metadata leaks can have significant privacy implications, allowing for the reconstruction of a network of relationships from publicly available certification data. This information could be exploited for surveillance or other malicious purposes.
+These certifications form the back-bone of the OpenPGP trust-model called the Web of Trust. The name stems from the fact that the collection of certifications forms a unidirectional graph resembling a web. Each edge of the graph connects the signing certificate to the identity component associated with another certificate.
 
-Efforts to mitigate this include selective certification sharing, anonymizing aspects of certifications, and refining certificate distribution mechanisms to offer more control over shared data. These efforts underscore the OpenPGP community's commitment to finding a balance between maintaining a robust, decentralized Web of Trust and safeguarding user privacy. Ongoing discussions and developments aim to enhance privacy-aware practices within the OpenPGP standards, highlighting the importance of addressing social graph metadata leaks proactively.
+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 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.
+
+So, there is some tension between the goals of
+
+- a decentralized system where every participant can access certification information and perform analysis on it locally,
+- privacy related goals (also see {ref}`certificate-lookup-by-email`, for a comparison of certificate distribution mechanisms, which also touches on this theme).
 
 (unbound-user-ids)=
-### Adding unbound, local User IDs to a certificate
+## Adding unbound, local User IDs to a certificate
 
-OpenPGP allows for the addition of unbound, local user IDs to certificates, enhancing personalization and operational flexibility. These IDs, not globally verified, can attach context-specific aliases or metadata. However, this flexibility introduces challenges related to certificate validity, trust, and potential misuse.
+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).
 
-The OpenPGP community, including implementations like [Sequoia PGP](https://sequoia-pgp.org/blog/2023/04/08/sequoia-sq/#an-address-book-style-trust-model), advocates for responsible management of local user IDs and their integration. Sequoia certifies these IDs with local trust anchors and 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 prevent unintended distribution (e.g., to public keyservers), balancing personalization with security and privacy.
+[PET]: https://sequoia-pgp.org/blog/2023/04/08/sequoia-sq/#an-address-book-style-trust-model
+
+Sequoia additionally certifies these "local, third party, User IDs" with a local trust anchor to facilitate local authentication decisions.
+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)=
+
+(keyserver-flooding)=
+## Third-party certification flooding
+
+Traditional OpenPGP keyservers are one mechanism for [collection and distribution](certificate-distribution) of certificate information. Their model revolves around receiving certificate information from sources that don't identify themselves to the keyserver network. Traditionally, these keyservers have accepted both components bound to certificates by self-signatures, and third party identity certifications.
+
+While a convenience for consumers, indiscriminately accepting and integrating third-party identity certifications comes with significant risks.
+
+Without any restrictions in place, malicious entities can flood a certificate with excessive certifications. Called "certificate flooding," this form of digital vandalism grossly expands the certificate size, making the certificate cumbersome and impractical for users.
+
+It also opens the door to potential denial-of-service attacks, rendering the certificate non-functional or significantly impeding its operation.
+
+The popular [SKS keyserver network experienced certificate flooding firsthand](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html) in 2019, causing significant changes to its operation.
+
+```{note}
+The *keys.openpgp.org* (KOO) service performs a similar function as the SKS-style keyservers.
+However, there are major differences in its design and tradeoffs.
+ 
+The KOO keyserver was designed to:
+
+1. conform to [GDPR regulations](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation), and
+2. be resistant to flooding-style vandalism.
+ 
+To achieve these goals, KOO does not serve identity components at all, unless an explicit opt-in has been performed, using a confirmation process vial email. Third-party certifications are also not served by default, but only under very specific circumstances, which preclude flooding.
+```
+
+### Hockeypuck-based keyservers
+
+Currently, third-party certification flooding can be worked around by users or administrators requesting the removal/re-adding of a certificate. [See here](https://github.com/hockeypuck/hockeypuck/wiki/HIP-1:-Regaining-control-over-public-key-identity-with-authenticated-key-management).
+
+Additional mechanisms [are upcoming](support-for-1pa3pc).
+
+## First-Party attested third-party certifications in OpenPGP (1pa3pc)
+
+[First-Party attested third-party certifications in OpenPGP](https://datatracker.ietf.org/doc/draft-dkg-openpgp-1pa3pc/) are a "mechanism to allow the owner of a certificate to explicitly approve of specific third-party certifications". 1pa3pc was designed to enable flooding-proof distribution of third-part certifications.
+
+This mechanism uses the *attested certifications* signature subpacket (type ID `37`), which currently only exists as a proposed feature in [draft-ietf-openpgp-rfc4880bis](https://www.ietf.org/archive/id/draft-ietf-openpgp-rfc4880bis-10.html#table-3)[^ac-draft].
+
+[^ac-draft]: Introducing the *attested certifications* signature subpacket (type ID `37`) was unfortunately not in scope of the chartered topics for the current "crypto-refresh" work of the OpenPGP working group. However, hopefully the working group can handle this feature in future rechartering.
+
+(support-for-1pa3pc)=
+### Support
+
+- The *keys.openpgp.org* (KOO) keyserver [supports *1pa3pc*](https://gitlab.com/keys.openpgp.org/hagrid/-/commit/39c0e12ac64588220d36bada6497d8396f5915b3).
+
+- The Hockeypuck keyserver software [plans to add support for *1pa3pc*](https://github.com/hockeypuck/hockeypuck/issues/136#issuecomment-1812466084) in version 2.2.0.
+
+- The Sequoia `sq` commandline tool [allows adding](https://man.archlinux.org/man/sq-key-attest-certifications.1) attested third-party certifications to a certificate.