From 78ec12bb208bafc3e957ac4b1de06df9afd8652f Mon Sep 17 00:00:00 2001 From: Justus Winter Date: Tue, 14 Dec 2021 12:39:15 +0100 Subject: [PATCH] XXX we're still working on the text... add news entry for OpenPGP CA support --- dist/templates/about/news.html.hbs | 99 ++++++++++++++++++++++ dist/templates/atom.xml.hbs | 8 +- dist/templates/index.html.hbs | 2 +- po/hagrid/de.po | 13 ++- po/hagrid/en.po | 4 +- po/hagrid/hagrid.pot | 2 +- po/hagrid/ja.po | 4 +- src/gettext_strings.rs | 2 +- templates-untranslated/about/news.html.hbs | 99 ++++++++++++++++++++++ 9 files changed, 221 insertions(+), 12 deletions(-) diff --git a/dist/templates/about/news.html.hbs b/dist/templates/about/news.html.hbs index 0283926..abad65a 100644 --- a/dist/templates/about/news.html.hbs +++ b/dist/templates/about/news.html.hbs @@ -2,6 +2,105 @@

About | News | Usage | FAQ | Stats | Privacy

+

+
2021-12-20 📅
+ Adding support for third-party certifications to Hagrid +

+

+ When we designed keys.openpgp.org, we wanted users to be in control + of their certificates. That's one of the reasons that keys.openpgp.org + strips third-party certifications. But certifications are useful, and + key servers are a convenient way to distribute them. So, we're adding + support to Hagrid to distribute them while still keeping users in control. + +

+ Historically, when Alice signed Bob's certificate, and uploaded + the certification to a key server, the key server attached her + certification to Bob's certificate, and there was nothing that Bob could do + to remove it. + +

+ In general, attaching third-party certifications to the signed certificate + isn't really a problem. If a certification is irrelevant, it is just ignored. + But this policy means that third parties can attach an arbitrary number of certifications + to Bob's key (see here and here). Bob could get a lot of certifications if he is very popular. Or, + an attacker could upload a lot of valid, but useless certifications. + +

+ We've identified three mechanisms that allow keys.openpgp.org to + distribute certifications while preventing these types of attacks. + +

+ Support for 1pa3pc certifications + +

+ First, a user can add a so-called 1pa3pc signature to their certificate. + This special signature allows the user to decide who is allowed to sign + their certificate. + +

+ Using 1pa3pc, if Bob is happy for keys.openpgp.org to distribute + signatures by Alice, then he adds Alice's key to his 1pa3pc signature. + When keys.openpgp.org sees that signature, it won't strip third-party certifications + from Alice, but it will strip other third-party certifications. If an + attacker tries to flood Bob's key, the certifications will simply be ignored, since + they are not made by keys on Bob's good list. + +

+ Sequoia already makes it convenient to + add 1pa3pc packets, as this example shows: + + 

+    $ sq key attest-certifications <mykey.pgp >mykey.attested.pgp
+    $ sq key extract-cert <mykey.attested.pgp >mycert.attested.pgp
+
+ +

+ We hope other tooling will add support for them + in the future. + +

+ Support for OpenPGP CA certifications + +

+ The second scenario where keys.openpgp.org distributes certifications + doesn't require the user to opt-in, which makes it much more convenient + for normal users. This mode is designed for OpenPGP CA, a new + tool that makes it easy for organizations to set up their own CA. + +

