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

remove stray comma

Browse source
This commit is contained in:
Tammi L. Coles 2024-02-16 15:47:42 +01:00
parent a70f4fb347
commit 1135e8059f
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -293,7 +293,7 @@ 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. 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).
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. 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.