49 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 component keys, as well as identity components that may associate the certificate with a real-world identity, and signatures that validate this association. Certificates are the foundation of the Web of Trust model, in which users mutually endorse the linkage between a certificate 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 to an expired certificate, adhering to the expressed preferences in the certificate's metadata. This refusal acts as a safeguard, prompting certificate holders to either extend the validity of their certificate, or replace it with a new one, 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 otherwise unable to issue a revocation.

By facilitating regular updates triggered by 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 distinguishes 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, including retroactively.

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

Merging and updating certificates

OpenPGP's design as a decentralized and distributed system poses unique challenges and considerations for certificate management. Among these challenges is the need to "merge versions of a certificate": a user may have obtained one version of a certificate in the past, and later receives a different copy of the same certificate. Merging the two versions of the certificate is the process of consolidating the information from both copies into a single certificate that incorporates all information from both copies.

This section explores strategies for merging certificates, handling unauthenticated information, and the implications of OpenPGP's append-only certificate 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 another, potentially different, version of Alice’s certificate from a keyserver. Bob's software will then incorporate new information about Alice’s certificate, if any, into 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 into the merged view when they are bound to the certificate with a valid self-signature, discarding any unbound components.
Conflict resolution: When conflicting information is present, 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 comprehensive, accurate and up-to-date.

Handling unauthenticated information

