mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-12-22 05:47:58 +01:00
edit metadata leak of social graph and fold into challenges section
This commit is contained in:
parent
2df214d0c1
commit
2b375ad4bb
1 changed files with 10 additions and 19 deletions
|
@ -281,24 +281,6 @@ Once the expiration time is reached, third parties, or ideally their OpenPGP sof
|
|||
|
||||
After the update, the updated copy of the certificate will usually have a fresh expiration time. The same procedure will repeat once that new expiration time has been reached.
|
||||
|
||||
(social-graph-metadata-leak)=
|
||||
## Metadata leak of Social Graph
|
||||
|
||||
Third-party certifications are signatures over identity components made by other users.
|
||||
|
||||
These certifications form the back-bone of the OpenPGP trust-model called the Web of Trust. The name stems from the fact that the collection of certifications forms a unidirectional graph resembling a web. Each edge of the graph connects the signing certificate to the identity component associated with another certificate.
|
||||
|
||||
OpenPGP software can inspect that graph. Based on the certification data in the graph and a set of trust anchors, it can infer whether a target certificate is legitimate.
|
||||
|
||||
The trust anchor is usually the certificate holder's own key, but a user may designate additional certificates of entities they are connected to as trust anchors.
|
||||
|
||||
Third-party certifications can be published as part of the target certificate to facilitate the process of certificate authentication. Unfortunately, a side effect of this approach is that it's feasible to reconstruct the entire social graph of all people issuing certifications. In addition, the signature creation time of certifications can be used to deduce whether the certificate owner attended a Key Signing Party (and if it was public, where it was held) and whom they interacted with.
|
||||
|
||||
So, there is some tension between the goals of
|
||||
|
||||
- a decentralized system where every participant can access certification information and perform analysis on it locally,
|
||||
- privacy related goals (also see {ref}`certificate-lookup-by-email`, for a comparison of certificate distribution mechanisms, which also touches on this theme).
|
||||
|
||||
(unbound-user-ids)=
|
||||
## Adding unbound, local User IDs to a certificate
|
||||
|
||||
|
@ -331,4 +313,13 @@ The OpenPGP community has evolved strategies to counter certificate flooding, no
|
|||
|
||||
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 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)).
|
||||
|
||||
(social-graph-metadata-leak)=
|
||||
### 18.7.2. Metadata leak of social graph
|
||||
|
||||
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.
|
Loading…
Reference in a new issue