OpenPGP certificates are pivotal in establishing and maintaining trust within the realm of secure communications. These certificates encapsulate public key data along with user identities and are instrumental in the encryption, decryption, and signing processes that underpin the OpenPGP standard.
### Overview of OpenPGP certificates
An OpenPGP certificate comprises one or more public keys, a user ID that associates the certificate with a real-world identity, and signatures that validate this association. Certificates are the foundation of the Web of Trust model, allowing users to sign each other's keys to endorse the linkage between a key and its owner's identity. This decentralized trust model enables users to establish chains of trust for verifying identities in the absence of a central authority.
### Importance and use cases
OpenPGP certificates are crucial for a wide range of applications, from secure email communication to software signing and beyond. They provide the mechanisms for users to encrypt messages, ensuring that only the intended recipient can decrypt them, and to sign data, confirming the integrity and origin of the information. In the software development domain, OpenPGP certificates are used to sign code and packages, allowing users to verify the authenticity and integrity of software they download and install.
In this chapter, we aim to delve deeper into the advanced concepts surrounding OpenPGP certificates, focusing on their validity, expiration, and the critical role they play in ensuring the security and reliability of cryptographic communications. By exploring these concepts, we aim to provide readers with a comprehensive understanding of how OpenPGP certificates function within the ecosystem, their practical applications, and best practices for managing certificate validity and expiration to maintain a secure cryptographic environment.
OpenPGP certificates are integral to establishing and maintaining secure communication channels. These certificates, being composites of various components linked by [signatures](../signing_components), embody the trust and authentication mechanisms underpinning the OpenPGP standard. This section explores the dual aspects of certificate validity: expiration and revocation, and how they govern the lifecycle of a certificate and its individual components.
Certificates and their components within the OpenPGP framework are subject to expiration, a mechanism designed to ensure timely review and renewal of cryptographic credentials. Expiration delineates a clear validity period, beyond which a certificate or its specific components, such as subkeys or identities, are considered invalid.
Certificates can "expire," rendering them and their individual components invalid unless renewed. OpenPGP software will refuse to encrypt email using an expired certificate, adhering to the expressed preferences in the certificate's metadata. This refusal acts as a safeguard, prompting certificate owners to update or renew their certificates to maintain operational security.
Expiration dates are set using *Key Expiration Time* subpackets for subkeys, and [*signature expiration time* subpackets](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#signature-expiration-subpacket) for identity components. An expired binding signature invalidates the component it is associated with, emphasizing the critical role of timely updates.
The expiration mechanism serves a crucial function beyond merely invalidating old or compromised certificates. It acts as a proactive catalyst for certificate renewal, ensuring that the OpenPGP ecosystem remains vibrant with up-to-date cryptographic keys and identities.
Utilizing expiration dates fulfills two primary objectives: it compels the polling for certificate updates, such as from a keyserver, and it provides a passive mechanism for certificates to "time out." This is particularly vital if a certificate owner loses control over their certificates or is unable to issue a revocation.
By mandating regular updates through expiration, the OpenPGP standard ensures that certificates reflect the current cryptographic stance of their owners, thereby enhancing the overall security and reliability of the network. This mechanism ensures that certificates maintain their relevance and trustworthiness, fostering a culture of active security management and vigilance among users.
Revocation is a critical security mechanism in the OpenPGP standard, allowing for the invalidation of a certificate or its components. Unlike expiration, which is inherently time-based, revocation is an explicit declaration that a certificate or component should no longer be trusted or used.
OpenPGP certificates are designed as "append only" data structures, meaning that once a component or signature is added, it cannot simply be removed. Instead, to invalidate a certificate or component, revocation signatures are issued and appended to the certificate. This method ensures that the historical record is preserved, maintaining a full audit trail of actions taken over the certificate's lifecycle.
Revocation can apply to individual components of a certificate, such as User IDs and subkeys, allowing specific elements to be marked as invalid without affecting the overall certificate. However, revoking the *primary User ID* or the primary key with a [*Key revocation signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-revocation-signature-ty) (type ID `0x20`) has a more significant effect, marking the entire certificate and all its components as invalid and unusable.
The OpenPGP standard facilitates various [*Reasons for Revocation*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#reason-for-revocation), each denoting the specific rationale behind the revocation. These reasons allow for nuanced distinctions between "soft" and "hard" revocations, impacting how the revocation affects the certificate's use:
- *Soft revocations* (e.g., *Key is superseded*, *Key is retired*, *User ID is no longer valid*) suggest that the revoked component may still have valid uses before the revocation time, allowing for historical verification of signatures.
- *Hard revocations* signal a significant trust breach, such as key compromise, and are treated as valid from the moment of the key's creation, effectively invalidating it for all time.
Revocation semantics play a crucial role in the OpenPGP trust model, particularly in distinguishing between hard and soft revocations. Hard revocations are irreversible and signal that a certificate or component should never be used again, addressing scenarios where a private key is compromised. In contrast, soft revocations allow for the possibility that a component was valid in the past but is no longer appropriate for current use, such as when a subkey is retired in favor of a new one.
This distinction is vital for evaluating the validity of components or signatures at a specified reference time. Hard revocations invalidate a component at all points in time, including before the creation of the revocation signature, to prevent misuse by attackers. Soft revocations, however, leave the door open for the component's use before the revocation, acknowledging its past validity[^undo-revocations].
By understanding the mechanisms and semantics of revocation, OpenPGP users and implementers can more effectively manage and interpret the validity and trustworthiness of certificates within the ecosystem.
[^undo-revocations]: While some revocations can be reverted, undoing revocations is an uncommon workflow. Unlike expirations, which are commonly undone by extending the expiration time.
OpenPGP's design as a decentralized and distributed system poses unique challenges and considerations for certificate management. This section explores strategies for merging certificates, handling unauthenticated information, and the implications of OpenPGP's append-only data structure on certificate validity and trust.
Merging certificates in OpenPGP involves reconciling various pieces of information from different sources to construct a unified and up-to-date view of a certificate. This process is crucial when different copies of a certificate, each potentially containing unique data, need to be consolidated into a single, coherent certificate view.
For example, Bob’s OpenPGP software may have a local copy of Alice’s certificate, and obtain a different version of Alice’s certificate from a keyserver. The goal of the implementation is to add new information about Alice’s certificate, if any, to the local copy. Alice may have added a new identity, replaced a subkey with a new subkey, or revoked some components of her certificate. Or, Alice may have revoked her certificate, signaling that she doesn’t want communication partners to use that certificate anymore. All of these updates could be crucial for Bob to be aware of.
- **Timestamp verification**: Compare the timestamps on certificate components from different sources. Retain the most recent information, such as the latest revocation status or key expiration dates, to ensure the certificate view is current.
- **Signature validation**: Verify the signatures on each component of the certificate. Only incorporate components with valid signatures into the merged view, discarding any data that cannot be authenticated.
- **Conflict resolution**: When conflicting information is present (e.g., differing subkey sets from two sources), prioritize data from more reliable or directly obtained sources, such as WKD or a direct exchange with the certificate owner.
- **Revocation checks**: Pay special attention to revocation signatures. A revocation signature supersedes all other information about the revoked component, marking it as invalid regardless of other data.
Implementing these strategies helps OpenPGP software and users to manage the complexities of certificate information distributed across the decentralized OpenPGP ecosystem, ensuring that the operational view of a certificate is both comprehensive and accurate.
In the OpenPGP ecosystem, certificates often accumulate information that is not directly authenticated by the certificate owner, such as third-party certifications or subkeys. Handling this unauthenticated information requires careful consideration to maintain the trustworthiness of the certificate.
For information that *is* related to the certificate but not bound to it by a self-signature, implementations need to navigate these cases thoughtfully, often in a context-specific manner. Challenges include:
The key is to balance the inclusion of potentially valuable third-party information with the risk of incorporating misleading or harmful data. Strategies may include user-configurable trust settings, software that prioritizes data verified by trusted sources, and mechanisms for users to manually verify or reject unauthenticated information.
OpenPGP certificates act as *append-only data structures*, in practice. Once packets are associated with a certificate and published, they cannot be "recalled." This ensures the integrity and auditability of certificate changes over time. Third parties, including other users and keyservers, may keep and distribute copies of these packets.
Invalidation of components, achieved by adding new metadata such as expiration times or revocation signatures, does not remove packets from the certificate. Instead, it semantically "removes" the component's validity, allowing implementations to omit these invalid elements from their operational view of the certificate.
The decentralized nature of OpenPGP allows users to share and receive certificate information through various mechanisms, including keyservers, manual handling, [Web Key Directory](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/) (WKD), and [Autocrypt](https://en.wikipedia.org/wiki/Autocrypt). This can lead to different users having different views of a certificate at any given time.
These differing views necessitate a process within OpenPGP software to reconcile and store a combined version of the certificate elements obtained from disparate sources. This aspect underlines the importance of assuming a defensive posture when reasoning about the validity and completeness of certificate information in OpenPGP's distributed environment.
- Recipients may not obtain updates to a certificate in a timely manner, for various reasons including, but not limited to, interference by malicious actors. This delay in receiving updates could lead to the use of outdated or compromised keys, undermining the security of communications.
- Data associated with a certificate may compound over time, leading to a certificate that is too large for convenient handling. This situation can arise when a certificate accumulates a significant number of legitimate third-party certifications. In such cases, the certificate holder is limited in their ability to manage the certificate's size, as the OpenPGP standard does not allow for the direct removal of existing packets.
Variability in certificate views among OpenPGP users highlights the system's inherent complexity and the challenges in ensuring all parties have an accurate, up-to-date understanding of a certificate's status. Defensive practices, such as regular certificate updates and careful consideration of certificate expiration and revocation, are vital in navigating these challenges.
Different OpenPGP implementations may handle these challenges in various ways, emphasizing the need for users to understand the potential for discrepancies and adopt practices that ensure the security and reliability of their cryptographic communications.
The diversity of certificate views, influenced by distributed third-party certifications, underscores the complexity of managing privacy and trust within OpenPGP. Users must navigate these challenges with an understanding that not all certificate information may be equally available or desirable to share widely, emphasizing a cautious approach to certificate data management[^tpc-privacy]..
One mechanism that addresses a part of this issue is *expiration*: By setting their certificates to expire after an appropriate interval, certificate holders can force their communication partners to refresh their certificate, e.g., from a keyserver[^mgorny]. This approach not only helps in naturally eliminating unused keys but also enforces periodical checks on the primary key, thereby promoting a consistent and up-to-date view of the certificate across different users.
[^tpc-privacy]: The two parties to a certification (the issuer and the target of the certification) may prefer not to publish their mutual association. Also see {ref}`social-graph-metadata-leak`.
[^mgorny]: See, for example, [here](https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/): "Expiration times really serve two purposes: naturally eliminating unused keys, and enforcing periodical checks on the primary key."
Certificate minimization involves selectively filtering out components of a certificate that are not essential for its intended use-case or to mitigate specific security concerns. This practice aims to enhance performance – particularly for client software – address security vulnerabilities like certificate flooding, and protect user privacy.
The strategy behind certificate minimization focuses on creating a streamlined certificate by removing elements not required for its specific application. This approach not only boosts operational efficiency and client software performance but also safeguards OpenPGP communications against various threats. By filtering which components to retain or omit, the process can serve distinct purposes:
- **Omitting unnecessary components**: In contexts such as email encryption, only the keys necessary for encryption, signing, and certification are retained, excluding those like authentication subkeys that are irrelevant to the primary use-case.
- **Omitting third-party certifications**: Proactively filtering these out upon import can prevent the overload of a certificate with excessive certifications, a common tactic in [certificate flooding](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html) that is designed to render a certificate unusable. This is particularly relevant when certificates grow organically large, to the point that user software [encounters difficulties handling them](https://www.reddit.com/r/GnuPG/comments/bp23p4/my_key_is_too_large/).
Additionally, specific elements of a certificate can be selectively omitted during the minimization process to tailor the certificate to its use-case, improve manageability, and ensure software compatibility:
- **Subkeys and their signatures**: Subkeys not used for the current application, along with their associated signatures, can be omitted.
- **Identity components and outdated signatures**: Both self-signatures that have been superseded by newer versions and third-party signatures on identity components that are not necessary can be excluded. This helps keep the certificate lean and focused on its current application, reducing bloat and enhancing performance.
Through these targeted techniques, certificate minimization serves to enhance the practical usability of certificates in various environments and protect against potential security threats and privacy concerns. It strikes a careful balance, maintaining the OpenPGP trust framework while optimizing certificates for efficiency and specific operational contexts.
[Hagrid keyserver software](https://gitlab.com/keys.openpgp.org/hagrid), operating keys.openpgp.org, adopts a privacy-centric model by not automatically publishing identity components of certificates. According to its [privacy policy](https://keys.openpgp.org/about/privacy), the service allows certificates to be uploaded by anyone, but identifying information is shared only with the certificate owner's explicit opt-in. This measure significantly contributes to user privacy and aids in minimizing certificates by default.
Additionally, to mitigate the risk of certificate flooding, Hagrid currently filters out third-party certifications, further aligning with certificate minimization principles.
The `clean` command streamlines certificates by removing all but the most recent self-signature for user IDs that are no longer usable due to revocation or expiration, and also purges signatures not contributing to trust calculations.
Detailed in the [GnuPG manual](https://www.gnupg.org/documentation/manuals/gnupg-devel/OpenPGP-Key-Management.html), these functionalities allow users to manage their certificates efficiently, directly supporting the goals of minimization.
Moreover, GnuPG's approach to handling incoming certificates includes stripping some signatures by default[^gpg-default-strip] to prevent bloating, although this behavior varies across different Linux distributions. For instance, distributions like Debian and Arch Linux have altered this default setting, affecting how third-party certifications are managed upon import.
This variance underscores the importance of understanding your specific GnuPG configuration and its effects on certificate minimization, especially for users relying on the [Web of Trust mechanism](wot) for authentication.
[^gpg-default-strip]: GnuPG's changes in the default handling of third-party certifications on imports were prompted by the 2019 [keyserver flooding event](https://dev.gnupg.org/T4607#127792).
Certificate minimization plays a critical role in email communications. By reducing certificate size, email clients can improve performance and enhance security. However, certificate minimization strategies may vary, depending on the use case and with consideration given to the balance between usability and security.
The approach adopted by [Autocrypt](https://autocrypt.org/) aims to simplify end-to-end encryption for emails by automatically negotiating encryption capabilities. Autocrypt Level 1 specifies a [minimal format for OpenPGP certificates](https://autocrypt.org/level1.html#openpgp-based-key-data) that are distributed by the autocrypt mechanism in mail headers, emphasizing the importance of keeping certificates small for efficient email communication. An essential practice within the Autocrypt framework is the on-demand generation of minimized certificate views. For instance, when an email is sent or composed, an Autocrypt header is constructed with a freshly minimized version of the sender's certificate. This ensures that the certificate data embedded in the email is both current and optimized for the specific communication context. The receiving end is then expected to merge this data with any locally available information, maintaining a comprehensive and up-to-date view of the certificate.
Proton Mail, a secure email service, exemplifies certificate minimization by selectively fetching only the necessary OpenPGP certificates via Web Key Directory (WKD) when composing a message. This targeted approach ensures that only essential component keys are used, omitting components like invalid subkeys, authentication subkeys not relevant to email encryption, superseded self-signatures, and third-party certifications. With many real-world certificates, the space savings of such a minimization are significant[^space-example].
The examples of Autocrypt and Proton Mail illustrate the advantages of certificate minimization in email communications. However, these examples also highlight several challenges:
- **Balance between security and usability:** Minimizing certificates must carefully balance security concerns with usability. Overly aggressive minimization might omit crucial information necessary for verifying the authenticity of a message.
- **Historical signature verification:** The removal of historical self-signatures can complicate the verification of signatures at different reference times, potentially impacting the trustworthiness of the certificate. For an example, see [this discussion](https://github.com/rpm-software-management/rpm-sequoia/issues/50#issuecomment-1689642607) of [temporal validity](temporal-validity) in the case of`rpm-sequoia`.
- **Dynamic certificate views:** Minimization strategies need to account for the dynamic nature of certificates, where updates and changes are frequent. This requires a thoughtful approach to ensure that minimized certificates remain current and valid.
Moreover, while pursuing certificate minimization for email, it's essential to balance the reduction in size with the preservation of the OpenPGP trust framework. Adequate information must be retained within the certificate to allow users to verify its authenticity and integrity, ensuring that the minimization process does not impede the ability to establish trust through the Web of Trust mechanism.
Overall, certificate minimization for email presents a promising approach to enhancing email security and performance. However, it requires discernment and careful implementation to navigate the inherent trade-offs between minimizing certificate size and maintaining the integrity and trustworthiness of email communications.
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.
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.
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.
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.
- **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.
- **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].
[^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)
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/)).
(certificate-lookup-by-email)=
### 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:
- 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, for more see [](certificate-distribution).
(certificate-freshness)=
## Certificate freshness: Triggering updates with an expiration time
For a certificate holder, one problem is that their communication partners may not regularly poll for updates of their certificate.
A certificate holder usually prefers that everyone else regularly obtains updates for their certificate. This way, a third party will, for example, not mistakenly keep using the certificate indefinitely, after it gets revoked. Setting an expiration time on the certificate, ahead of time, limits the worst case scenario: communication partners will at most use a revoked certificate until its expiration time, even if they never learn of the revocation.
Once the expiration time is reached, third parties, or ideally their OpenPGP software will have to stop using the certificate, and may attempt to obtain an update for it. For example, from a keyserver, or via WKD. Ideally, certificate updates are obtained automatically, by the user's OpenPGP software, without any need for human intervention.
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.
(social-graph-metadata-leak)=
## Metadata leak of Social Graph
Third-party certifications are signatures over identity components made by other users.
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.
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
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).
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)=
## 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].
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
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).
## 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.
