WIP: ch18-tammi #274
No reviewers
Labels
No labels
bug
contribution welcome
correction/clarification
diagrams
duplicate
enhancement
final checks
good first issue
help wanted
project management
question
sphinx
style guide
terminology cleanup
upstream
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
openpgp/notes!274
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "ch18-tammi"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@ -155,0 +157,4 @@[Hagrid keyserver software](https://gitlab.com/keys.openpgp.org/hagrid), operating keys.openpgp.org, adopts a privacy-centric model by not automatically publishing identity components of certificates. According to its [privacy policy](https://keys.openpgp.org/about/privacy), the service allows certificates to be uploaded by anyone, but identifying information is shared only with the certificate owner's explicit opt-in. This measure significantly contributes to user privacy and aids in minimizing certificates by default.Additionally, to mitigate the risk of certificate flooding, Hagrid currently filters out third-party certifications, further aligning with certificate minimization principles.Hagrid actually accepts and retains third-party certifications if they have been approved by the keyholder, via the mechanism described in draft-dkg-openpgp-1pa3pc. I don't know whether you want to include that in this commentary.
@ -376,2 +305,3 @@#### 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](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.Please use "first party approved", not "first party attested". the acronym 1pa3pc remains the same, but it is probably worthwhile to avoiding the use of the word "attested", as it has a significantly different meaning in other contexts.
The draft cited uses "Approved" in its title and in its body. (historically, the early versions of this work did use the term "attested", but folks doing other work using the term attestation protested, so we switched to "Approved").
@ -381,1 +311,3 @@- 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 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.please drop this (and all references) to draft-ietf-openpgp-rfc4880bis -- unless you're in the weeds of historical/archaeological discussion about the process of producing new standards, either refer to rfc9580, or to rfc4880.
btw, i know i'm reporting problems above (and will probably report more later) but i don't want to seem just plain negative about this. This is really useful work, and i don't think i've ever seen these concepts and concerns spelled out quite this clearly. My comments are trying to polish it even further, not to dissuade anyone from making these contributions in the first place!
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.