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

Application-specific approaches: Hagrid and GnuPG

Hagrid

Hagrid keyserver software, operating keys.openpgp.org, adopts a privacy-centric model by not automatically publishing identity components of certificates. According to its privacy policy, 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.

GnuPG

GnuPG introduces two explicit commands for certificate minimization, clean and minimize, aimed at optimizing certificate size and content.

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.

The minimize command further reduces the certificate size by retaining only the latest self-signature for each user ID.

Detailed in the GnuPG manual, 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⁴ 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 for authentication.

Minimization for email: Use cases and considerations

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 aims to simplify end-to-end encryption for emails by automatically negotiating encryption capabilities. Autocrypt Level 1 specifies a minimal format for OpenPGP certificates 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⁵.

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 of temporal validity in the case ofrpm-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.

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

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.

## Identifying certificates: Fingerprints and Key IDs

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.

### Version differences in fingerprints

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)

### Practical use of fingerprints and Key IDs in software

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.

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.

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)=
### Certificate lookup by email using fingerprints and Key IDs

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. 

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

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

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

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

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

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

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. ↩︎
This example demonstrates how to minimize a certificate using GnuPG commands, targeting only relevant components: ↩︎

43 KiB Raw Blame History Unescape Escape