mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-25 17:12:06 +01:00
clean up formatting, remove bullet points on main paragraphs
This commit is contained in:
parent
b29e9448fe
commit
0367dc98a4
1 changed files with 14 additions and 13 deletions
|
@ -197,6 +197,7 @@ gpg --export-options export-minimal,export-clean,no-export-attributes \
|
|||
--export wiktor@metacode.biz
|
||||
|
||||
The process significantly reduces the certificate size from 152,322 bytes to just 3,771 bytes, demonstrating a substantial decrease in size by over 40 times. Such minimization is particularly crucial in contexts with strict size limitations, like embedding certificate data in email headers.
|
||||
```
|
||||
|
||||
## Identifying certificates: Fingerprints and Key IDs
|
||||
|
||||
|
@ -208,9 +209,9 @@ This section delves into the evolution of these identifiers, their practical app
|
|||
|
||||
The development of fingerprints within the OpenPGP framework reflects ongoing efforts to bolster security measures and align with current cryptographic standards. Initially, fingerprints were shorter and derived using less secure hashing algorithms. As cryptographic standards advanced, the need for longer, more secure fingerprints became apparent, leading to the adoption of longer hash functions to generate these identifiers.
|
||||
|
||||
- **Version 4 fingerprints**: OpenPGP version 4 introduced 20-byte (160-bit) fingerprints, generated using the SHA-1 hashing algorithm. These fingerprints became the standard for identifying certificates, with their hexadecimal representation commonly used in various user workflows. Activities such as verifying a new contact's certificate or issuing third-party certifications often required manual comparison of these fingerprints, highlighting their centrality to OpenPGP's trust-building processes.
|
||||
**Version 4 fingerprints**: OpenPGP version 4 introduced 20-byte (160-bit) fingerprints, generated using the SHA-1 hashing algorithm. These fingerprints became the standard for identifying certificates, with their hexadecimal representation commonly used in various user workflows. Activities such as verifying a new contact's certificate or issuing third-party certifications often required manual comparison of these fingerprints, highlighting their centrality to OpenPGP's trust-building processes.
|
||||
|
||||
- **Version 6 fingerprints**: The OpenPGP version 6 standards transition to 32-byte (256-bit) fingerprints, enhancing security through the use of stronger hash functions. However, due to the challenges humans face in comparing high-entropy data, [version 6 explicitly recommends against using these longer fingerprints](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-fingerprint-usability) in user-facing contexts, advocating instead for "mechanical fingerprint transfer and comparison" whenever possible. This shift underscores the evolving considerations around the usability and security of certificate identifiers[^schuermann].
|
||||
**Version 6 fingerprints**: The OpenPGP version 6 standards transition to 32-byte (256-bit) fingerprints, enhancing security through the use of stronger hash functions. However, due to the challenges humans face in comparing high-entropy data, [version 6 explicitly recommends against using these longer fingerprints](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-fingerprint-usability) in user-facing contexts, advocating instead for "mechanical fingerprint transfer and comparison" whenever possible. This shift underscores the evolving considerations around the usability and security of certificate identifiers[^schuermann].
|
||||
|
||||
[^schuermann]: See "An Empirical Study of Textual Key-Fingerprint Representations" [<https://www.ibr.cs.tu-bs.de/papers/schuermann-usenix2016.pdf>](https://www.ibr.cs.tu-bs.de/papers/schuermann-usenix2016.pdf)
|
||||
|
||||
|
@ -227,9 +228,9 @@ In essence, fingerprints and Key IDs are crucial for software to programmaticall
|
|||
|
||||
A common use case of fingerprints and Key IDs, crucial for day-to-day secure communications, is locating an OpenPGP certificate associated with an email address.
|
||||
|
||||
- **[Web Key Directory (WKD)](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/)** and **[Hagrid](https://keys.openpgp.org/)** exemplify systems that leverage these identifiers for secure and privacy-respecting certificate lookup by email, enhancing the reliability of encrypted email communications.
|
||||
**[Web Key Directory (WKD)](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/)** and **[Hagrid](https://keys.openpgp.org/)** exemplify systems that leverage these identifiers for secure and privacy-respecting certificate lookup by email, enhancing the reliability of encrypted email communications.
|
||||
|
||||
- **SKS-style keyservers** represent a more traditional approach to certificate distribution. Despite their age, these keyservers continue to play a role in the OpenPGP ecosystem. Today, most of these run the [Hockeypuck](https://github.com/hockeypuck/hockeypuck) software, which helps secure the keyserver infrastructure. SKS-style keyservers use fingerprints and Key IDs for certificate indexing and retrieval, underscoring the universal applicability of these identifiers in enhancing email security across various platforms.
|
||||
**SKS-style keyservers** represent a more traditional approach to certificate distribution. Despite their age, these keyservers continue to play a role in the OpenPGP ecosystem. Today, most of these run the [Hockeypuck](https://github.com/hockeypuck/hockeypuck) software, which helps secure the keyserver infrastructure. SKS-style keyservers use fingerprints and Key IDs for certificate indexing and retrieval, underscoring the universal applicability of these identifiers in enhancing email security across various platforms.
|
||||
|
||||
While their properties differ, these mechanisms showcase the indispensable role of fingerprints and Key IDs in facilitating secure email exchanges within the OpenPGP ecosystem.
|
||||
|
||||
|
@ -242,31 +243,31 @@ The OpenPGP ecosystem employs various mechanisms for the distribution and retrie
|
|||
|
||||
The Web Key Directory (WKD) offers a decentralized solution for the distribution of OpenPGP certificates, enabling domain owners to host OpenPGP keys on their own web servers. This approach provides a direct, user-friendly method for retrieving certificates based on email addresses, aligning with OpenPGP's trust and privacy principles.
|
||||
|
||||
- **Decentralization and domain control**: WKD's decentralized framework allows for the hosting of certificates in a well-known location on a webserver, managed by the entity controlling the DNS domain of an email-based identity. This model empowers domain owners with direct control over the certificates associated with their domain, enhancing security and trustworthiness. The decentralization aspect ensures that the reliability and availability of OpenPGP certificates can vary depending on the organization operating each WKD instance, allowing for tailored security practices and policies.
|
||||
**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.
|
||||
**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.
|
||||
**Seamless integration with email systems**: WKD leverages the existing infrastructure of email addresses and domain names for smooth integration with email clients. This supports the automatic discovery and retrieval of certificates, streamlining the process for end-users. Such seamless integration ensures that certificates are always current, making secure communication more accessible and manageable.
|
||||
|
||||
### keys.openpgp.org (Hagrid)
|
||||
|
||||
Hagrid, the software powering the keys.openpgp.org service, represents a paradigm shift in keyserver design, focusing on verifying user identities and safeguarding privacy. This "verifying" keyserver model is distinctive for its approach to managing identity components associated with OpenPGP certificates.
|
||||
|
||||
- **Trust and verification**: Hagrid introduces a rigorous verification process, wherein identity components (including email addresses) are only published after the keyserver has sent a verification email to the address in question and received explicit opt-in consent from the user. This verification mechanism ensures that all published certificates are authentically linked to their claimed identities, significantly mitigating risks of impersonation and unauthorized certificate publication.
|
||||
**Trust and verification**: Hagrid introduces a rigorous verification process, wherein identity components (including email addresses) are only published after the keyserver has sent a verification email to the address in question and received explicit opt-in consent from the user. This verification mechanism ensures that all published certificates are authentically linked to their claimed identities, significantly mitigating risks of impersonation and unauthorized certificate publication.
|
||||
|
||||
- **Centralization and privacy considerations**: Unlike traditional, decentralized keyservers, Hagrid operates on a centralized model, which necessitates trust in the operator to accurately perform verification steps. However, this centralization facilitates a trade-off that enhances privacy: Hagrid prevents the "enumeration" of certificates and identities, meaning third parties cannot simply list or query all email addresses stored in the service's database. This feature is critical for user privacy and control over personal information in the digital space.
|
||||
**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, enabling users to easily update or invalidate their certificates without necessitating the publication of additional identity components.
|
||||
|
||||
### SKS-style keyservers: Challenges and solutions
|
||||
|
||||
SKS-style keyservers have historically facilitated the exchange of OpenPGP certificates within a distributed, unverified database framework. While instrumental in the OpenPGP ecosystem, this model has encountered significant challenges, particularly related to security and privacy.
|
||||
|
||||
- **Security and privacy concerns**: The openness of SKS-style keyservers has exposed them to certificate flooding attacks, where attackers inundate a key with excessive, often malicious, signatures. This not only disrupts operational efficiency but also raises privacy concerns, as these servers indiscriminately distribute third-party certifications and identity packets, potentially without the certificate owner's consent.
|
||||
**Security and privacy concerns**: The openness of SKS-style keyservers has exposed them to certificate flooding attacks, where attackers inundate a key with excessive, often malicious, signatures. This not only disrupts operational efficiency but also raises privacy concerns, as these servers indiscriminately distribute third-party certifications and identity packets, potentially without the certificate owner's consent.
|
||||
|
||||
- **Adaptive responses and Hockeypuck's role**: In response, the OpenPGP community has sought solutions to these vulnerabilities. Hockeypuck, an advanced keyserver software, exemplifies these efforts by aiming to enhance security and data integrity, directly addressing the limitations of the traditional SKS architecture. One notable discussion within the community ([GitHub issue #136](https://github.com/hockeypuck/hockeypuck/issues/136)) focuses on proposals like HIP-1, aiming to provide key owners with more control over their certificates on keyservers, thus mitigating risks such as certificate flooding.
|
||||
**Adaptive responses and Hockeypuck's role**: In response, the OpenPGP community has sought solutions to these vulnerabilities. Hockeypuck, an advanced keyserver software, exemplifies these efforts by aiming to enhance security and data integrity, directly addressing the limitations of the traditional SKS architecture. One notable discussion within the community ([GitHub issue #136](https://github.com/hockeypuck/hockeypuck/issues/136)) focuses on proposals like HIP-1, aiming to provide key owners with more control over their certificates on keyservers, thus mitigating risks such as certificate flooding.
|
||||
|
||||
- **Evolving towards more secure models**: This transition from SKS-style servers to more controlled, secure models signifies a broader shift within the OpenPGP community. Newer mechanisms like WKD and Hagrid illustrate this evolution, offering more privacy-respecting and user-centric approaches to certificate distribution. Hagrid, in particular, introduces a verifying keyserver model that only distributes verified identity information, a stark contrast to the traditional SKS system's approach.
|
||||
**Evolving towards more secure models**: This transition from SKS-style servers to more controlled, secure models signifies a broader shift within the OpenPGP community. Newer mechanisms like WKD and Hagrid illustrate this evolution, offering more privacy-respecting and user-centric approaches to certificate distribution. Hagrid, in particular, introduces a verifying keyserver model that only distributes verified identity information, a stark contrast to the traditional SKS system's approach.
|
||||
|
||||
The progression from SKS-style keyservers to innovative solutions like Hockeypuck and Hagrid demonstrates the OpenPGP community's commitment to safeguarding the OpenPGP ecosystem against evolving threats, ensuring a more secure and reliable infrastructure for certificate distribution.
|
||||
|
||||
|
|
Loading…
Reference in a new issue