vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2024-12-21 13:27:57 +01:00
Code Issues Projects Releases Packages Wiki Activity

edits for terminology, precision, clarity

Browse source
This commit is contained in:
Heiko Schaefer 2024-03-05 13:38:38 +01:00
parent 1135e8059f
commit 6b06644db5
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 99 additions and 72 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

171
book/source/adv/certificates.md
View file

@ -11,7 +11,7 @@ OpenPGP certificates are pivotal in establishing and maintaining trust within th
### 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.
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
@ -27,17 +27,17 @@ OpenPGP certificates are integral to establishing and maintaining secure communi
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.
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](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#signature-expiration-subpacket) for identity components. An expired binding signature invalidates the component it is associated with, emphasizing the critical role of timely updates.
Expiration dates are set using [*key expiration time* subpackets](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-expiration-time) for subkeys, and [*signature expiration time* subpackets](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#signature-expiration-subpacket) for identity components. An expired binding signature invalidates the component it is associated with, emphasizing the critical role of timely updates.
### The 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.
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 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.
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
@ -49,10 +49,10 @@ OpenPGP certificates are designed as "append only" data structures, meaning that
Revocation can apply to individual components of a certificate, such as User IDs and subkeys, allowing specific elements to be marked as invalid without affecting the overall certificate. However, revoking the *primary User ID* or the primary key with a [*Key revocation signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-revocation-signature-ty) (type ID `0x20`) has a more significant effect, marking the entire certificate and all its components as invalid and unusable.
The OpenPGP standard facilitates various [*Reasons for Revocation*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#reason-for-revocation), each denoting the specific rationale behind the revocation. These reasons allow for nuanced distinctions between "soft" and "hard" revocations, impacting how the revocation affects the certificate's use:
The OpenPGP standard distinguishes various [*Reasons for Revocation*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#reason-for-revocation), each denoting the specific rationale behind the revocation. These reasons allow for nuanced distinctions between "soft" and "hard" revocations, impacting how the revocation affects the certificate's use:
- *Soft revocations* (e.g., *Key is superseded*, *Key is retired*, *User ID is no longer valid*) suggest that the revoked component may still have valid uses before the revocation time, allowing for historical verification of signatures.
- *Hard revocations* signal a significant trust breach, such as key compromise, and are treated as valid from the moment of the key's creation, effectively invalidating it for all time.
- *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
@ -65,28 +65,30 @@ By understanding the mechanisms and semantics of revocation, OpenPGP users and i
[^undo-revocations]: While some revocations can be reverted, undoing revocations is an uncommon workflow. Unlike expirations, which are commonly undone by extending the expiration time.
(certificate-merging)=
## 18.3 Merging and updating certificates
## 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.
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 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.
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 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.
- **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 both comprehensive and accurate.
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, such as third-party certifications or subkeys. Handling this unauthenticated information requires careful consideration to maintain the trustworthiness of the certificate.
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:
@ -112,7 +114,7 @@ When considering edge cases within this distributed system, it's prudent to "ass
- 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.
- 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
@ -120,9 +122,9 @@ Variability in certificate views among OpenPGP users highlights the system's inh
Different OpenPGP implementations may handle these challenges in various ways, emphasizing the need for users to understand the potential for discrepancies and adopt practices that ensure the security and reliability of their cryptographic communications.
The diversity of certificate views, influenced by distributed third-party certifications, underscores the complexity of managing privacy and trust within OpenPGP. Users must navigate these challenges with an understanding that not all certificate information may be equally available or desirable to share widely, emphasizing a cautious approach to certificate data management[^tpc-privacy]..
The diversity of certificate views, influenced by distributed third-party certifications, underscores the complexity of managing privacy and trust within OpenPGP. Users must navigate these challenges with an understanding that not all certificate information may be equally available or desirable to share widely, emphasizing a cautious approach to certificate data management[^tpc-privacy].
One mechanism that addresses a part of this issue is *expiration*: By setting their certificates to expire after an appropriate interval, certificate holders can force their communication partners to refresh their certificate, e.g., from a keyserver[^mgorny]. This approach not only helps in naturally eliminating unused keys but also enforces periodical checks on the primary key, thereby promoting a consistent and up-to-date view of the certificate across different users.
One mechanism that addresses a part of this issue is *expiration*: By setting their certificates to expire after an appropriate interval, certificate holders can force their communication partners to refresh their certificate, e.g., from a keyserver[^mgorny]. This approach not only helps in naturally eliminating unused keys but also enforces periodical checks for updates to a certificate, thereby promoting a consistent and up-to-date view of the certificate across different users.
[^tpc-privacy]: The two parties to a certification (the issuer and the target of the certification) may prefer not to publish their mutual association. Also see {ref}`social-graph-metadata-leak`.
[^mgorny]: See, for example, [here](https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/): "Expiration times really serve two purposes: naturally eliminating unused keys, and enforcing periodical checks on the primary key."
@ -130,21 +132,24 @@ One mechanism that addresses a part of this issue is *expiration*: By setting th
(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.
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 components to retain or omit, the process can serve distinct purposes:
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 components**: In contexts such as email encryption, only the keys necessary for encryption, signing, and certification are retained, excluding those like authentication subkeys that are irrelevant to the primary use-case.
- **Omitting third-party certifications**: Proactively filtering these out upon import can prevent the overload of a certificate with excessive certifications, a common tactic in [certificate flooding](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html) that is designed to render a certificate unusable. This is particularly relevant when certificates grow organically large, to the point that user software [encounters difficulties handling them](https://www.reddit.com/r/GnuPG/comments/bp23p4/my_key_is_too_large/).
- **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](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html) 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](https://www.reddit.com/r/GnuPG/comments/bp23p4/my_key_is_too_large/).
Additionally, specific elements of a certificate can be selectively omitted during the minimization process to tailor the certificate to its use-case, improve manageability, and ensure software compatibility:
- **Subkeys and their signatures**: Subkeys not used for the current application, along with their associated signatures, can be omitted.
- **Identity components and outdated signatures**: Both self-signatures that have been superseded by newer versions and third-party signatures on identity components that are not necessary can be excluded. This helps keep the certificate lean and focused on its current application, reducing bloat and enhancing performance.
- **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 security threats and privacy concerns. It strikes a careful balance, maintaining the OpenPGP trust framework while optimizing certificates for efficiency and specific operational contexts.
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
@ -156,39 +161,39 @@ Additionally, to mitigate the risk of certificate flooding, Hagrid currently fil
#### GnuPG
GnuPG introduces two explicit commands for certificate minimization, `clean` and `minimize`, aimed at optimizing certificate size and content.
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 signatures not contributing to trust calculations.
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.
The `minimize` command further reduces the certificate size by retaining only the latest self-signature for each User ID.
Detailed in the [GnuPG manual](https://www.gnupg.org/documentation/manuals/gnupg-devel/OpenPGP-Key-Management.html), these functionalities allow users to manage their certificates efficiently, directly supporting the goals of minimization.
Moreover, GnuPG's approach to handling incoming certificates includes stripping some signatures by default[^gpg-default-strip] to prevent bloating, although this behavior varies across different Linux distributions. For instance, distributions like Debian and Arch Linux have altered this default setting, affecting how third-party certifications are managed upon import.
Moreover, GnuPG's approach to handling incoming certificates includes stripping some signatures by default[^gpg-default-strip], although this behavior varies across different Linux distributions. For instance, distributions like Debian and Arch Linux have altered this default setting, affecting how third-party certifications are managed upon import.
This variance underscores the importance of understanding your specific GnuPG configuration and its effects on certificate minimization, especially for users relying on the [Web of Trust mechanism](wot) for authentication.
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.
[^gpg-default-strip]: GnuPG's changes in the default handling of third-party certifications on imports were prompted by the 2019 [keyserver flooding event](https://dev.gnupg.org/T4607#127792).
## Minimization for email: Use cases and considerations
### 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.
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](https://autocrypt.org/) aims to simplify end-to-end encryption for emails by automatically negotiating encryption capabilities. Autocrypt Level 1 specifies a [minimal format for OpenPGP certificates](https://autocrypt.org/level1.html#openpgp-based-key-data) that are distributed by the autocrypt mechanism in mail headers, emphasizing the importance of keeping certificates small for efficient email communication. An essential practice within the Autocrypt framework is the on-demand generation of minimized certificate views. For instance, when an email is sent or composed, an Autocrypt header is constructed with a freshly minimized version of the sender's certificate. This ensures that the certificate data embedded in the email is both current and optimized for the specific communication context. The receiving end is then expected to merge this data with any locally available information, maintaining a comprehensive and up-to-date view of the certificate.
The approach adopted by [Autocrypt](https://autocrypt.org/) aims to simplify end-to-end encryption for emails by automatically negotiating encryption capabilities. Autocrypt Level 1 specifies a [minimal format for OpenPGP certificates](https://autocrypt.org/level1.html#openpgp-based-key-data) that are distributed by the Autocrypt mechanism in mail headers, emphasizing the importance of keeping certificates small for efficient email communication. An essential practice within the Autocrypt framework is the on-demand generation of minimized certificate views. For instance, when an email is sent or composed, an Autocrypt header is constructed with a freshly minimized version of the sender's certificate. This ensures that the certificate data embedded in the email is both current and optimized for the specific communication context. The receiving end is then expected to merge this data with any locally available information, maintaining a comprehensive and up-to-date view of the certificate.
Proton Mail, a secure email service, exemplifies certificate minimization by selectively fetching only the necessary OpenPGP certificates via Web Key Directory (WKD) when composing a message. This targeted approach ensures that only essential component keys are used, omitting components like invalid subkeys, authentication subkeys not relevant to email encryption, superseded self-signatures, and third-party certifications. With many real-world certificates, the space savings of such a minimization are significant[^space-example].
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[^space-example].
The examples of Autocrypt and Proton Mail illustrate the advantages of certificate minimization in email communications. However, these examples also highlight several challenges:
- **Balance between security and usability:** Minimizing certificates must carefully balance security concerns with usability. Overly aggressive minimization might omit crucial information necessary for verifying the authenticity of a message.
- **Historical signature verification:** The removal of historical self-signatures can complicate the verification of signatures at different reference times, potentially impacting the trustworthiness of the certificate. For an example, see [this discussion](https://github.com/rpm-software-management/rpm-sequoia/issues/50#issuecomment-1689642607) of [temporal validity](temporal-validity) in the case of`rpm-sequoia`.
- **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](https://github.com/rpm-software-management/rpm-sequoia/issues/50#issuecomment-1689642607) of [temporal validity](temporal-validity) in the case of `rpm-sequoia`.
- **Dynamic certificate views:** Minimization strategies need to account for the dynamic nature of certificates, where updates and changes are frequent. This requires a thoughtful approach to ensure that minimized certificates remain current and valid.
Moreover, while pursuing certificate minimization for email, it's essential to balance the reduction in size with the preservation of the OpenPGP trust framework. Adequate information must be retained within the certificate to allow users to verify its authenticity and integrity, ensuring that the minimization process does not impede the ability to establish trust through the Web of Trust mechanism.
Overall, certificate minimization for email presents a promising approach to enhancing email security and performance. However, it requires discernment and careful implementation to navigate the inherent trade-offs between minimizing certificate size and maintaining the integrity and trustworthiness of email communications.
[^space-example]: This example demonstrates how to minimize a certificate using GnuPG commands, targeting only relevant components:
[^space-example]: This example demonstrates how to minimize a certificate using GnuPG commands, retaining only components relevant in an email context:
```sh
gpg --export-options export-minimal,export-clean,no-export-attributes \
@ -199,49 +204,56 @@ Overall, certificate minimization for email presents a promising approach to enh
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
## Identifying certificates: By Fingerprints, Key IDs on email address
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.
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.
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.
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 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.
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 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 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](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].
**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].
**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.
[^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)
### 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](https://evil32.com/), 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 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.
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 using fingerprints and Key IDs
### Certificate lookup by email
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.
A common use case in day-to-day secure communications is locating an OpenPGP certificate that is 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.
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.
**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.
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`):
While their properties differ, these mechanisms showcase the indispensable role of fingerprints and Key IDs in facilitating secure email exchanges within the OpenPGP ecosystem.
**[Web Key Directory (WKD)](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/)** and **[Hagrid](https://keys.openpgp.org/)** 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](https://github.com/hockeypuck/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 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.
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.
@ -249,31 +261,34 @@ The Web Key Directory (WKD) offers a decentralized solution for the distribution
**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 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.
**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.
**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[^revocations-easy-to-publish], enabling users to easily update or invalidate their certificates without necessitating the publication of additional identity components.
[^revocations-easy-to-publish]: 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.
### 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.
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, 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.
**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, 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.
**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](https://github.com/hockeypuck/hockeypuck/issues/136)) focuses on proposals like [HIP-1](https://github.com/hockeypuck/hockeypuck/wiki/HIP-1:-Regaining-control-over-public-key-identity-with-authenticated-key-management), aiming to provide certificate holders 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.
**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 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.
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 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.
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
@ -289,11 +304,11 @@ The popular SKS keyserver network experienced certificate flooding firsthand. Th
(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.
The OpenPGP community has evolved strategies to counter certificate flooding, notably through the development of [First-Party Attested Third-Party Certifications](https://datatracker.ietf.org/doc/draft-dkg-openpgp-1pa3pc/) (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](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.
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).
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](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 [support in the `sq` tool](https://man.archlinux.org/man/sq-key-attest-certifications.1).
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.
@ -306,30 +321,42 @@ However, this model inadvertently risks exposing users' social graphs, revealing
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](hagrid) keyserver, as well as of [WKD](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[^proton-wkd].
[^proton-wkd]: 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.
(unbound-user-ids)=
### Adding unbound, local User IDs to a certificate
OpenPGP allows for the addition of unbound, local user IDs to certificates, enhancing personalization and operational flexibility. These IDs, not globally verified, can attach context-specific aliases or metadata. However, this flexibility introduces challenges related to certificate validity, trust, and potential misuse.
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](https://sequoia-pgp.org/blog/2023/04/08/sequoia-sq/#an-address-book-style-trust-model), advocates for responsible management of local user IDs and their integration. Sequoia certifies these IDs with local trust anchors and marks these binding signatures as "local" artifacts using [Exportable Certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-exportable-certification) subpackets to prevent unintended distribution (e.g., to public keyservers), balancing personalization with security and privacy.
The OpenPGP community, including implementations like [Sequoia PGP](https://sequoia-pgp.org/blog/2023/04/08/sequoia-sq/#an-address-book-style-trust-model), advocates for responsible management of local User IDs and their integration. Sequoia certifies local User IDs in its certificate store with local trust anchors and marks these binding signatures as "local" artifacts using [Exportable Certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-exportable-certification) subpackets to prevent unintended distribution (e.g., to public keyservers), balancing personalization 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:
* omitting unnecessary components and third-party certifications not required for the use case
* employing strategies like GnuPG's `clean` and `minimize` commands, which compact certificates by removing superseded or irrelevant signatures
* considering the use case and context when minimizing, ensuring enough historical self-signatures are included for validation
* 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 to reflect the current cryptographic stance of their owners. Best practices include:
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:
* setting appropriate expiration times to force regular updates and limit the use of revoked certificates
* encouraging automatic updates by OpenPGP software, ideally without human intervention, to maintain certificate relevance and trustworthiness
* 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
@ -337,4 +364,4 @@ Distribution mechanisms like WKD, Hagrid, and SKS-style keyservers facilitate th
* leveraging verifying keyservers like Hagrid for controlled, privacy-aware distribution
* utilizing WKD for decentralized, domain-controlled certificate hosting
* adapting to evolving keyserver designs that mitigate vulnerabilities like certificate flooding
* adapting to evolving keyserver designs that further mitigate problems such as certificate flooding