+ The problem that OpenPGP CA helps solve is how to do strong authentication. That is, how does Alice know that she has the right key for Bob? Traditionally, when using PGP (or Signal, or any other tool that doesn't rely on central authorities), it is up to each individual user to make sure they use the right key for each of their correspondents. One way do this with PGP is for users to check each of their correspondent's fingerprints. In Signal, users need to check each other's safety numbers. This doesn’t scale. + +

+ OpenPGP CA's proposition is that often it is better for Alice to rely on a third party to check fingerprints on her behalf. This is especially reasonable in many organizations where users already rely on their IT department to perform security relevant tasks for them. So, if Alice relies on her IT department to install updates on her machine, then she can just as well rely on them to perform these checks on her behalf. This doesn't only save Alice time and trouble, but the IT department staff is typically much better trained to perform such tasks safely and efficiently. + +

+ An organisation that uses OpenPGP CA has CA key with the User ID + openpgp-ca@example.org. + This key certifies all of the other keys in the organization. Of course, + for these certifications to be useful, they need to be distributed. + +

+ To better support OpenPGP CA, keys.openpgp.org will + return certifications made by a User ID of the form openpgp-ca@example.org, + if this email address has been verified, and for User IDs in their own domain. That is, the CA openpgp-ca@example.org is allowed to publish certifications for alice@example.org, + but not for bob@other.org. Conversely, if alice@example.org certifies + openpgp-ca@example.org, keys.openpgp.org will also publish that certification. + +

+ It is still possible for someone to spam certificates with this mechanism. For instance, + if an attacker registers openpgp-ca@web.de, they can issue a certification for every + certificate that has a web.de email address; we don't check that + openpgp-ca@web.de is a valid CA, we only check that the person who controls + that email address also controls the key. However, our design only allows + the publication of one such gratuitous certification per User ID, which is far from a + denial-of-service attack. + +

+ OpenPGP CA also supports the concept of CA bridges where one + organization certifies another organization's CA. These + certifications are supported if the certification is mutual. +

2019-11-12 📅
Celebrating 100.000 verified addresses! 📈 diff --git a/dist/templates/atom.xml.hbs b/dist/templates/atom.xml.hbs index 7229898..0b78752 100644 --- a/dist/templates/atom.xml.hbs +++ b/dist/templates/atom.xml.hbs @@ -3,7 +3,13 @@ keys.openpgp.org urn:uuid:8e783366-73b1-460e-83d3-42f01046646d - 2019-11-12T12:00:00Z + 2021-12-20T12:00:00Z + + Support for OpenPGP-CA + + 2021-12-20T12:00:00Z + urn:uuid:aca50bf2-5310-4d6a-8ee1-d361be7ce201 + Celebrating 100.000 verified addresses! 📈 diff --git a/dist/templates/index.html.hbs b/dist/templates/index.html.hbs index 65af7c2..ddba936 100644 --- a/dist/templates/index.html.hbs +++ b/dist/templates/index.html.hbs @@ -25,7 +25,7 @@

- {{ text "News:" }} {{ text "Celebrating 100.000 verified addresses! 📈 (2019-11-12)" }} + {{ text "News:" }} {{ text "Support for OpenPGP-CA (2021-12-20)" }}

{{/with}} {{/layout}} diff --git a/po/hagrid/de.po b/po/hagrid/de.po index c87900c..e7f0bea 100644 --- a/po/hagrid/de.po +++ b/po/hagrid/de.po @@ -87,11 +87,9 @@ msgid "News:" msgstr "News:" msgid "" -"Celebrating 100.000 " -"verified addresses! 📈 (2019-11-12)" +"Support for third-party " +"certification signatures (2021-09-21)" msgstr "" -"Wir feiern 100.000 " -"überprüfte Adressen! 📈 (2019-11-12)" msgid "v{{ version }} built from" msgstr "v{{ version }}, Revision" @@ -401,3 +399,10 @@ msgstr "Zeitlimit beim Hochladen abgelaufen. Bitte versuch es erneut." msgid "Invalid verification link." msgstr "Ungültiger Bestätigungs-Link." + +#~ msgid "" +#~ "Celebrating 100.000 " +#~ "verified addresses! 📈 (2019-11-12)" +#~ msgstr "" +#~ "Wir feiern 100.000 " +#~ "überprüfte Adressen! 📈 (2019-11-12)" diff --git a/po/hagrid/en.po b/po/hagrid/en.po index c08ea1d..7198f14 100644 --- a/po/hagrid/en.po +++ b/po/hagrid/en.po @@ -81,8 +81,8 @@ msgid "News:" msgstr "News:" msgid "" -"Celebrating 100.000 " -"verified addresses! 📈 (2019-11-12)" +"Support for third-party " +"certification signatures (2021-09-21)" msgstr "" #, fuzzy diff --git a/po/hagrid/hagrid.pot b/po/hagrid/hagrid.pot index 465cf08..090ca2b 100644 --- a/po/hagrid/hagrid.pot +++ b/po/hagrid/hagrid.pot @@ -71,7 +71,7 @@ msgstr "" msgid "News:" msgstr "" -msgid "Celebrating 100.000 verified addresses! 📈 (2019-11-12)" +msgid "Support for third-party certification signatures (2021-09-21)" msgstr "" msgid "v{{ version }} built from" diff --git a/po/hagrid/ja.po b/po/hagrid/ja.po index ec1ea34..7057956 100644 --- a/po/hagrid/ja.po +++ b/po/hagrid/ja.po @@ -86,8 +86,8 @@ msgid "News:" msgstr "ニュース:" msgid "" -"Celebrating 100.000 " -"verified addresses! 📈 (2019-11-12)" +"Support for third-party " +"certification signatures (2021-09-21)" msgstr "" msgid "v{{ version }} built from" diff --git a/src/gettext_strings.rs b/src/gettext_strings.rs index 8e36a4e..c18e1ae 100644 --- a/src/gettext_strings.rs +++ b/src/gettext_strings.rs @@ -13,7 +13,7 @@ fn _dummy() { t!("You can also upload or manage your key."); t!("Find out more about this service."); t!("News:"); - t!("Celebrating 100.000 verified addresses! 📈 (2019-11-12)"); + t!("Support for third-party certification signatures (2021-09-21)"); t!("v{{ version }} built from"); t!("Powered by Sequoia-PGP"); t!("Background image retrieved from Subtle Patterns under CC BY-SA 3.0"); diff --git a/templates-untranslated/about/news.html.hbs b/templates-untranslated/about/news.html.hbs index 161d228..8b45903 100644 --- a/templates-untranslated/about/news.html.hbs +++ b/templates-untranslated/about/news.html.hbs @@ -1,6 +1,105 @@

About | News | Usage | FAQ | Stats | Privacy

+

+
2021-12-20 📅
+ Adding support for third-party certifications to Hagrid +

+

+ When we designed keys.openpgp.org, we wanted users to be in control + of their certificates. That's one of the reasons that keys.openpgp.org + strips third-party certifications. But certifications are useful, and + key servers are a convenient way to distribute them. So, we're adding + support to Hagrid to distribute them while still keeping users in control. + +

+ Historically, when Alice signed Bob's certificate, and uploaded + the certification to a key server, the key server attached her + certification to Bob's certificate, and there was nothing that Bob could do + to remove it. + +

+ In general, attaching third-party certifications to the signed certificate + isn't really a problem. If a certification is irrelevant, it is just ignored. + But this policy means that third parties can attach an arbitrary number of certifications + to Bob's key (see here and here). Bob could get a lot of certifications if he is very popular. Or, + an attacker could upload a lot of valid, but useless certifications. + +

+ We've identified three mechanisms that allow keys.openpgp.org to + distribute certifications while preventing these types of attacks. + +

+ Support for 1pa3pc certifications + +

+ First, a user can add a so-called 1pa3pc signature to their certificate. + This special signature allows the user to decide who is allowed to sign + their certificate. + +

+ Using 1pa3pc, if Bob is happy for keys.openpgp.org to distribute + signatures by Alice, then he adds Alice's key to his 1pa3pc signature. + When keys.openpgp.org sees that signature, it won't strip third-party certifications + from Alice, but it will strip other third-party certifications. If an + attacker tries to flood Bob's key, the certifications will simply be ignored, since + they are not made by keys on Bob's good list. + +

+ Sequoia already makes it convenient to + add 1pa3pc packets, as this example shows: + + 

+    $ sq key attest-certifications <mykey.pgp >mykey.attested.pgp
+    $ sq key extract-cert <mykey.attested.pgp >mycert.attested.pgp
+
+ +

+ We hope other tooling will add support for them + in the future. + +

+ Support for OpenPGP CA certifications + +

+ The second scenario where keys.openpgp.org distributes certifications + doesn't require the user to opt-in, which makes it much more convenient + for normal users. This mode is designed for OpenPGP CA, a new + tool that makes it easy for organizations to set up their own CA. + +

+ The problem that OpenPGP CA helps solve is how to do strong authentication. That is, how does Alice know that she has the right key for Bob? Traditionally, when using PGP (or Signal, or any other tool that doesn't rely on central authorities), it is up to each individual user to make sure they use the right key for each of their correspondents. One way do this with PGP is for users to check each of their correspondent's fingerprints. In Signal, users need to check each other's safety numbers. This doesn’t scale. + +

+ OpenPGP CA's proposition is that often it is better for Alice to rely on a third party to check fingerprints on her behalf. This is especially reasonable in many organizations where users already rely on their IT department to perform security relevant tasks for them. So, if Alice relies on her IT department to install updates on her machine, then she can just as well rely on them to perform these checks on her behalf. This doesn't only save Alice time and trouble, but the IT department staff is typically much better trained to perform such tasks safely and efficiently. + +

+ An organisation that uses OpenPGP CA has CA key with the User ID + openpgp-ca@example.org. + This key certifies all of the other keys in the organization. Of course, + for these certifications to be useful, they need to be distributed. + +

+ To better support OpenPGP CA, keys.openpgp.org will + return certifications made by a User ID of the form openpgp-ca@example.org, + if this email address has been verified, and for User IDs in their own domain. That is, the CA openpgp-ca@example.org is allowed to publish certifications for alice@example.org, + but not for bob@other.org. Conversely, if alice@example.org certifies + openpgp-ca@example.org, keys.openpgp.org will also publish that certification. + +

+ It is still possible for someone to spam certificates with this mechanism. For instance, + if an attacker registers openpgp-ca@web.de, they can issue a certification for every + certificate that has a web.de email address; we don't check that + openpgp-ca@web.de is a valid CA, we only check that the person who controls + that email address also controls the key. However, our design only allows + the publication of one such gratuitous certification per User ID, which is far from a + denial-of-service attack. + +

+ OpenPGP CA also supports the concept of CA bridges where one + organization certifies another organization's CA. These + certifications are supported if the certification is mutual. +

2019-11-12 📅
Celebrating 100.000 verified addresses! 📈