40 KiB

Raw Blame History

Advanced material: Certificates

Introduction to OpenPGP certificates

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.

Certificate validity, expiration, and revocation

OpenPGP certificates are integral to establishing and maintaining secure communication channels. These certificates, being composites of various components linked by signatures, 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.

Understanding certificate expiration

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 for identity components. An expired binding signature invalidates the component it is associated with, emphasizing the critical role of timely updates.

The role of expiration in certificate freshness

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.

Introduction to certificate revocation

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 mechanisms and types

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 (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, 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.

Semantics of revocations

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¹.

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.

(certificate-merging)=

18.3 Merging and updating certificates

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.

Strategies for merging certificates

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.

Key strategies for effective certificate merging include:

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.

Handling unauthenticated information

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:

Third-party certifications, which may either be valuable endorsements of an identity’s association with a certificate or could serve as spam.
Subpackets in the unhashed area of a signature packet, which could contain either useful or potentially misleading information.

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.

(append-only)=

OpenPGP certificates as append-only data structures

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.

Reasoning about append-only properties in a distributed system

The decentralized nature of OpenPGP allows users to share and receive certificate information through various mechanisms, including keyservers, manual handling, Web Key Directory (WKD), and 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.

When considering edge cases within this distributed system, it's prudent to "assume the worst." For instance:

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.

Differing views of a certificate

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²..

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³. 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.

(minimization)=

Certificate minimization

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.

Rationale and techniques for minimization

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 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.

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.

Minimization in applications

Hagrid, which runs keys.openpgp.org

The hagrid keyserver software doesn't publish the identity components in certificates by default. This is a central aspect of the privacy policy of the service. Certificates can be uploaded to the service by third parties, which is useful. However, identifying information is only distributed by the service on an explicit opt-in basis.

Separately, third-party certifications are currently filtered out by the service, to avoid flooding attacks.

GnuPG

GnuPG offers two explicit methods for certificate minimization, described in the GnuPG manual as:

clean: Compact (by removing all signatures except the selfsig) any user ID that is no longer usable (e.g. revoked, or expired). Then, remove any signatures that are not usable by the trust calculations. Specifically, this removes any signature that does not validate, any signature that is superseded by a later signature, revoked signatures, and signatures issued by keys that are not present on the keyring.
minimize: Make the key as small as possible. This removes all signatures from each user ID except for the most recent self-signature.

clean removes third-party signatures by certificates that are not present in current keyring, as well as other stale data. minimize removes superseded signatures that are not needed at the point when the command is executed.

Independently, GnuPG by default strips some signatures on key import⁴. However, a number of Linux distributions change this default behavior, and continue to import signatures without minimization by default. e.g. Debian and Arch Linux: stripping third-party certifications on import, by default, is problematic for users who want to leverage authentication based on the Web of Trust mechanism.

Limitations that can result from stripping historical self-signatures

Some implementations, such as Sequoia, prefer to rely on the full historical set of self-signatures to construct a view of the certificate over time. This way, signatures can be verified at different reference times. In this model, removing superseded self-signatures can cause problems with the validation of historical signature.

An example for the tension between minimization and nuanced verification of the temporal validity of signatures can be seen in the case of rpm-sequoia. See this discussion for details:

Initially, when checking the validity of a data signature for a software package, rpm-sequoia used the signature's creation time as the reference time. However, the availability of historical self-signatures in certificates is limited. So sometimes only a more recent self-signature for the primary key is available, and there is no evidence that the primary key was valid at the reference time.

To deal with this reality, the rpm-sequoia implementation was adjusted to accept data signatures that predate the validity of the current primary key self-signature⁵.

Autocrypt

The Autocrypt project describes itself as:

[..] a set of guidelines for developers to achieve convenient end-to-end-encryption of e-mails. It specifies how e-mail programs negotiate encryption capabilities using regular e-mails.

The Autocrypt Level 1 specification defines a specific minimal format for OpenPGP certificates that are distributed by the autocrypt mechanism.

One goal of the Autocrypt mechanism is to distribute certificates widely. To this end, Autocrypt sends certificates in mail headers, where smaller size is greatly preferable.

Basic encrypted email functionality requires only a small subset of the recipient's certificate, so small certificate size is feasible.

Minimization for email

Note that minimization of certificates isn't generally "right" or "wrong." The benefit or harm depends on the context.

For example, we might consider minimizing a certificate for distribution via WKD, with the use-case of email in mind.

Many certificates can be significantly pruned if the only goal of distributing them is to enable encryption and signature verification. For such cases, many components can be dropped, including invalid subkeys and their binding signatures, authentication subkeys (which are irrelevant to email), shadowed self-signatures, and third-party certifications. With many real-world certificates, the space savings of such a minimization are significant⁶.

Such minimization might be appropriate and convenient to enable encrypted communication with a Proton Mail client, which automatically fetches OpenPGP certificates via WKD while composing a message. The Proton Mail use case requires only component keys, not third-party certifications, and it doesn't require historical component keys or self-signatures.

However, in a different context, the same certificate might be fetched to verify the authenticity of a signature. In that case, third-party certifications may be crucial for the client. Stripping them could prevent the client from performing Web of Trust calculations and validating the authenticity of the certificate.

Pitfalls of minimization

Disadvantages/risks of minimizing certificates:

A minimized certificate does not present a full view of how it (and the validity of its components) evolved over time.
As the OpenPGP subsystem on a user's computer learns about more certificates, third-party certifications that were previously unusable may become usable. Dropping third-party certifications by unknown issuers as a part of minimization prevents this mechanism.
An OpenPGP implementation that minimizes a certificate might remove component keys that it cannot use itself (e.g. because it doesn't support the algorithm of that key), even if the receiving implementation supports them.
Refreshing certificates from key servers may inflate the certificate again, since OpenPGP certificates tend to act as append-only structures.
Some libraries, such as anonaddy-sequoia strip unusable encryption subkeys, but retain at least one subkey, even if all subkeys are expired. Although this may leave only an expired encryption subkey in the certificate, this presents a better UX for the end user who potentially is still in possession of the private key for decryption.

Guidelines

Don't minimize certificates unless you have a good reason to.
When minimizing a certificate, minimize it in a way that suites your use-case. E.g., when minimizing a certificate for distribution alongside a signed software packet, make sure to include enough historical self-signatures as to not break the verification of the signed packet.
When presenting a minimized view of a certificate to a consumer, consider when that a new version of that view needs to be generated. Ideally, minimized certificates are freshly generated on demand (e.g., an Autocrypt header is constructed while an email is sent or composed). The receiver is expected to typically merge all data it sees locally.

Fingerprints and beyond: "Naming" certificates in user-facing contexts

Certificates in OpenPGP have traditionally often been "named" using hexadecimal strings of varying length.

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.

Workflows such as

accepting a certificate for a communication partner, or
issuing a third-party certification for an identity,

required users to manually compare the 40 character long hexadecimal representation of a fingerprint against a reference source for that fingerprint.

Fingerprints in Version 6

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 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 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).

(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:

Web Key Directory (WKD)
The keys.openpgp.org "verifying keyserver" (also known as "hagrid", the name of the server software it runs)
SKS-style OpenPGP keyservers (today, most of these run the Hockeypuck software)

Their properties differ, for more see .

(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)=

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" 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 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⁸.

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 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 in 2019, causing significant changes to its operation.

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.

Additional mechanisms are upcoming.

First-Party attested third-party certifications in OpenPGP (1pa3pc)

First-Party attested third-party certifications in OpenPGP 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⁹.

(support-for-1pa3pc)=

Support

The keys.openpgp.org (KOO) keyserver supports 1pa3pc.
The Hockeypuck keyserver software plans to add support for 1pa3pc in version 2.2.0.
The Sequoia sq commandline tool allows adding attested third-party certifications to a certificate.

While some revocations can be reverted, undoing revocations is an uncommon workflow. Unlike expirations, which are commonly undone by extending the expiration time. ↩︎
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. ↩︎
See, for example, here: "Expiration times really serve two purposes: naturally eliminating unused keys, and enforcing periodical checks on the primary key." ↩︎
GnuPG's changes in the default handling of third-party certifications on imports were prompted by the 2019 keyserver flooding event. ↩︎
Which in OpenPGP version 4 is often a primary User ID binding signature. ↩︎
The following fragment processes an example certificate. It drops any subkey that is not valid at the time of export (because of revocation or expiration), authentication subkeys, and any third-party certifications:
```
gpg --export-options export-minimal,export-clean,no-export-attributes \
    --export-filter keep-uid=mbox=wiktor@metacode.biz \
    --export-filter 'drop-subkey=expired -t || revoked -t || usage =~ a' \
    --export wiktor@metacode.biz
```
At the time of writing, the original certificate consists of 152322 bytes of data. The filtered variant consists of only 3771 bytes, which is 40x smaller. In some contexts, there are hard constraints on size, and minimization is unavoidable, e.g., when embedding certificate data in email headers. ↩︎
See "An Empirical Study of Textual Key-Fingerprint Representations" https://www.ibr.cs.tu-bs.de/papers/schuermann-usenix2016.pdf ↩︎
https://github.com/hockeypuck/hockeypuck/issues/136 ↩︎
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. ↩︎

40 KiB Raw Blame History Unescape Escape