In the OpenPGP ecosystem, certificates often accumulate information that is not directly authenticated by the certificate owner, in particular third-party certifications and information in the unhashed area of signatures. Handling this unauthenticated information requires careful consideration.

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 (common OpenPGP tools don't offer convenient methods for e.g. granular management of stored third-party certifications).

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 for updates to a certificate, thereby promoting a consistent and up-to-date view of the certificate across different users.

(minimization)=

Certificate minimization

Certificate minimization involves selectively filtering out elements 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 denial-of-service attempts 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 elements to retain or omit, the process can serve distinct purposes:

Omitting unnecessary elements: In contexts such as email encryption, it is possible to only retain the component keys necessary for encryption, signing, and certification, while excluding authentication subkeys that are irrelevant to this use-case.
Omitting (some) third-party certifications: Proactively filtering these out upon import can prevent the overload of a certificate with excessive certifications, a tactic that has been seen in certificate flooding which is designed to render a certificate unusable. This is also relevant when certificates grow organically large, potentially even 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 their signatures: Identity components not relevant to the current application, along with their associated signatures, can be omitted.
Historical signatures and third-party certification 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 privacy concerns. It strikes a careful balance, maintaining the OpenPGP trust framework while optimizing certificates for efficiency and specific operational contexts.

Also see {ref}minimization-guidelines.

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 in the local certificate store.

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 third-party 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⁴, 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 {term}Web of Trust mechanism for authentication.

Minimization for email: Use cases and considerations

Certificate minimization plays a critical role in schemes that opportunistically distribute certificates for email communication. By heavily restricting size, certificates can be distributed in email headers without causing undue overhead. However, certificate minimization strategies may vary, depending on the use case and with consideration given to the balance between usability and overhead.

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, provides minimal certificates via Web Key Directory (WKD), which are automatically obtained by the Proton Mail client software 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, or important information about revocation of components.
Historical signature verification: The removal of historical self-signatures can impact the evaluation of past signature validity. For an example, see this discussion of 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.

Identifying certificates: By Fingerprints, Key IDs on email address

OpenPGP certificates are often identified through fingerprints and Key IDs, both of which are derived from the public key material. Over time, OpenPGP's approach to identifying certificates through fingerprints and key IDs has adapted to changing demands.

There is a tension between the length of identifiers and guarantees of unique identification: shorter certificate identifiers will more often collide organically with unrelated certificates. Malicious actors can more easily generate malicious certificates that share a short identifier with a target certificate. On the other hand, long identifiers are inconvenient to handle for human users.

This section delves into the evolution of these identifiers, their practical application across various platforms, and the 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 format reflects ongoing efforts to bolster security measures and align with current cryptographic standards. Initially, fingerprints were shorter and derived using now obsolete hashing algorithms. As cryptographic standards advanced, the need for longer, more secure fingerprints became apparent, leading to the adoption of stronger hash functions to generate these identifiers.

Version 6 fingerprints: The OpenPGP version 6 standard transitions to 32-byte (256-bit) fingerprints, and enhances security through the use of the stronger SHA-2 hash function. However, due to the challenges humans face in comparing high-entropy data, version 6 explicitly recommends against using fingerprints 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⁶.

Version 4 fingerprints: OpenPGP version 4 uses 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.

Key IDs

Key IDs are shorter versions of Fingerprints, and act as a shorthand method for identifying certificates. Due to their shorter size, they come with security caveats. The now common 8-byte Key IDs are susceptible to collisions, and applications that use Key IDs must be prepared to handle duplicate Key IDs gracefully.

Note that historically, even shorter 4-byte "short Key IDs" were used. Use of 4-byte sized identifiers is strongly discouraged for any purpose due to the triviality of generating collisions within a 32-bit keyspace, making such identifiers unsuitable for identification of certificates.

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 address and manage specific certificates. This utility extends across all versions of OpenPGP, including version 6, underscoring the indispensable nature of these identifiers in behind-the-scenes operations, even as there are plans to retire their use in user-facing contexts.

(certificate-lookup-by-email)=

Certificate lookup by email

A common use case in day-to-day secure communications is locating an OpenPGP certificate that is associated with an email address.

Lookup by email is in some ways similar to lookup by fingerprint, but with some important differences: While a fingerprint is cryptographically linked to a particular certificate and effectively serves as a unique identifier for a particular certificate, lookup by email may produce multiple certificates, some or all of them potentially fraudulent. However, an email address is more convenient for humans to handle and remember. This makes lookup by email attractive for user workflows, but even so, such lookups can't by themselves reliably lead to the correct certificate for the communication partner in question.

That said, there are multiple mechanisms that facilitate lookup of OpenPGP certificates by email. They strike different trade-offs in their design and operation (for more details see {ref}certificate-distribution):

Web Key Directory (WKD) and Hagrid exemplify systems that enable certificate lookup by email, and are more likely to provide trustworthy information for lookups by email. The advent of both of these services has greatly enhanced the ease of use of encrypted email communications with modest security requirements.

SKS-style keyservers represent a more traditional approach to certificate distribution. Despite their age, these keyservers continue to play an important role in the OpenPGP ecosystem. Today, most of them run the Hockeypuck software. SKS-style keyservers allow lookup of certificates by email. However, by design, they offer no assurances at all about the correctness of email identities that are associated with certificates. Additional vetting may thus be particularly necessary when looking up certificates by email from these keyservers.

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

(wkd)=

Web Key Directory (WKD)

The Web Key Directory (WKD) offers a decentralized solution for the distribution of OpenPGP certificates, enabling domain owners to publish OpenPGP certificates 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.

(hagrid)=

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 only email-centric identity components are published, and only 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 availability 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 signatures, disrupting practical use of these certificates. This openness doesn't only cause risks for operational efficiency but in addition raises privacy concerns, as these servers indiscriminately distribute third-party certifications and identity components, 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 in the SKS lineage, 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) focuses on proposals like HIP-1, aiming to provide certificate holders with more control over their certificates on keyservers, thus mitigating risks such as certificate flooding.

Evolving towards more defensive 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 the original SKS 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.

Challenges in certificate management

The management of OpenPGP certificates encompasses various challenges, ranging from security-critical ones 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, 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 holders 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 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 management and distribution mechanisms. See how KOO supports 1pa3pc, Hockeypuck's statement on "HIP 1: Regaining control over public key identity with authenticated key management" and support in the sq tool.

It's also noteworthy that the mechanism of 1pa3pc relies on the attested certifications signature subpacket (type ID 37), a feature presently proposed in the draft-ietf-openpgp-rfc4880bis. Although the inclusion of this specific subpacket was not within the scope of the current "crypto-refresh" work by the OpenPGP working group, there is optimism that future revisions of the standard will formally integrate this capability, further solidifying the framework for secure and controlled certificate management.

(social-graph-metadata-leak)=

The OpenPGP Web of Trust, built on third-party certifications, allows OpenPGP software to analyze trust relationships by inspecting the certification graph. This graph, along with designated trust anchors — usually the certificate holder's own key or other trusted entities' certificates — helps infer the legitimacy of a target certificate.

However, this model inadvertently risks exposing users' social graphs, revealing who trusts whom and potentially sensitive interaction patterns based on certification patterns and signature timestamps. Such metadata leaks can have significant privacy implications, allowing for the reconstruction of a network of relationships from publicly available certification data. This information could be exploited for surveillance or other malicious purposes.

Efforts to mitigate this include selective certification sharing, anonymizing aspects of certifications, and refining certificate distribution mechanisms to offer more control over shared data. These efforts underscore the OpenPGP community's commitment to finding a balance between maintaining a robust, decentralized Web of Trust and safeguarding user privacy. Ongoing discussions and developments aim to enhance privacy-aware practices within the OpenPGP standards, highlighting the importance of addressing social graph metadata leaks proactively.

Enumerability of certificates on distribution mechanisms

One aspect of the trade-off is the question of "enumerability". We say that a repository of certificates can be "enumerated" when a third party can obtain a full set of all OpenPGP certificates that were published on that service.

Some services attempt to limit or completely hinder enumeration: This is a design objective of the Hagrid keyserver, as well as of WKD in which certificate distribution is managed by the domain operator for an email address. WKD only facilitates lookup by specific email localpart. Wildcard-searches are not part of the WKD specification. Some WKD service providers implement additional mitigations against enumeration⁸.

(unbound-user-ids)=

Adding unbound, local User IDs to a certificate

The OpenPGP format allows for the addition of unbound, local user IDs to certificates, enhancing personalization and operational flexibility. These IDs, not globally verified, can attach context-specific local aliases or metadata. However, this flexibility introduces challenges related to certificate validity, trust, and potential misuse.

The OpenPGP community, including implementations like Sequoia PGP, advocates for responsible management of local User IDs and their integration. Sequoia certifies local User IDs in its certificate store with local trust anchors and marks these binding signatures as "local" artifacts using Exportable Certification subpackets to prevent unintended distribution (e.g., to public keyservers), balancing personalization and privacy.

Best practices and recommendations

(minimization-guidelines)=

Guidelines for certificate minimization

Minimization involves presenting a partial view of a certificate by filtering out some components for specific use cases, such as email encryption where only necessary keys are retained. It serves to enhance performance, address security vulnerabilities like certificate flooding, and protect user privacy. Best practices include:

keeping a complete view of certificates available locally is appropriate in many cases
producing minimized views on demand, geared towards a specific use-case (e.g. a certificate may be minimized on demand to send as part of an email header)
omitting unnecessary elements with a specific and clearly understood purpose, aimed at a particular use case
considering the use case and context when minimizing, which elements must be retained or can be discarded must suit the needs of the context the minimization is applied in

There is no one-size-fits-all approach to minimization! Certificate minimization involves trade-offs that must be weighed and considered in each application's context.

(certificate-freshness)=

Handling certificate freshness and expiration

Freshness concerns ensuring certificates are up-to-date, compelling users or their software to poll for updates, such as from a keyserver. Expiration acts as a passive mechanism for certificates to time out, promoting regular updates by peers, making them aware of the current cryptographic stance of the certificate holder. Best practices include:

certificate holders should set appropriate expiration times to force regular updates of their certificate (which also acts as a limiter on the use of the certificate in case it gets revoked and peers fail to become aware of the revocation)
OpenPGP software should poll for updates on certificates, ideally without human intervention, to maintain certificate relevance and trustworthiness (applications should strongly consider employing mitigation techniques against metadata leakage of such polling)

Securely distributing and verifying certificates

Distribution mechanisms like WKD, Hagrid, and SKS-style keyservers facilitate the exchange of OpenPGP certificates, each with unique properties affecting security, privacy, and usability. Recommendations for secure distribution and verification include:

leveraging verifying keyservers like Hagrid for controlled, privacy-aware distribution
utilizing WKD for decentralized, domain-controlled certificate hosting
adapting to evolving keyserver designs that further mitigate problems such as certificate flooding

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, retaining only components relevant in an email context:
```
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. ↩︎
See "An Empirical Study of Textual Key-Fingerprint Representations" https://www.ibr.cs.tu-bs.de/papers/schuermann-usenix2016.pdf ↩︎
Note that publication of revocations doesn't require opt-in by the certificate holder, in the Hagrid model. The cryptographic signature on a revocation statement enables easy verification that a revocation was issued by the certificate holder, so the existence of a revocation signature is considered as a statement of intent by the certificate holder, signaling that they want the revocation to be distributed widely. ↩︎
The Proton Mail WKD server adds another layer of obfuscation on the design of WKD itself: it returns OpenPGP certificates for any WKD request for Proton email identities. In the case of non-existing email addresses, a synthetic certificate is generated and returned, to frustrate attempts to identify actively used Proton email addresses. ↩︎

49 KiB Raw Blame History Unescape Escape