vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2024-11-25 17:12:06 +01:00
Code Issues Projects Releases Packages Wiki Activity

create new section called "Challenges in certificate management", fold in flooding, 1pa3pc, and support sections

Browse source
This commit is contained in:
Tammi L. Coles 2024-02-16 11:06:28 +01:00
parent a44068ba62
commit 2df214d0c1
1 changed files with 13 additions and 37 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -309,50 +309,26 @@ Some OpenPGP software may add User IDs to a certificate, which are not bound to
Sequoia additionally certifies these "local, third party, User IDs" with a local trust anchor to facilitate local authentication decisions. Sequoia additionally certifies these "local, third party, User IDs" with a local trust anchor to facilitate local authentication decisions.
To prevent accidental publication of these local User IDs (e.g. to public keyservers), Sequoia marks these binding signatures as "local" artifacts using [Exportable Certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-exportable-certification) subpackets to mark them as non-exportable. To prevent accidental publication of these local User IDs (e.g. to public keyservers), Sequoia marks these binding signatures as "local" artifacts using [Exportable Certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-exportable-certification) subpackets to mark them as non-exportable.
## Challenges in certificate management
The management of OpenPGP certificates encompasses various challenges, ranging from security vulnerabilities to privacy concerns. This section addresses some of the most significant challenges and the responses developed by the OpenPGP community to mitigate these issues.
(keyserver-flooding)= (keyserver-flooding)=
## Third-party certification flooding ### Third-party certification flooding and responses
Traditional OpenPGP keyservers are one mechanism for [collection and distribution](certificate-distribution) of certificate information. Their model revolves around receiving certificate information from sources that don't identify themselves to the keyserver network. Traditionally, these keyservers have accepted both components bound to certificates by self-signatures, and third party identity certifications. 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.
While a convenience for consumers, indiscriminately accepting and integrating third-party identity certifications comes with significant risks. #### Certificate flooding: Risks and impacts
Without any restrictions in place, malicious entities can flood a certificate with excessive certifications. Called "certificate flooding," this form of digital vandalism grossly expands the certificate size, making the certificate cumbersome and impractical for users. 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.
It also opens the door to potential denial-of-service attacks, rendering the certificate non-functional or significantly impeding its operation. The popular SKS keyserver network experienced certificate flooding firsthand. The 2019 incident, [detailed by security researcher Daniel Kahn Gillmor on his blog](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html), highlights the severe operational challenges posed by such attacks within the OpenPGP ecosystem.
The popular [SKS keyserver network experienced certificate flooding firsthand](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html) in 2019, causing significant changes to its operation.
```{note}
The *keys.openpgp.org* (KOO) service performs a similar function as the SKS-style keyservers.
However, there are major differences in its design and tradeoffs.
The KOO keyserver was designed to:
1. conform to [GDPR regulations](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation), and
2. be resistant to flooding-style vandalism.
To achieve these goals, KOO does not serve identity components at all, unless an explicit opt-in has been performed, using a confirmation process vial email. Third-party certifications are also not served by default, but only under very specific circumstances, which preclude flooding.
```
### Hockeypuck-based keyservers
Currently, third-party certification flooding can be worked around by users or administrators requesting the removal/re-adding of a certificate. [See here](https://github.com/hockeypuck/hockeypuck/wiki/HIP-1:-Regaining-control-over-public-key-identity-with-authenticated-key-management).
Additional mechanisms [are upcoming](support-for-1pa3pc).
## First-Party attested third-party certifications in OpenPGP (1pa3pc)
[First-Party attested third-party certifications in OpenPGP](https://datatracker.ietf.org/doc/draft-dkg-openpgp-1pa3pc/) are a "mechanism to allow the owner of a certificate to explicitly approve of specific third-party certifications". 1pa3pc was designed to enable flooding-proof distribution of third-part certifications.
This mechanism uses the *attested certifications* signature subpacket (type ID `37`), which currently only exists as a proposed feature in [draft-ietf-openpgp-rfc4880bis](https://www.ietf.org/archive/id/draft-ietf-openpgp-rfc4880bis-10.html#table-3)[^ac-draft].
[^ac-draft]: Introducing the *attested certifications* signature subpacket (type ID `37`) was unfortunately not in scope of the chartered topics for the current "crypto-refresh" work of the OpenPGP working group. However, hopefully the working group can handle this feature in future rechartering.
(support-for-1pa3pc)= (support-for-1pa3pc)=
### Support #### Modern responses: 1pa3pc and keyserver design considerations
- The *keys.openpgp.org* (KOO) keyserver [supports *1pa3pc*](https://gitlab.com/keys.openpgp.org/hagrid/-/commit/39c0e12ac64588220d36bada6497d8396f5915b3). 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 Hockeypuck keyserver software [plans to add support for *1pa3pc*](https://github.com/hockeypuck/hockeypuck/issues/136#issuecomment-1812466084) in version 2.2.0. 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.
- The Sequoia `sq` commandline tool [allows adding](https://man.archlinux.org/man/sq-key-attest-certifications.1) attested third-party certifications to a certificate. 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)).