From aheinecke at gnupg.org Mon Jul 1 09:14:00 2019 From: aheinecke at gnupg.org (Andre Heinecke) Date: Mon, 01 Jul 2019 09:14:00 +0200 Subject: Order of lookup methods in --auto-key-retrieve In-Reply-To: <6ad755d0-55b4-07fb-0bd6-4dd664839053@metacode.biz> References: <6ad755d0-55b4-07fb-0bd6-4dd664839053@metacode.biz> Message-ID: <43407069.SYQbWhqBlf@esus> Hi, On Sunday 30 June 2019 21:36:56 CEST Wiktor Kwapisiewicz via Gnupg-devel wrote: > The code checks first the keyserver and then the WKD domain. I guess > this is to limit the number of IP-leaking queries and prefer trusted > keyserver. I do not think that this is really the reason. As we have the fingerprint when we verify a signature it is more accurate to look for a key with that fingerprint on the keyserver instead of only matching the sender address with WKD. > I'm wondering if reversing the order (first WKD, then keyserver) > wouldn't be a better option. The current mechanism is not perfect, so > that the IP-leaking could still be triggered by attacker by using a > brand new key (that is not published on keyservers). I am fully with you. I've complained about this in the past, but It is not so important to me anymore because in GpgOL I no longer use "auto-key-retrieve" until I can show the unverified mail while the key is fetched. For me it is even more important because GpgOL assigns keys that were fetched through WKD some additional trust (Level 2) by using the key origin, because the mail domain owner asserted this key. So if you have a key both on the keyservers and WKD you will get a different trust level if you receive the key by verifying a mail or if you receive the key by a "locate-key" when entering the sender address. I thought we had an issue for that already but I did not find it. So i've cerated a new one. https://dev.gnupg.org/T4595 Best Regards, Andre -- GnuPG.com - a brand of g10 Code, the GnuPG experts. g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459 GF Werner Koch, USt-Id DE215605608, www.g10code.com. GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board at gnupg.org Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Jul 1 18:57:03 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Jul 2019 18:57:03 +0200 Subject: Stop-gap for signature flooded keys Message-ID: <87pnmtitgg.fsf@wheatstone.g10code.de> Hi! In case the problem with too many key signatures accidently retrieved from a keyserver or from elsewhere turns more virolent, the two attached patches might help. They should apply to 2.2.16 and allow to put --8<---------------cut here---------------start------------->8--- keyserver-options self-sigs-only --8<---------------cut here---------------end--------------->8--- into gpg.conf to skip all key-signatures at an early import stage. This will go into 2.2.17. We track this problem at https://dev.gnupg.org/T4591 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-Make-read_block-in-import.c-more-flexible.patch Type: text/x-diff Size: 2825 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-gpg-New-import-and-keyserver-option-self-sigs-only.patch Type: text/x-diff Size: 5143 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Jul 1 19:13:37 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 01 Jul 2019 13:13:37 -0400 Subject: Stop-gap for signature flooded keys In-Reply-To: <87pnmtitgg.fsf@wheatstone.g10code.de> References: <87pnmtitgg.fsf@wheatstone.g10code.de> Message-ID: <87h885oeym.fsf@fifthhorseman.net> On Mon 2019-07-01 18:57:03 +0200, Werner Koch via Gnupg-devel wrote: > into gpg.conf to skip all key-signatures at an early import stage. This > will go into 2.2.17. We track this problem at https://dev.gnupg.org/T4591 Thanks for taking the time to work on this, Werner. I don't think this is an appropriate fix, though. As I've commented on T4591, If i am going to tell anyone "hey, do this weird thing differently in order to fetch my key", i will tell them "pull it from https://dkg.fifthhorseman.net/dkg-openpgp.key". I will never tell anyone to use import-self-sigs-only. Not only that, but the current implementation of import-self-sigs-only also does not appear to be robust against a malicious certificate flood given SKS's lack of cryptographic validation. Adding a new option to an already-crowded space is not the right solution. The right solution is for gpg to be more defensive about the OpenPGP packets it receives, regardless of who it receives them from. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon Jul 1 19:29:39 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Jul 2019 19:29:39 +0200 Subject: Order of lookup methods in --auto-key-retrieve In-Reply-To: <6ad755d0-55b4-07fb-0bd6-4dd664839053@metacode.biz> (Wiktor Kwapisiewicz via Gnupg-devel's message of "Sun, 30 Jun 2019 21:36:56 +0200") References: <6ad755d0-55b4-07fb-0bd6-4dd664839053@metacode.biz> Message-ID: <87lfxhiry4.fsf@wheatstone.g10code.de> On Sun, 30 Jun 2019 21:36, gnupg-devel at gnupg.org said: > The code checks first the keyserver and then the WKD domain. I guess > this is to limit the number of IP-leaking queries and prefer trusted > keyserver. Right that was one idea. The other reason is that it is not possible to lookup a key from the WKD using a fingerprint. Before rfc-4880bis added the /Issuer Fingerprint/ to signatures we only had the /Issuer's User ID/ information in a signature to lookup a key. With 2.1.13 we added the latter to all signatures if possible so to make --auto-key-retrieve working. I guess we should keep this information to prefer updating via WKD. > I'm wondering if reversing the order (first WKD, then keyserver) > wouldn't be a better option. The current mechanism is not perfect, so Agreed. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wiktor at metacode.biz Mon Jul 1 22:41:12 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Mon, 1 Jul 2019 22:41:12 +0200 Subject: Order of lookup methods in --auto-key-retrieve In-Reply-To: <43407069.SYQbWhqBlf@esus> References: <6ad755d0-55b4-07fb-0bd6-4dd664839053@metacode.biz> <43407069.SYQbWhqBlf@esus> Message-ID: On 01.07.2019 09:14, Andre Heinecke wrote: > I thought we had an issue for that already but I did not find it. So i've > cerated a new one. https://dev.gnupg.org/T4595 Thank you Andre, also for adding me to subscribers. I'll follow it. On 01.07.2019 19:29, Werner Koch wrote: > Before rfc-4880bis added > the /Issuer Fingerprint/ to signatures we only had the /Issuer's User > ID/ information in a signature to lookup a key. Understood. For further context for people following this on the mailing list the Issuer User ID packet can be added to the signature by using `default-key e-mail at example.com` instead of hex fingerprint in gpg.conf (or using the respective command line options). (Some other apps such as OpenKeychain also insert this packet). Thank you both! Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Jul 2 08:40:20 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jul 2019 08:40:20 +0200 Subject: Use of --sender (was: Order of lookup methods in --auto-key-retrieve) In-Reply-To: (Wiktor Kwapisiewicz via Gnupg-devel's message of "Mon, 1 Jul 2019 22:41:12 +0200") References: <6ad755d0-55b4-07fb-0bd6-4dd664839053@metacode.biz> <43407069.SYQbWhqBlf@esus> Message-ID: <8736jphrcb.fsf_-_@wheatstone.g10code.de> On Mon, 1 Jul 2019 22:41, gnupg-devel at gnupg.org said: > gpg.conf (or using the respective command line options). (Some other Which is --sender MAILADDRESS In general MUAs should use the FROM address here because on mail verification MUAs will check that the FROM address matches one of the user ID iof the key and the Signer's User ID as set with the above command. GPGME users use /* Store a sender address in the context. */ gpgme_error_t gpgme_set_sender (gpgme_ctx_t ctx, const char *address); Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Jul 2 09:39:35 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jul 2019 09:39:35 +0200 Subject: Stop-gap for signature flooded keys In-Reply-To: <87pnmtitgg.fsf@wheatstone.g10code.de> (Werner Koch via Gnupg-devel's message of "Mon, 01 Jul 2019 18:57:03 +0200") References: <87pnmtitgg.fsf@wheatstone.g10code.de> Message-ID: <878stgholk.fsf@wheatstone.g10code.de> Hi! Here is another patch on top of the two I posted yesterday. This one implements a callback to the new option in the case the import failed. No need to set the option if you can live with the time it requires for the first time import of a flooded keyblock. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-gpg-Fallback-to-import-with-self-sigs-only-on-too-la.patch Type: text/x-diff Size: 8063 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wiktor at metacode.biz Tue Jul 2 10:08:55 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 2 Jul 2019 10:08:55 +0200 Subject: Use of --sender (was: Order of lookup methods in --auto-key-retrieve) In-Reply-To: <8736jphrcb.fsf_-_@wheatstone.g10code.de> References: <6ad755d0-55b4-07fb-0bd6-4dd664839053@metacode.biz> <43407069.SYQbWhqBlf@esus> <8736jphrcb.fsf_-_@wheatstone.g10code.de> Message-ID: <0b89bc4a-0313-2538-bae1-f168deb06180@metacode.biz> On 02.07.2019 08:40, Werner Koch wrote: > Which is > > --sender MAILADDRESS Oh, I was not aware of this one but it is very useful. I did ask Enigmail to use e-mail address as --local-user but they had a different idea: https://sourceforge.net/p/enigmail/forum/feature_requests/thread/a2a7dd87/ Adding --sender there could resolve my issue (adding Signer's UID packet) without changing their key selection logic. Thanks for the info! Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Jul 2 10:40:23 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 2 Jul 2019 10:40:23 +0200 Subject: Use of --sender (was: Order of lookup methods in --auto-key-retrieve) In-Reply-To: <0b89bc4a-0313-2538-bae1-f168deb06180@metacode.biz> References: <6ad755d0-55b4-07fb-0bd6-4dd664839053@metacode.biz> <43407069.SYQbWhqBlf@esus> <8736jphrcb.fsf_-_@wheatstone.g10code.de> <0b89bc4a-0313-2538-bae1-f168deb06180@metacode.biz> Message-ID: <91c3a82c-ffb3-fb49-838e-7794249e784c@digitalbrains.com> On 02/07/2019 10:08, Wiktor Kwapisiewicz via Gnupg-devel wrote: > Oh, I was not aware of this one but it is very useful. I'd like to suggest the attached patch to draw a bit more attention to this option. I stopped looking for the --sender option once the man page told me "this is only done with --local-user" :-). HTH, Peter. PS: I don't know why the line lengths for this paragraph were originally shorter; other lines in the same document seem longer. If I'm breaking some consistency I'm not aware of, the paragraph needs to be reflowed :-). -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Mention-sender-in-documentation.patch Type: text/x-patch Size: 1277 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Jul 2 13:34:55 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jul 2019 13:34:55 +0200 Subject: Use of --sender In-Reply-To: <91c3a82c-ffb3-fb49-838e-7794249e784c@digitalbrains.com> (Peter Lebbing's message of "Tue, 2 Jul 2019 10:40:23 +0200") References: <6ad755d0-55b4-07fb-0bd6-4dd664839053@metacode.biz> <43407069.SYQbWhqBlf@esus> <8736jphrcb.fsf_-_@wheatstone.g10code.de> <0b89bc4a-0313-2538-bae1-f168deb06180@metacode.biz> <91c3a82c-ffb3-fb49-838e-7794249e784c@digitalbrains.com> Message-ID: <87d0isfz4w.fsf@wheatstone.g10code.de> On Tue, 2 Jul 2019 10:40, peter at digitalbrains.com said: > I'd like to suggest the attached patch to draw a bit more attention to > this option. I stopped looking for the --sender option once the man page Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Fri Jul 5 17:15:12 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Jul 2019 17:15:12 +0200 Subject: Release candidate for 2.2.17 Message-ID: <875zogms1r.fsf@wheatstone.g10code.de> Hi! Due to the SKS keyserver problems we are planning a new release for the next week. That release will have some changes related to keyserver. See below for details. In general we do not provide release candidates because experience showed that they are more or less ignored. However, this time I would like to you to give that version some testing. Get it from and in case of problems please report to gnupg-devel. Here are the changes: * gpg: Ignore all key-signatures received from keyservers. This change is required to mitigate a DoS due to keys flooded with faked key-signatures. The old behaviour can be achieved by adding keyserver-options no-self-sigs-only,no-import-clean to your gpg.conf. [#4607] * gpg: If an imported keyblocks is too large to be stored in the keybox (pubring.kbx) do not error out but fallback to an import using the options "self-sigs-only,import-clean". [#4591] * gpg: New command --locate-external-key which can be used to refresh keys from the Web Key Directory or via other methods configured with --auto-key-locate. * gpg: New import option "self-sigs-only". * gpg: In --auto-key-retrieve prefer WKD over keyservers. [#4595] * dirmngr: Support the "openpgpkey" subdomain feature from draft-koch-openpgp-webkey-service-07. [#4590]. * dirmngr: Add an exception for the "openpgpkey" subdomain to the CSRF protection. [#4603] * dirmngr: Fix endless loop due to http errors 503 and 504. [#4600] * dirmngr: Fix TLS bug during redirection of HKP requests. [#4566] * gpgconf: Fix a race condition when killing components. [#4577] Release-info: https://dev.gnupg.org/T4606 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gnupg-devel at spodhuis.org Mon Jul 8 08:28:10 2019 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Mon, 8 Jul 2019 02:28:10 -0400 Subject: Release candidate for 2.2.17 In-Reply-To: <875zogms1r.fsf@wheatstone.g10code.de> References: <875zogms1r.fsf@wheatstone.g10code.de> Message-ID: <20190708062809.GA30324@breadbox.private.spodhuis.org> On 2019-07-05 at 17:15 +0200, Werner Koch via Gnupg-devel wrote: > In general we do not provide release candidates because experience > showed that they are more or less ignored. However, this time I would > like to you to give that version some testing. Get it from Looks like importing multiple keys at once from --search-keys has broken. I don't know if this is behaviour which you still want to support. gpg --search-keys ${my_first_name_as_above}@pennock-tech.com # sorry for obfuscation; darned spammers If I try to import all three keys which I currently see, then it works under 2.2.16 but not under 2.2.17-beta21. I just enter >> 1 2 3 << and hit enter. That used to work. The keys are: ACBB4324393ADE3515DA2DDA4D1E900E14C1CC04 AB882DD64035A24758F69688D231BDA6A79FCEE0 F5AE6DEAA11037B7E652718D081969BAB569CCB2 -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 996 bytes Desc: Digital signature URL: From gnupg-devel at spodhuis.org Mon Jul 8 08:47:03 2019 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Mon, 8 Jul 2019 02:47:03 -0400 Subject: Release candidate for 2.2.17 In-Reply-To: <20190708062809.GA30324@breadbox.private.spodhuis.org> References: <875zogms1r.fsf@wheatstone.g10code.de> <20190708062809.GA30324@breadbox.private.spodhuis.org> Message-ID: <20190708064703.GA30543@breadbox.private.spodhuis.org> On 2019-07-08 at 02:28 -0400, Phil Pennock wrote: > On 2019-07-05 at 17:15 +0200, Werner Koch via Gnupg-devel wrote: > > In general we do not provide release candidates because experience > > showed that they are more or less ignored. However, this time I would > > like to you to give that version some testing. Get it from > > Looks like importing multiple keys at once from --search-keys has > broken. I don't know if this is behaviour which you still want to > support. Please forgive the very poor bug-report. (I should have been in bed hours ago, that's my only excuse). By "broken" I mean that only one of the three imports: Keys 1-3 of 3 for "...". Enter number(s), N)ext, or Q)uit > 1 2 3 gpg: key 4D1E900E14C1CC04: 1 duplicate signature removed gpg: key 4D1E900E14C1CC04: 1 signature reordered gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key 4D1E900E14C1CC04: public key "Phil Pennock <...>" imported gpg: key D231BDA6A79FCEE0: no valid user IDs gpg: this may be caused by a missing self-signature gpg: key 081969BAB569CCB2: no valid user IDs gpg: this may be caused by a missing self-signature gpg: Total number processed: 3 gpg: w/o user IDs: 2 gpg: imported: 1 However, if I instead invoke the command three times, each time selecting one of the keys, then each imports correctly. It's only when I try to import multiple keys at once that GnuPG decides that ... "all keys but the last one" (?) are missing a self-signature. There, I hope that's a bit more useful. -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 996 bytes Desc: Digital signature URL: From gnupg-devel at spodhuis.org Tue Jul 9 05:08:57 2019 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Mon, 8 Jul 2019 23:08:57 -0400 Subject: webkey service: caching/robot policy statements? Message-ID: <20190709030856.GA3631@spodhuis.org> Folks, In draft-koch-openpgp-webkey-service-08 section 4.5, policy flags, the use of WELLKNOWN/policy is defined, with an extension mechanism. Does this seem a reasonable location for a "caching keyserver" to check for directives on policy controls, too? Something like (assuming standardized, which is absolutely not appropriate yet): cache-policy: prohibited or: cache-policy: min-refresh-interval=2d ? Also, to double-check: the local use extension would be: pennock.tech_cache-policy: ? I'm going to risk descending into bikeshedding here because that feels so unusual. Rather than a whole new syntax, the two most obvious alternatives are: 1. Use an `@` as per RFC4880 notation data, or the SSH protocol, thus: cache-policy at pennock.tech: min-refresh-interval=2d 2. Use reversed domain syntax, per Java, thus: tech.pennock.cache-policy: min-refresh-interval=2d And to re-emphasize: I don't want cache-policy added yet, I'm still sketching out the rough ideas in my head, I'm mostly checking if the policy file could be for more than submission controls without having people scream at me, and if I have the extension syntax right. Thanks, -Phil From wk at gnupg.org Tue Jul 9 11:30:02 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Jul 2019 11:30:02 +0200 Subject: Release candidate for 2.2.17 In-Reply-To: <20190708062809.GA30324@breadbox.private.spodhuis.org> (Phil Pennock via Gnupg-devel's message of "Mon, 8 Jul 2019 02:28:10 -0400") References: <875zogms1r.fsf@wheatstone.g10code.de> <20190708062809.GA30324@breadbox.private.spodhuis.org> Message-ID: <87d0ijk12d.fsf@wheatstone.g10code.de> On Mon, 8 Jul 2019 02:28, gnupg-devel at gnupg.org said: > If I try to import all three keys which I currently see, then it works > under 2.2.16 but not under 2.2.17-beta21. Thanks for the report. I found and fix the bug which was related to the early dropping of self-signatures. A variable with the keyid for comparison was not initialized in all cases. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bernhard at intevation.de Tue Jul 9 11:50:36 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 9 Jul 2019 11:50:36 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" (was: Launching a new keyserver on keys.openpgp.org!) In-Reply-To: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> Message-ID: <201907091150.44819.bernhard@intevation.de> Hello friends of GnuPG! Am Mittwoch 12 Juni 2019 18:53:50 schrieb Vincent Breitmoser: > the Hagrid team is pleased to announce the launch of our new keyserver, > running at keys.openpgp.org! It is good to see new code for distributing pubkeys for OpenPGP in general. Hagrid's design decisions seems to aim towards preserving privacy by requiring a confirmation before personal data is published. This is much like the General Data Protection Regulation (GDPR). > * Identities are only published with consent, while > non-identity information is freely distributed. > * Deletable. Users can delete personal information with a simple e-mail > confirmation. And a simple implementation of this would make the service central, inheriting the drawbacks of a validating, central keyserver. "Central" in the meaning that one place decides if a user id of a pubkey (and the pubkey itself) is made available or not. Another drawback as far as I can see is limiting the IDs that can be published towards email addresses, which makes it harder for non-email use cases of OpenPGP. Can we write a keyserver-software that avoid these two drawbacks? What about the following idea: == A permission recording keyserver === Ask for permission to publish once A keyserver records where it got the user id from. If it is uploaded, and the id contains personal data, it knows which person's data it is, thus this person can be asked for permission. Example, there is an email address in the id. Thus an email can be send to confirm the intend of the person to publish the pubkey. This permission is recorded. In the other case a keyserver gets a key and uid from a different server and records from which one. It is avoided that each independent keyserver has to ask again. Now if someone complains, a server operator can either point to the other keyserver or the permission they have recorded themselfs. === Record deletions If someone requests a deletion (which means this person can prove that it is there personal data), this is also recorded, only by key number, so this can also be synced with other keyservers. This way we can have independent keyservers, and it is clear that the network in non-validating as a rouge keyserver may claim to have recorded permissions or deletions. However if a keyserver does real malice, it will get pointed to and is liable. It may also be blocked. === Non-email ids If the iid does not contain an email address, it may or may not be data that is personal. Example: "bernhard at intevation dot de" has personal data. Example: "Zilkin 2019-ahex" does not. The server can publish it preliminary, until someone complains and then we either adapt the detection algorithm, record a deletion for the pubkey or manually trigger the permission request. Someone who claims that this is their personal data, will have to do this with contact information and an understandable explanation why this is personal data. In the beginning there maybe some interesting encodings and manual cases to consider, but after a short while the detection algorithms will catching most encodings. === How about the GDPR? This idea accepts the assumption that we really need approval for publishing an id that contains personal data (aka opt-in). Especially that the EU GDPR actually is applicable in this case. I'm not sure if this is the case. What I am quite sure about is that searching for an email address is okay, if the search engine as recorded the information from a place where the permission can be safely assumed, for example from a personal homepage in the web. So once there is a chain of responsibility that can be followed in exceptional cases, this is fine as the rights of users are honored. == Conclusion While this is just an idea, yet, it seems possible to keep a searchable public and independently federated directory of pubkeys by design. Maybe hagrid can be used as basis for such an implementation. Whether such a directly is useful as an addition to WKD in the long run is not discussed. And tthe recent attack on the SKS keyserver network should not put pressure on this important discussion, in my opinion. Best Regards, Bernhard ps.: Dominik and Andre are getting a copy, because I have voiced that idea to them on the phone in the last days. You do not need to include them in follow-ups. pps.: I was unable to read all the writings about the hagrid approach so far. These days I need good, balances summaries to get on speed on some debates. However got the impression that the idea is interesting enough to be written down rather sooner than later. -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Jul 9 11:31:41 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 9 Jul 2019 11:31:41 +0200 Subject: webkey service: caching/robot policy statements? In-Reply-To: <20190709030856.GA3631@spodhuis.org> References: <20190709030856.GA3631@spodhuis.org> Message-ID: <201907091131.41683.bernhard@intevation.de> Am Dienstag 09 Juli 2019 05:08:57 schrieb Phil Pennock via Gnupg-devel: > Does this seem a reasonable location for a "caching keyserver" to check > for directives on policy controls, too? What is a "caching keyserver" in this context? What purpose would it serve? A WKD request would only be served by the TLS certificate of the webserver of the original domain. This cannot be cached, otherwise the check would not be working. Also, a third party server would not know the email address to ask for. (Unless given by some application.) So why would this application prefer the third party server when it could ask the real WKD server? Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Tue Jul 9 13:14:19 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 9 Jul 2019 12:14:19 +0100 Subject: webkey service: caching/robot policy statements? In-Reply-To: <201907091131.41683.bernhard@intevation.de> References: <20190709030856.GA3631@spodhuis.org> <201907091131.41683.bernhard@intevation.de> Message-ID: <62466b9a-1906-fe65-fab4-93c461e4ec3c@andrewg.com> On 09/07/2019 10:31, Bernhard Reiter wrote: > What is a "caching keyserver" in this context? > What purpose would it serve? See https://lists.gnupg.org/pipermail/gnupg-users/2019-July/062151.html - this is also of relevance to your previous post. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Tue Jul 9 13:59:09 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 9 Jul 2019 13:59:09 +0200 Subject: Launching a new keyserver on keys.openpgp.org! In-Reply-To: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> Message-ID: <201907091359.15794.bernhard@intevation.de> Dear Hagrid Team, Am Mittwoch 12 Juni 2019 18:53:50 schrieb Vincent Breitmoser: > the Hagrid team is pleased to announce the launch of our new keyserver, > running at keys.openpgp.org! [..] > https://keys.openpgp.org/about/news#2019-06-12-launch [..] > Some of the things we do are a bit experimental. For some things we found > that there is no good mechanism at this point, so we decided to drop them > for now. it is good to see more code around OpenPGP. Maybe hagrid can be useful to improve the common infrastructure to distribute public keys in the future. From my point of view the service announcement and its description is a bit problematic, though: The choice of keys.openpgp.org let people assume that there is a larger consensus in the OpenPGP world about hagrid. While from my point of view some approaches are still controversial. The announcement and domain name portraits the service as an "OpenPGP keyserver" while at least with the distribution of pubkeys without user id it is not in compliance with RFC4880. But he annoumcement makes it sound like this is a defect with GnuPG. A clearer phrasing would have pointed this out: GnuPG behaves according to the current standard from which we deviate (for a reason.) Hagrid uses an OpenPGP implementation which describes itself as "few to no" products using it "not a lot of experience with it in the wild". So it is experimental, just like you write here, but not in the official announcement. People even further aways may have assumed that hagrid is an offering like the old keyservers which means carrying third party signatures. The timing of the announcement here works against hagrid as the attacks of the SKS keyserver network have recently become public close to the time of the hagrid announcement. Because being close in timing, people may assume some correlation. Are you aware of any correlation? (Like you have accellerated the announcement after you have learned about the attacks.) Hopefully some of the descriptions can be improved. Though the press has already picked up on some of the points. Technically I believe that it is possible to preserve the current idea of a keyserver to make it privacy aware, but still decentral and non-validating while still transporting third party signatures and several keys for an email address. I'll outline this in other emails to gnupg-devel at . If hagrid could be turned into a more robust replacement for the current keyserver software, to me it would be a useful addition. Sincerely, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From dirk.gottschalk1980 at googlemail.com Tue Jul 9 14:13:36 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 09 Jul 2019 14:13:36 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" (was: Launching a new keyserver on keys.openpgp.org!) In-Reply-To: <201907091150.44819.bernhard@intevation.de> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> Message-ID: <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> Hello. Am Dienstag, den 09.07.2019, 11:50 +0200 schrieb Bernhard Reiter: > Hello friends of GnuPG! > Am Mittwoch 12 Juni 2019 18:53:50 schrieb Vincent Breitmoser: > > the Hagrid team is pleased to announce the launch of our new > > keyserver, running at keys.openpgp.org! > > * Identities are only published with consent, while > > non-identity information is freely distributed. > > * Deletable. Users can delete personal information with a simple e- > > mail confirmation. > And a simple implementation of this would make the service central, > inheriting the drawbacks of a validating, central keyserver. > "Central" in the meaning that one place decides if a user id of a > pubkey (and the pubkey itself) is made available or not. And central in the meaning of standing alone. :/ > Another drawback as far as I can see is limiting the IDs that can be > published towards email addresses, which makes it harder for non- > email use cases of OpenPGP. Right. > Can we write a keyserver-software that avoid these two drawbacks? With Obama's words: Yes, we can! I am thinking abour writing a new distributed key server now for a few days. In my case, just for a company in house solution, but it would be interwsting to make it a public solution. Respecting the GDPR was out of scope in my case, but let's simply discuss, if you wish. > What about the following idea: > == A permission recording keyserver > === Ask for permission to publish once > A keyserver records where it got the user id from. > If it is uploaded, and the id contains personal data, it knows which > person's data it is, thus this person can be asked for permission. > Example, there is an email address in the id. Thus an email can be > send to confirm the intend of the person to publish the pubkey. This > permission is recorded. > In the other case a keyserver gets a key and uid from a different > server and records from which one. It is avoided that each > independent keyserver has to ask again. On sync, the key has just to be flagged if it is privacy protected, or if it's IDs can be delivered. Yeah, that's a ghood point. > Now if someone complains, a server operator can either point to the > other keyserver or the permission they have recorded themselfs. This could also be done while syncing. Just changing the Flag for KEy 0xABCDEF > === Record deletions > If someone requests a deletion (which means this person can prove > that it is there personal data), this is also recorded, only by key > number, so this can also be synced with other keyservers. Sure, technically not a big thing. > This way we can have independent keyservers, and it is clear that the > network in non-validating as a rouge keyserver may claim to have > recorded permissions or deletions. However if a keyserver does real > malice, it will get pointed to and is liable. It may also be blocked. Exactly my thoughts. I have some thoughts about how to realize such a server, a little mir in Detail. I would like to discuss them, are you interested? Would thos be okay here on the list? > === Non-email ids > If the iid does not contain an email address, it may or may not be > data that is personal. Example: "bernhard at intevation dot de" has > personal data. Example: "Zilkin 2019-ahex" does not. > The server can publish it preliminary, until someone complains and > then we either adapt the detection algorithm, record a deletion for > the pubkey or manually trigger the permission request. > Someone who claims that this is their personal data, will have to do > this with contact information and an understandable explanation why > this is personal data. In the beginning there maybe some interesting > encodings and manual cases to consider, but after a short while the > detection algorithms will catching most encodings. > === How about the GDPR? > This idea accepts the assumption that we really need approval for > publishing an id that contains personal data (aka opt-in). Especially > that the EU GDPR actually is applicable in this case. I'm not sure > if this is the case. > What I am quite sure about is that searching for an email address is > okay, if the search engine as recorded the information from a place > where the permission can be safely assumed, for example from a > personal homepage in the web. So once there is a chain of > responsibility that can be followed in exceptional cases, this is > fine as the rights of users are honored. That'S what I think to. We could even take the upload as implicated consent on the legal state. But, the possibility to share keys without UIDs is in some ways a good one. So you can habe ID-less keys for automated operations where you don't need the UIDs. By the way, is there a way to generate keys with GPG without UIDs? I tried, but I failed. Did I oversee an CLI option to do this? > == Conclusion > While this is just an idea, yet, it seems possible to keep a > searchable public and independently federated directory of pubkeys by > design. Maybe hagrid can be used as basis for such an implementation. My approach would be different. Not using Hagrid. But that's another story. > Whether such a directly is useful as an addition to WKD in the long > run is not discussed. And tthe recent attack on the SKS keyserver > network should not put pressure on this important discussion, in my > opinion. WKD is in some Cases kind of problematic. Think about users of gmail, like me, they don't offer WKD at all. So, a second system is nice to have. Just a few lines Background: I work in some company projects, where other companies are involved now. Until then, we propagated the keys we use over DNS as CERT RRs.in our internal DNS-Server. Now this is no longer an options. Relying hardly on PGP for many purposes and usecases, we need a new way to propagate keys and sync them with the other companies. LDAP would be an option, but making them public available is not a good idea in aur eyes. A VPN is also out of question for some reasons, even it would avoid the DNS-Problem. If somebody wishes to get further details on my theoretical plans or to discuss the whole thing from another side, I'm open to discussion. Kind regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From dirk.gottschalk1980 at googlemail.com Tue Jul 9 14:31:58 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 09 Jul 2019 14:31:58 +0200 Subject: Launching a new keyserver on keys.openpgp.org! In-Reply-To: <201907091359.15794.bernhard@intevation.de> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091359.15794.bernhard@intevation.de> Message-ID: Hi. Am Dienstag, den 09.07.2019, 13:59 +0200 schrieb Bernhard Reiter: > Dear Hagrid Team, > > Am Mittwoch 12 Juni 2019 18:53:50 schrieb Vincent Breitmoser: > > the Hagrid team is pleased to announce the launch of our new > > keyserver, > > running at keys.openpgp.org! > > [..] > > https://keys.openpgp.org/about/news#2019-06-12-launch > [..] > > > Some of the things we do are a bit experimental. For some things we > > found > > that there is no good mechanism at this point, so we decided to > > drop them > > for now. > > it is good to see more code around OpenPGP. > Maybe hagrid can be useful to improve the common infrastructure to > distribute public keys in the future. > > From my point of view the service announcement and its description > is a bit problematic, though: [snip] I fully agree with Bernhard. And I, for myself, think that stri??ing off third party signatures is a bad idea as well. It should be possible to implement some kind of validation for them. Another way could be to make only signatures from keys which are already on the server available. Something like "import-clean" does on import. This would avoid flooded keys. It could also be possible to filter out double signatures which are made unintented. So it happened to me with key of Werner a while ago. Sorry for this, Werner, something went wrong. The other pint is, the hkp protocol should be expanded to some kind of authentication, so only the owner can upload and update a key. The hagrid approach, which forces people to upload the keys via web, as far as I could look into it, is a bad solution for automatic systems. Yes, I know, they offer some kind of Api for this, but it doesn't work just utilizing gpg itself, as far as I can tell at this moment. I tested the new server and it works. It's not a bad solution, but I am missing some functions. I think we should not only touch the server side. We should improve both sides, or in other words the underlying protocol. I know, all People involved in GnuPG have enough work to do. I am willing to help where I can. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From bernhard at intevation.de Tue Jul 9 14:36:39 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 9 Jul 2019 14:36:39 +0200 Subject: Preserving third party signatures distribution (was: Launching a new keyserver on keys.openpgp.org!) In-Reply-To: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> Message-ID: <201907091436.52907.bernhard@intevation.de> Hello friends of GnuPG! > the Hagrid team is pleased to announce the launch of our new keyserver, In this post an idea is outlined to preserve the common infrastructure of distributing third party signatures. (It is related to my post about 'Preserving non-central and privacy with a "permission recording keyserver"'.) Can we build up a keyserver infrastructure, without central control, but where spam is kept at bay? What about: == Some accountability, like email With email there is a spam problem, but email still works and is decentralized. Usually email is accepted from all domains and servers (adhering to some rules.) More generally speaking it is a common infrastructure. And this has to be defended against attacks, which happens via blacklists and even legal or police actions in case of email. For this to work for third party signature, we'd need some trails of the data and some responsibility. This seems possible - as with email. Though it means some work operating the keyserver network. A server can record where the third pary signature came from, either an upload or a different keyserver; and when. And then it can limit the number of third party signatures carried for one pubkey. == Order more important information Towards the limit of carried information about a pubkey, the most important information should be delivered first, this means pubkey itself, revocation information, self-signed user ids. And then third pary signatures that have been authorised by the key owner (by a signature) and the remaining ones ordered in time that the keyserver has seen them. So if flooding is attempted, it will only affect the remaining space for additional pubkey information, but the important stuff is delivered first. This avoids a denial of service attack. == Occasionally record preference of third party signatures by key owner If we have a network of permission recording keyservers, only one of them occasionally would need to receive a permission of the key owner to carry the third party signature. The others will just see the signature on the third party keys. The limit is not a problem, if no attack is tried. Often there will be enough old third party signature for the system to work. If an attack occurs and third party signatures are a problem, a key owner may # request a higher limit # request that some signatures are not being carried (by pattern or id) # sign some third party keys However this is only necessary in case of attacks. It is additional information in other cases, so it does not pose much work on the user (clients). == No motivation for attacks If there is a limit and an order for the distributed third party signatures, the motivation of attackers are lower, as people can defend themselfs and they are unable to interrupt the exchange of relevant third party keys. (Also I wonder what the motivation of the current attacks is.) == Context This does not discuss if having third party information outside of WKD repositories is useful in the long-term. The approach only tries to make technically possible what a significant number of people is using today and some consider useful to have. Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Tue Jul 9 14:44:16 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 9 Jul 2019 13:44:16 +0100 Subject: Launching a new keyserver on keys.openpgp.org! In-Reply-To: References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091359.15794.bernhard@intevation.de> Message-ID: On 09/07/2019 13:31, Dirk Gottschalk via Gnupg-devel wrote: > The other pint is, the hkp protocol should be expanded to some kind of > authentication, so only the owner can upload and update a key. No need to change the protocol. Just store unvalidated uploads in a holding area pending confirmation via the email(s) in the user ID packet(s). Same way we sign people up to this mailing list, in fact. :-) -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Tue Jul 9 14:51:43 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 9 Jul 2019 14:51:43 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> Message-ID: <201907091451.48768.bernhard@intevation.de> Dirk, Am Dienstag 09 Juli 2019 14:13:36 schrieb Dirk Gottschalk via Gnupg-devel: > Am Dienstag, den 09.07.2019, 11:50 +0200 schrieb Bernhard Reiter: > I am thinking abour writing a new distributed key server now for a few > days. the attack on the existing SKS keyservers show that we need a software improvement. (I haven't looked at the existing solution, so I don't know if a fresh implementation is an advantage or not.) > In my case, just for a company in house solution, but it would be > interwsting to make it a public solution. There is probably some extra work involved to make it a more general solution, but it maybe even good for the company you are working for in the mid term. (Better tested software, more ideas, more compatibility and maybe even shared maintenance costs in the long term.) > Respecting the GDPR was out of scope in my case, but let's simply discuss, > if you wish. To me it is useful to think about what happens if there is illegal contents in the user ids, which includes personal data without permission. This could also happen in-house, so the ability to somehow "filter" this maybe even necessary in-house. > I have some thoughts about how to realize such a > server, a little mir in Detail. I would like to discuss them, are you > interested? Would thos be okay here on the list? In my understanding it is fine to discuss this on the list. If the volume of messages becomes too large, a different channel can be used. E.g. wiki.gnupg.org could be used to write down arguments and research results. Personally would be interested but I may not have much time to particiate much. You know it is summer holiday period here in Germany. My main point is that it is possible to do. > We could even take the upload as implicated > consent on the legal state. Probably not, because somebody else may just create a key with a user id that contains personal data of a different person. > But, the possibility to share keys without > UIDs is in some ways a good one. So you can habe ID-less keys for > automated operations where you don't need the UIDs. By the way, is > there a way to generate keys with GPG without UIDs? I tried, but I > failed. Did I oversee an CLI option to do this? I don't know. It does not seems to be forseen in RFC4880 and other common OpenPGP implementations. And with lots of stable GnuPG revisions out there in production and OpenPGP implementations for interoperability, it does not seem to be a short term solution. > WKD is in some Cases kind of problematic. Think about users of gmail, > like me, they don't offer WKD at all. So, a second system is nice to > have. I agree that is is nice to have second system, if just to provide history data and revocation or rollout information if an email provider completely drops out. On the gmail case I can only suggest to use an email provider that is more privacy aware and supports WKD. (>;)) No seriously gmail my offer WKD some day, if this is the standard emails users demand. > Just a few lines Background: I work in some company projects, where > other companies are involved now. Until then, we propagated the keys we > use over DNS as CERT RRs.in our internal DNS-Server. Now this is no > longer an options. But why not WKD? Do you require to transport a group of pubkeys? Then I'd suggest a https file. Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From dirk.gottschalk1980 at googlemail.com Tue Jul 9 14:54:50 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 09 Jul 2019 14:54:50 +0200 Subject: Launching a new keyserver on keys.openpgp.org! In-Reply-To: <6df86906ad976ef31f1bc1566551bc8a286442f3.camel@gentoo.org> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091359.15794.bernhard@intevation.de> <6df86906ad976ef31f1bc1566551bc8a286442f3.camel@gentoo.org> Message-ID: Am Dienstag, den 09.07.2019, 14:40 +0200 schrieb Micha? G?rny: > On Tue, 2019-07-09 at 14:31 +0200, Dirk Gottschalk via Gnupg-devel > wrote: > > Hi. > > > > Am Dienstag, den 09.07.2019, 13:59 +0200 schrieb Bernhard Reiter: > > > Dear Hagrid Team, > > > > > > Am Mittwoch 12 Juni 2019 18:53:50 schrieb Vincent Breitmoser: > > > > the Hagrid team is pleased to announce the launch of our new > > > > keyserver, > > > > running at keys.openpgp.org! > > > > > > [..] > > > > https://keys.openpgp.org/about/news#2019-06-12-launch > > > [..] > > > > > > > Some of the things we do are a bit experimental. For some > > > > things we > > > > found > > > > that there is no good mechanism at this point, so we decided to > > > > drop them > > > > for now. > > > > > > it is good to see more code around OpenPGP. > > > Maybe hagrid can be useful to improve the common infrastructure > > > to > > > distribute public keys in the future. > > > > > > From my point of view the service announcement and its > > > description > > > is a bit problematic, though: > > > > [snip] > > > > I fully agree with Bernhard. And I, for myself, think that > > stri??ing > > off third party signatures is a bad idea as well. It should be > > possible > > to implement some kind of validation for them. Another way could be > > to > > make only signatures from keys which are already on the server > > available. Something like "import-clean" does on import. This would > > avoid flooded keys. > It could be trivially worked around via uploading the flooding keys > to the server. After all, it accepts *all* keys, only UIDs it > restricts. It could be done by cleaning the keys after recieving. At first there surely will only a few signatures be shown, but with a growing database, it would be a good idea. It would be possible to preseed the database with the strong set, or with other well known clean keys. > > The other pint is, the hkp protocol should be expanded to some kind > > of authentication, so only the owner can upload and update a key. > > The hagrid approach, which forces people to upload the keys via > > web, as far as I could look into it, is a bad solution for > > automatic systems. > > Yes, I know, they offer some kind of Api for this, but it doesn't > > work just utilizing gpg itself, as far as I can tell at this > > moment. > This presumes you can trust the server, and therefore solves only > half of the problem. If the server eventually becomes distributed, > you would also need to authorize cross-server exchanges. This still > could be done via hacking on HKP but in the end I think it's > preferable to store the permission on the key somewhere, so that end > users can also benefit from it. That could be one was. On the other hand, there is no need f?r the sync to also use HKP. There are other options to sync the database. And I prefer the decentralized approach, so decentralized servers are mandatory. Permission? I think you are talking about the permission to distribute the UID. That doesn't need to be stored in the key and it should not be. Assuming the recipient knows who he is talking to and has recieved the complete key directly from the sender, is there any nead for the recipient to know that the sender doesn't want his UID to be leaked on the servers? This could lead to wrong assumptions on the recipients side. Regards,# Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mgorny at gentoo.org Tue Jul 9 14:40:18 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Tue, 09 Jul 2019 14:40:18 +0200 Subject: Launching a new keyserver on keys.openpgp.org! In-Reply-To: References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091359.15794.bernhard@intevation.de> Message-ID: <6df86906ad976ef31f1bc1566551bc8a286442f3.camel@gentoo.org> On Tue, 2019-07-09 at 14:31 +0200, Dirk Gottschalk via Gnupg-devel wrote: > Hi. > > Am Dienstag, den 09.07.2019, 13:59 +0200 schrieb Bernhard Reiter: > > Dear Hagrid Team, > > > > Am Mittwoch 12 Juni 2019 18:53:50 schrieb Vincent Breitmoser: > > > the Hagrid team is pleased to announce the launch of our new > > > keyserver, > > > running at keys.openpgp.org! > > > > [..] > > > https://keys.openpgp.org/about/news#2019-06-12-launch > > [..] > > > > > Some of the things we do are a bit experimental. For some things we > > > found > > > that there is no good mechanism at this point, so we decided to > > > drop them > > > for now. > > > > it is good to see more code around OpenPGP. > > Maybe hagrid can be useful to improve the common infrastructure to > > distribute public keys in the future. > > > > From my point of view the service announcement and its description > > is a bit problematic, though: > > [snip] > > I fully agree with Bernhard. And I, for myself, think that stri??ing > off third party signatures is a bad idea as well. It should be possible > to implement some kind of validation for them. Another way could be to > make only signatures from keys which are already on the server > available. Something like "import-clean" does on import. This would > avoid flooded keys. It could be trivially worked around via uploading the flooding keys to the server. After all, it accepts *all* keys, only UIDs it restricts. > The other pint is, the hkp protocol should be expanded to some kind of > authentication, so only the owner can upload and update a key. The > hagrid approach, which forces people to upload the keys via web, as far > as I could look into it, is a bad solution for automatic systems. Yes, > I know, they offer some kind of Api for this, but it doesn't work just > utilizing gpg itself, as far as I can tell at this moment. This presumes you can trust the server, and therefore solves only half of the problem. If the server eventually becomes distributed, you would also need to authorize cross-server exchanges. This still could be done via hacking on HKP but in the end I think it's preferable to store the permission on the key somewhere, so that end users can also benefit from it. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From mgorny at gentoo.org Tue Jul 9 14:37:05 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Tue, 09 Jul 2019 14:37:05 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" (was: Launching a new keyserver on keys.openpgp.org!) In-Reply-To: <201907091150.44819.bernhard@intevation.de> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> Message-ID: <0ad6850a6cd807f2e2e1903cd04d7b2b803a960b.camel@gentoo.org> On Tue, 2019-07-09 at 11:50 +0200, Bernhard Reiter wrote: > == A permission recording keyserver > > === Ask for permission to publish once > A keyserver records where it got the user id from. > If it is uploaded, and the id contains personal data, it knows which person's > data it is, thus this person can be asked for permission. > Example, there is an email address in the id. Thus an email can be send to > confirm the intend of the person to publish the pubkey. This permission is > recorded. In my opinion, the whole e-mail hassle is unnecessary, and could be resolved with appropriate privacy policy. If someone decides to upload the key with his own personal data on it, then that someone obviously agrees with the personal data being shared. As long as he can get that data removed afterwards, there shouldn't be a problem with that. That said, of course somebody could upload a key with your data without your permission. However, somebody can also upload an UID with your PII on it (name, even address, etc.) and some other e-mail address. E-mail verification does not really solve the problem, and I think it's reasonable to assume goodwill and handle abuse directly. > > === Record deletions > If someone requests a deletion (which means this person can prove that it is > there personal data), this is also recorded, only by key number, so this can > also be synced with other keyservers. That generally makes sense. Of course, the major problem is how to prove. You want to avoid abuse, e.g. when someone with coincidentally the same name (or fake documents) tries to delete somebody else's key. You probably should also have a way to revert the deletion requests. > === Non-email ids > If the iid does not contain an email address, it may or may not be data that > is personal. Example: "bernhard at intevation dot de" has personal data. > Example: "Zilkin 2019-ahex" does not. > The server can publish it preliminary, until someone complains and then > we either adapt the detection algorithm, record a deletion for the pubkey or > manually trigger the permission request. See above. I agree with the idea of publishing by default. If we really can't live with that, I think it would be reasonable to require only one verified e-mail (as statement of consent), and allow other UIDs on the same key by default. Detection algorithms make little sense. Do you really want to have different rules for people with common names, and with uncommon names? How are you going to detect people on photo IDs? -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From dirk.gottschalk1980 at googlemail.com Tue Jul 9 15:55:07 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 09 Jul 2019 15:55:07 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <201907091451.48768.bernhard@intevation.de> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> <201907091451.48768.bernhard@intevation.de> Message-ID: Hello Bernhard. Am Dienstag, den 09.07.2019, 14:51 +0200 schrieb Bernhard Reiter: > Dirk, > Am Dienstag 09 Juli 2019 14:13:36 schrieb Dirk Gottschalk via Gnupg- > devel: > > Am Dienstag, den 09.07.2019, 11:50 +0200 schrieb Bernhard Reiter: > > I am thinking abour writing a new distributed key server now for a > > few > > days. > the attack on the existing SKS keyservers show that we need a > software improvement. (I haven't looked at the existing solution, so > I don't know if a fresh implementation is an advantage or not.) That would have to be checked. It's just a theorethical thing in my head right now. > > In my case, just for a company in house solution, but it would be > > interwsting to make it a public solution. > There is probably some extra work involved to make it a more general > solution, but it maybe even good for the company you are working for > in the mid term. > (Better tested software, more ideas, more compatibility and maybe > even shared maintenance costs in the long term.) Yes, that's what I had in mind. > > Respecting the GDPR was out of scope in my case, but let's simply > > discuss, if you wish. > To me it is useful to think about what happens if there is illegal > contents in the user ids, which includes personal data without > permission. This could also happen in-house, so the ability to > somehow "filter" this maybe even necessary in-house. A warning and a clause in terms that state "By uploading your key..." which has to be accepted is sufficient by german law. But stripping the UIDs also has some efforts. Hard decision. But nothing stands again implementing both solutions. > > I have some thoughts about how to realize such a > > server, a little mir in Detail. I would like to discuss them, are > > you interested? Would thos be okay here on the list? > In my understanding it is fine to discuss this on the list. If the > volume of messages becomes too large, a different channel can be > used. E.g. wiki.gnupg.org could be used to write down arguments and > research results. > Personally would be interested but I may not have much time to > particiate > much. You know it is summer holiday period here in Germany. > My main point is that it is possible to do. Yes, I know, holidays here in NRW start by the beginning of the next week. I will think about my ideas and write them down in the next few days. It would be a good think to have some kind of "proposal" what could be discusses. Even if it never leaves the stage of a theoretical work, it would still have some benefits for the f?rther development, I think. > > We could even take the upload as implicated > > consent on the legal state. > Probably not, because somebody else may just create a key with a user > id that contains personal data of a different person. That'S where some kind of first upload authentication comes into the game, like Hagrid does. That's an approach that is worth consideration in that point. > > But, the possibility to share keys without > > UIDs is in some ways a good one. So you can habe ID-less keys for > > automated operations where you don't need the UIDs. By the way, is > > there a way to generate keys with GPG without UIDs? I tried, but I > > failed. Did I oversee an CLI option to do this? > I don't know. It does not seems to be forseen in RFC4880 and other > common OpenPGP implementations. And with lots of stable GnuPG > revisions out there in production and OpenPGP implementations for > interoperability, it does not seem to be a short term solution. Right, I read the document a while ago. The UIDs are nothing that disturb even in automated environments. So that's not a heavy thing. > > WKD is in some Cases kind of problematic. Think about users of > > gmail, like me, they don't offer WKD at all. So, a second system is > > nice to have. > I agree that is is nice to have second system, if just to provide > history data and revocation or rollout information if an email > provider completely drops out. That's one of the points I thought about. > On the gmail case I can only suggest to use an email provider that is > more privacy aware and supports WKD. (>;)) No seriously gmail my > offer WKD some day, if this is the standard emails users demand. Yes, but there are other cases where WKD is not an option. > > Just a few lines Background: I work in some company projects, where > > other companies are involved now. Until then, we propagated the > > keys we > > use over DNS as CERT RRs.in our internal DNS-Server. Now this is no > > longer an options. > But why not WKD? Do you require to transport a group of pubkeys? > Then I'd suggest a https file. This is related to the underlaying infrastructure. This has been there before I began working for them and I have to fight hard for any change or improvement I want to implement. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mgorny at gentoo.org Tue Jul 9 16:09:57 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Tue, 09 Jul 2019 16:09:57 +0200 Subject: Launching a new keyserver on keys.openpgp.org! In-Reply-To: References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091359.15794.bernhard@intevation.de> <6df86906ad976ef31f1bc1566551bc8a286442f3.camel@gentoo.org> Message-ID: <46a4d3c73703d7585c206e6a983a55821069d55e.camel@gentoo.org> On Tue, 2019-07-09 at 14:54 +0200, Dirk Gottschalk wrote: > Am Dienstag, den 09.07.2019, 14:40 +0200 schrieb Micha? G?rny: > > On Tue, 2019-07-09 at 14:31 +0200, Dirk Gottschalk via Gnupg-devel > > wrote: > > > Hi. > > > > > > Am Dienstag, den 09.07.2019, 13:59 +0200 schrieb Bernhard Reiter: > > > > Dear Hagrid Team, > > > > > > > > Am Mittwoch 12 Juni 2019 18:53:50 schrieb Vincent Breitmoser: > > > > > the Hagrid team is pleased to announce the launch of our new > > > > > keyserver, > > > > > running at keys.openpgp.org! > > > > > > > > [..] > > > > > https://keys.openpgp.org/about/news#2019-06-12-launch > > > > [..] > > > > > > > > > Some of the things we do are a bit experimental. For some > > > > > things we > > > > > found > > > > > that there is no good mechanism at this point, so we decided to > > > > > drop them > > > > > for now. > > > > > > > > it is good to see more code around OpenPGP. > > > > Maybe hagrid can be useful to improve the common infrastructure > > > > to > > > > distribute public keys in the future. > > > > > > > > From my point of view the service announcement and its > > > > description > > > > is a bit problematic, though: > > > > > > [snip] > > > > > > I fully agree with Bernhard. And I, for myself, think that > > > stri??ing > > > off third party signatures is a bad idea as well. It should be > > > possible > > > to implement some kind of validation for them. Another way could be > > > to > > > make only signatures from keys which are already on the server > > > available. Something like "import-clean" does on import. This would > > > avoid flooded keys. > > It could be trivially worked around via uploading the flooding keys > > to the server. After all, it accepts *all* keys, only UIDs it > > restricts. > > It could be done by cleaning the keys after recieving. At first there > surely will only a few signatures be shown, but with a growing > database, it would be a good idea. It would be possible to preseed the > database with the strong set, or with other well known clean keys. I don't think you understood my point. There is no reason why the attacker wouldn't be able to upload all the garbage keys used to create garbage signatures. > > > > The other pint is, the hkp protocol should be expanded to some kind > > > of authentication, so only the owner can upload and update a key. > > > The hagrid approach, which forces people to upload the keys via > > > web, as far as I could look into it, is a bad solution for > > > automatic systems. > > > Yes, I know, they offer some kind of Api for this, but it doesn't > > > work just utilizing gpg itself, as far as I can tell at this > > > moment. > > This presumes you can trust the server, and therefore solves only > > half of the problem. If the server eventually becomes distributed, > > you would also need to authorize cross-server exchanges. This still > > could be done via hacking on HKP but in the end I think it's > > preferable to store the permission on the key somewhere, so that end > > users can also benefit from it. > > That could be one was. On the other hand, there is no need f?r the sync > to also use HKP. There are other options to sync the database. And I > prefer the decentralized approach, so decentralized servers are > mandatory. > > Permission? I think you are talking about the permission to distribute > the UID. No, I'm talking about permission to distribute signature, i.e. the proof that the key owner has accepted it. Otherwise, GnuPG is still vulnerable to being hit by a single malicious keyserver in the pool. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From wk at gnupg.org Tue Jul 9 17:15:58 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Jul 2019 17:15:58 +0200 Subject: [Announce] GnuPG 2.2.17 released to mitigate attacks on keyservers Message-ID: <87ftnfi6hd.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.17. This is maintenance release to mitigate the effects of the denial-of-service attacks on the keyserver network. See below for a list changes. About GnuPG =========== The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.17 ==================================== * gpg: Ignore all key-signatures received from keyservers. This change is required to mitigate a DoS due to keys flooded with faked key-signatures. The old behaviour can be achieved by adding keyserver-options no-self-sigs-only,no-import-clean to your gpg.conf. [#4607] * gpg: If an imported keyblocks is too large to be stored in the keybox (pubring.kbx) do not error out but fallback to an import using the options "self-sigs-only,import-clean". [#4591] * gpg: New command --locate-external-key which can be used to refresh keys from the Web Key Directory or via other methods configured with --auto-key-locate. * gpg: New import option "self-sigs-only". * gpg: In --auto-key-retrieve prefer WKD over keyservers. [#4595] * dirmngr: Support the "openpgpkey" subdomain feature from draft-koch-openpgp-webkey-service-07. [#4590]. * dirmngr: Add an exception for the "openpgpkey" subdomain to the CSRF protection. [#4603] * dirmngr: Fix endless loop due to http errors 503 and 504. [#4600] * dirmngr: Fix TLS bug during redirection of HKP requests. [#4566] * gpgconf: Fix a race condition when killing components. [#4577] Release-info: https://dev.gnupg.org/T4606 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.17 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.17.tar.bz2 (6560k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.17.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.17_20190709.exe (4185k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.17_20190709.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new version of Gpg4win incluing this version of GnuPG will be released in a few days. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.2.17.tar.bz2 you would use this command: gpg --verify gnupg-2.2.17.tar.bz2.sig gnupg-2.2.17.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.17.tar.bz2, you run the command like this: sha1sum gnupg-2.2.17.tar.bz2 and check that the output matches the next line: 12c1cee8871c03f0315fc8f27876364b75c95b12 gnupg-2.2.17.tar.bz2 533deef5939fcd6506be650731dea4a9d18f9df8 gnupg-w32-2.2.17_20190709.tar.xz 82abfbc79d1a99b27f25ba92fe878cad07a31532 gnupg-w32-2.2.17_20190709.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Japanese, Norwegian, Polish, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T4509 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs two full-time developers and one contractor. They all work exclusively on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and to address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dominik at schuermann.eu Tue Jul 9 16:09:35 2019 From: dominik at schuermann.eu (Dominik Schuermann) Date: Tue, 9 Jul 2019 16:09:35 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <201907091451.48768.bernhard@intevation.de> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> <201907091451.48768.bernhard@intevation.de> Message-ID: <19f1150a-e92f-20d4-101d-599915831ffd@schuermann.eu> On 7/9/19 2:51 PM, Bernhard Reiter wrote: >> We could even take the upload as implicated >> consent on the legal state. > > Probably not, because somebody else may just create a key with a user id that > contains personal data of a different person Yep, exactly. GDPR is all about consent (Art 7). Consent can not be given implicitly. This is generally interpreted in a way that leads to the requirement of a double opt-in. This ensures that consent is given by the person related to this PII ('data subject'). In simple terms: If I upload a key with Bernhard's email address, Bernhard must be asked to give consent. This works by sending an email to Bernhard. One goal of keys.openpgp.org is that it's GDPR-compliant. Thus, email validation using double opt-in is implemented. Cheers Dominik From mgorny at gentoo.org Tue Jul 9 19:45:17 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Tue, 09 Jul 2019 19:45:17 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <19f1150a-e92f-20d4-101d-599915831ffd@schuermann.eu> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> <201907091451.48768.bernhard@intevation.de> <19f1150a-e92f-20d4-101d-599915831ffd@schuermann.eu> Message-ID: <629909da9c33c080052edce62704ab494b13cf3c.camel@gentoo.org> On Tue, 2019-07-09 at 16:09 +0200, Dominik Schuermann wrote: > On 7/9/19 2:51 PM, Bernhard Reiter wrote: > > > We could even take the upload as implicated > > > consent on the legal state. > > > > Probably not, because somebody else may just create a key with a user id that > > contains personal data of a different person > Yep, exactly. GDPR is all about consent (Art 7). Consent can not be > given implicitly. This is generally interpreted in a way that leads to > the requirement of a double opt-in. This ensures that consent is given > by the person related to this PII ('data subject'). In simple terms: If > I upload a key with Bernhard's email address, Bernhard must be asked to > give consent. This works by sending an email to Bernhard. > > One goal of keys.openpgp.org is that it's GDPR-compliant. Thus, email > validation using double opt-in is implemented. > I don't really understand why e-mail validation is proper consent to real name which is not verified at all. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From wk at gnupg.org Tue Jul 9 21:37:17 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Jul 2019 21:37:17 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> (Dirk Gottschalk via Gnupg-devel's message of "Tue, 09 Jul 2019 14:13:36 +0200") References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> Message-ID: <87pnmjgfte.fsf@wheatstone.g10code.de> On Tue, 9 Jul 2019 14:13, gnupg-devel at gnupg.org said: >> === Record deletions >> If someone requests a deletion (which means this person can prove >> that it is there personal data), this is also recorded, only by key >> number, so this can also be synced with other keyservers. > > Sure, technically not a big thing. Right, we have most tthings already in place. To delete a key the owner of the key just needs to publish a revocation certificate. The keyserver validates the revocation and removes everything from the key but the primary public key and the revocation signature. We can also make use of the reason-for-revocation flag. For example No reason specified --> Delete as described. Key is superseded --> Keep keyblock. Key material has been compromised --> Delete as described Key is retired and no longer used --> Keep keyblock In the keep cases the server should be prepared to see another revocation to delete the key. This is a bit questionable in the "key compromised" case. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dirk.gottschalk1980 at googlemail.com Wed Jul 10 01:15:48 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Wed, 10 Jul 2019 01:15:48 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <87pnmjgfte.fsf@wheatstone.g10code.de> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> <87pnmjgfte.fsf@wheatstone.g10code.de> Message-ID: <4ff5eb5f79ddc56a2f4a67d2e61866087986110b.camel@googlemail.com> Hello. Am Dienstag, den 09.07.2019, 21:37 +0200 schrieb Werner Koch: > On Tue, 9 Jul 2019 14:13, gnupg-devel at gnupg.org said: > > > === Record deletions > > > If someone requests a deletion (which means this person can prove > > > that it is there personal data), this is also recorded, only by > > > key > > > number, so this can also be synced with other keyservers. > > Sure, technically not a big thing. > Right, we have most tthings already in place. To delete a key the > owner of the key just needs to publish a revocation certificate. The > keyserver validates the revocation and removes everything from the > key but the primary public key and the revocation signature. This is a really good starting point. > We can also make use of the reason-for-revocation flag. For example > No reason specified --> Delete as described. > Key is superseded --> Keep keyblock. > Key material has been compromised --> Delete as described > Key is retired and no longer used --> Keep keyblock Yes, this makes sense. For a revoked key there is no need for a UID- Packet. A refresh would get the 'cut' packet and add the revocation. The UID packet on the client side shoule be left untouched so that the user is still able to see whoms key has been revoked. > In the keep cases the server should be prepared to see another > revocation to delete the key. This is a bit questionable in the "key > compromised" case. Yes, I see. In this case there shoule be some kind of additional confirmation mechanism to avoid abuse. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From angel at pgp.16bits.net Wed Jul 10 03:13:48 2019 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Wed, 10 Jul 2019 03:13:48 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <629909da9c33c080052edce62704ab494b13cf3c.camel@gentoo.org> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> <201907091451.48768.bernhard@intevation.de> <19f1150a-e92f-20d4-101d-599915831ffd@schuermann.eu> <629909da9c33c080052edce62704ab494b13cf3c.camel@gentoo.org> Message-ID: <1562721228.961.60.camel@16bits.net> On 2019-07-09 at 19:45 +0200, Micha? G?rny via Gnupg-devel wrote: > I don't really understand why e-mail validation is proper consent to > real name which is not verified at all. I'm not convinced it could be done. For validation you need a clear identifier. When you have an email you can easily validate its owner accepts it to be published, but if there's anything else attached to it, such as a secret you can't really validate it. Suppose someone uploaded a key named: clarkentissuperman You can programmatically check that someone which currently has access to says "Yes, I am clarkentissuperman, own key 0xDEADBEEF and wish that key to be uploaded to the keyservers" So far, so good, but is the name clarkentissuperman really his name (o alias)? Or is it framing someone else? Not only is that not automated, but it's really not decidable. Now someone comes called Clark Kent (he provides a government issued identification showing that), stating that such key is framing him. Maybe. Or maybe not. May someone have been named "clarkentissuperman"? Surely there could be several people named Clark Kent, but who would name a kid 'superman'?? ? Not to mention that it would make whole sense to use such name for someone whose online identity was that nickname.? The classic WoT solution uses signatures from people that validated it IRL to vouch that the uid is correct (not that everyone does that correctly, though). But other than mandating the usage of keys with only an email address in the uid field (or no uid field at all), there's little to do here. And then, the next step would be to create a clarkentissuperman at gmail.com account... Best regards ? https://i.pinimg.com/736x/62/76/ca/6276ca0474520316f8173896835b23fe.jpg ? https://www.pinterest.com/pin/351280839654707652 ? https://en.wikipedia.org/wiki/Nymwars From bernhard at intevation.de Wed Jul 10 09:11:18 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 10 Jul 2019 09:11:18 +0200 Subject: Launching a new keyserver on keys.openpgp.org! In-Reply-To: <46a4d3c73703d7585c206e6a983a55821069d55e.camel@gentoo.org> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <46a4d3c73703d7585c206e6a983a55821069d55e.camel@gentoo.org> Message-ID: <201907100911.18722.bernhard@intevation.de> Am Dienstag 09 Juli 2019 16:09:57 schrieb Micha? G?rny via Gnupg-devel: > Otherwise, GnuPG is still > vulnerable to being hit by a single malicious keyserver in the pool. The defense against malicious keyservers in a federated model I see is that those keyservers get blacklisted (and potentially legal action taken). So a typical defense against system on the internet. Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Jul 10 09:15:45 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 10 Jul 2019 09:15:45 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <4ff5eb5f79ddc56a2f4a67d2e61866087986110b.camel@googlemail.com> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <87pnmjgfte.fsf@wheatstone.g10code.de> <4ff5eb5f79ddc56a2f4a67d2e61866087986110b.camel@googlemail.com> Message-ID: <201907100915.45998.bernhard@intevation.de> Am Mittwoch 10 Juli 2019 01:15:48 schrieb Dirk Gottschalk via Gnupg-devel: > Am Dienstag, den 09.07.2019, 21:37 +0200 schrieb Werner Koch: > > On Tue, 9 Jul 2019 14:13, gnupg-devel at gnupg.org said: > > > > === Record deletions > > > > If someone requests a deletion (which means this person can prove > > > > that it is there personal data), this is also recorded, only by > > > > key > > > > number, so this can also be synced with other keyservers. > > > > > > Sure, technically not a big thing. > > > > Right, we have most things already in place. To delete a key the > > owner of the key just needs to publish a revocation certificate. As the problem I like to solve is with personal data about A that comes from a key that A does not control. So if A then requests deletion, which will be possible, because otherwise it wouldn't be personal data from A, the keyserver must record this. But because the keyserver and A do not control the key, it must be recorded differently. It cannot be a signature of the key in question. Once a pubkey is found to distribute personal data of A which A does not like, the full pubkey is not distributed anymore. Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Jul 10 09:23:42 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 10 Jul 2019 09:23:42 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <1562721228.961.60.camel@16bits.net> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <629909da9c33c080052edce62704ab494b13cf3c.camel@gentoo.org> <1562721228.961.60.camel@16bits.net> Message-ID: <201907100923.42449.bernhard@intevation.de> Am Mittwoch 10 Juli 2019 03:13:48 schrieb ?ngel: > On 2019-07-09 at 19:45 +0200, Micha? G?rny via Gnupg-devel wrote: > > I don't really understand why e-mail validation is proper consent to > > real name which is not verified at all. Because if the real name is not enough to identify a person, it is not personal data. So we publish is as non-personal data and do not need consent. > For validation you need a clear identifier. When you have an email you > can easily validate its owner accepts it to be published, but if there's > anything else attached to it, such as a secret you can't really validate > it. And you don't need to, we do not want to "validate" it, which is impossible, we just want to avoid abuse and allow anonymous usage. > Suppose someone uploaded a key named: > clarkentissuperman Which obviously isn't a personal data of "clarkent", because it is not his email address. > Now someone comes called Clark Kent (he provides a government issued > identification showing that), stating that such key is framing him. So the operator of the keyserver gets an email by Clark and sees by the description that this really is personal data of him, then this operator would manually record a deletion for this pubkey in question and note the explanation down (for later requests). Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Jul 10 09:32:29 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 10 Jul 2019 09:32:29 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" (was: Launching a new keyserver on keys.openpgp.org!) In-Reply-To: <0ad6850a6cd807f2e2e1903cd04d7b2b803a960b.camel@gentoo.org> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <0ad6850a6cd807f2e2e1903cd04d7b2b803a960b.camel@gentoo.org> Message-ID: <201907100932.30130.bernhard@intevation.de> Am Dienstag 09 Juli 2019 14:37:05 schrieb Micha? G?rny via Gnupg-devel: > On Tue, 2019-07-09 at 11:50 +0200, Bernhard Reiter wrote: > somebody could upload a key with your data without > your permission. However, somebody can also upload an UID with your PII > on it (name, even address, etc.) and some other e-mail address. E-mail > verification does not really solve the problem, and I think it's > reasonable to assume goodwill and handle abuse directly. If the person with the address can reasonably prove that this is his address, you have a point of contact and can blacklist the pubkey. Same as someone can prove that the contents is otherwise illegal, e.g. by presenting a valid court order that it is. > > === Non-email ids > > The server can publish it preliminary, until someone complains and then > > we either adapt the detection algorithm, record a deletion for the pubkey > > or manually trigger the permission request. > Detection algorithms make little sense. Do you really want to have > different rules for people with common names, and with uncommon names? This is a strategy of keeping the administrative work of a keyserver at a reasonable amount. The first cases will be manual (like above), but other cases will be automated. The only way to defend against a work overflow is to automate the automatic publishing rules and for those that match go back to manual verification. This does not prevent legitimate, anynomous use of some string in the uids, but it prevents automated abuse like base64 encoding the personal data. > How are you going to detect people on photo IDs? We also should limit the data on the userid to some byte length, but yes, if it gets an automated attack that personal data, like an email address gets encoded as png image, we might have to add a png decoder and an OCR at some point. The point of this strategy is that we only do it, once this attack really comes to place. And additionally, we try to get hold of the attacker and sue her for interfering with a common infrastructure. All together we are making it less attractive to attack the common infrastructure, because it would mean to get inventive and to beat the cheap algorithm with manual work each time. Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Jul 10 10:04:36 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 10 Jul 2019 10:04:36 +0200 Subject: Web of Trust's usefulness (was: Preserving third party signatures distribution) In-Reply-To: <201907091436.52907.bernhard@intevation.de> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091436.52907.bernhard@intevation.de> Message-ID: <201907101004.41908.bernhard@intevation.de> Hello Friends of GnuPG, Am Dienstag 09 Juli 2019 14:36:39 schrieb Bernhard Reiter: > This does not discuss if having third party information outside of WKD > repositories is useful in the long-term. The approach only tries to make > technically possible what a significant number of people is using today > and some consider useful to have. overall I believe that having third party signatures is useful. Just like old pubkeys, non email uids and the ability to search them. Not in the traditional sense of the web of trust alone, but as additional source of trust and history. Think about how it would develop if we were not having it: Trust and identity would depend even more on email addresses and online TLS verifications (e.g. by accessing the keyservers or for the "validation" processes). And they already depend on this too much for my taste. Abandoning the web of trust common infrastructure works against usage models where there is anonymous usage, several identities, non-email use and offline usage. All those maybe not the majority case, they may even be nice models, but I think they are important to add diversity and resiliance against manipulations of mainstream players. To me it seems a bit like freedom of speach or press: An individual may need it rarely, but for society is is tremendously important. Thus, if it is true like discussed in other emails that we technically can be preserved for public keyservers, it maybe useful to do. An additional reason to preserve this infrastructure would be just to keep the promise for users by showing that we support old usage models and honor the trust that people have put into those models and in our development community in the past. == Mixing in history and trust for usage For a better user experience we do not want people to think about signature releationships and the trust value they put into other people's keys to verify other pubkeys. However if those signatures are present they can be used to mix in some trust into the personal setting and communication history. This won't be perfect, but can help to detect direct manipulation attempts. For example there is a group of people in an organisation that signs many pubkeys. They are some sort of low-key part-value certificate authority. People can learn this concept and saying, hey for this handball club or company I believe them to have some trust and I mark a few keys from them as trust-introducers. A calculation will take this into account to one pubkey will go one one step up if it has their signature. It is different from a CA in that one signature will not be enough to get a higher level it itself. == History if provider or people drop out It is not just the current active key, sometimes it is also the last active key that are enough to give a bit more confidence in the signature from last year. If a provider drops out, it is interesting to see that this person had an email address there and this person can still sign a new pubkey, with the old one. On the other hand if a person does not have access anymore or drops out, the pubkey will rot and third party signatures will show this. An old strong set of signatures is useful if a fast manipulation comes along, this is a bit like a distributed ledger, though not as strong, but needs less resources. == Conclusion The above arguments and thoughts trying to give an idea of positive effects of keeping Web of Trust information around in a federated common keyserver infrastructure. They do not consider if it is worth the costs, mostly because the costs are hard to estimate. Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From maximilian.krambach at intevation.de Wed Jul 10 10:12:37 2019 From: maximilian.krambach at intevation.de (Maximilian Krambach) Date: Wed, 10 Jul 2019 10:12:37 +0200 Subject: gpgme-json chromium/firefox packaging Message-ID: <201907101012.46496.maximilian.krambach@intevation.de> Hi, I have been tasked to prepare "debian packages" for the gpgme-json browser integration, to ease installation of native messaging between gnupg and browser extensions. I'm working on a patch for salsa.debian.org/debian/gpgme/, as I think this is probably the best place for it. Basically, the two packages (chromium-gpgme and firefox-gpgme) just need to ensure that the gpgme-json binary ships, and that a configuration file is present at paths the browsers like. My question: Is it okay and maintainable to add "approved" extension ids (in this case, mailvelope) to these configuration files? In the end, it is an authorization between the extension(s) and the browser (based on ids assigned by the browser publisher). gpgme-json itself does not care who communicates with them (as long as it stays the same actor). Still, I have the feelings that some link between worlds is created that may not be desired. Maximilian -- Maximilian Krambach | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Wed Jul 10 10:49:28 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 10 Jul 2019 09:49:28 +0100 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <4ff5eb5f79ddc56a2f4a67d2e61866087986110b.camel@googlemail.com> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> <87pnmjgfte.fsf@wheatstone.g10code.de> <4ff5eb5f79ddc56a2f4a67d2e61866087986110b.camel@googlemail.com> Message-ID: <4be79b20-d08e-9d12-9c29-20ee5ce986dc@andrewg.com> On 10/07/2019 00:15, Dirk Gottschalk via Gnupg-devel wrote: >> In the keep cases the server should be prepared to see another >> revocation to delete the key. This is a bit questionable in the "key >> compromised" case. > Yes, I see. In this case there shoule be some kind of additional > confirmation mechanism to avoid abuse. I don't follow. If a key is compromised, then the keyblock gets deleted. What's the additional confirmation mechanism for? -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Jul 10 11:01:09 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 10 Jul 2019 10:01:09 +0100 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <201907100915.45998.bernhard@intevation.de> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <87pnmjgfte.fsf@wheatstone.g10code.de> <4ff5eb5f79ddc56a2f4a67d2e61866087986110b.camel@googlemail.com> <201907100915.45998.bernhard@intevation.de> Message-ID: <5354b53e-c015-9ab5-dfb7-c660c88811ca@andrewg.com> On 10/07/2019 08:15, Bernhard Reiter wrote: > Once a pubkey is found to distribute personal data of A which A does not like, > the full pubkey is not distributed anymore. A validating, non-synchronising keyserver can perform this function in the same way that any other website can, by simply deleting the data on (reasonable) request. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Jul 10 11:05:24 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 10 Jul 2019 10:05:24 +0100 Subject: Preserving non-central and privacy with a "permission recording keyserver" (was: Launching a new keyserver on keys.openpgp.org!) In-Reply-To: <0ad6850a6cd807f2e2e1903cd04d7b2b803a960b.camel@gentoo.org> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <0ad6850a6cd807f2e2e1903cd04d7b2b803a960b.camel@gentoo.org> Message-ID: <2581277c-c891-7db6-cb71-24ba568b5e14@andrewg.com> On 09/07/2019 13:37, Micha? G?rny via Gnupg-devel wrote: > Detection algorithms make little sense. Do you really want to have > different rules for people with common names, and with uncommon names? Real names are not unique. For any given real name it is almost guaranteed that someone else in the world has the same name. Real-name impersonation is not a problem that the keyservers can or should solve - we are just trying to prevent spam here, not act as an authority. > How are you going to detect people on photo IDs? Don't, just delete them all. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From mgorny at gentoo.org Wed Jul 10 11:05:57 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Wed, 10 Jul 2019 09:05:57 +0000 Subject: Preserving non-central and privacy with a "permission recording keyserver" (was: Launching a new keyserver on keys.openpgp.org!) In-Reply-To: <201907100932.30130.bernhard@intevation.de> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <0ad6850a6cd807f2e2e1903cd04d7b2b803a960b.camel@gentoo.org> <201907100932.30130.bernhard@intevation.de> Message-ID: Dnia July 10, 2019 7:32:29 AM UTC, Bernhard Reiter napisa?(a): >Am Dienstag 09 Juli 2019 14:37:05 schrieb Micha? G?rny via Gnupg-devel: >> On Tue, 2019-07-09 at 11:50 +0200, Bernhard Reiter wrote: > >> > === Non-email ids > > >> How are you going to detect people on photo IDs? > >We also should limit the data on the userid to some byte length, but >yes, if >it gets an automated attack that personal data, like an email address >gets >encoded as png image, we might have to add a png decoder and an OCR at >some >point. The point of this strategy is that we only do it, once this >attack >really comes to place. And additionally, we try to get hold of the >attacker >and sue her for interfering with a common infrastructure. I don't think we're taking about the same thing. I was considering the case where somebody uploads his photo as UID. How are you going to protect against somebody using my face, for example? -- Best regards, Micha? G?rny From dirk.gottschalk1980 at googlemail.com Wed Jul 10 11:18:21 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Wed, 10 Jul 2019 11:18:21 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <4be79b20-d08e-9d12-9c29-20ee5ce986dc@andrewg.com> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> <87pnmjgfte.fsf@wheatstone.g10code.de> <4ff5eb5f79ddc56a2f4a67d2e61866087986110b.camel@googlemail.com> <4be79b20-d08e-9d12-9c29-20ee5ce986dc@andrewg.com> Message-ID: <4c3bf9977a349af9e547ff3c8783310bd41ef41f.camel@googlemail.com> Hi Andrew. Am Mittwoch, den 10.07.2019, 09:49 +0100 schrieb Andrew Gallagher: > On 10/07/2019 00:15, Dirk Gottschalk via Gnupg-devel wrote: > > > In the keep cases the server should be prepared to see another > > > revocation to delete the key. This is a bit questionable in the > > > "key > > > compromised" case. > > Yes, I see. In this case there shoule be some kind of additional > > confirmation mechanism to avoid abuse. > > I don't follow. If a key is compromised, then the keyblock gets > deleted. > What's the additional confirmation mechanism for? A compromised key will not be deleted in Werners scenario, just stripped down to primary key and revocation. Not a full Detetion. The confirmation is for the scenario when the full dataset should be deleted. Porobably I misunderstood Werner. If so, please forgive me. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From andrewg at andrewg.com Wed Jul 10 11:27:19 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 10 Jul 2019 10:27:19 +0100 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <4c3bf9977a349af9e547ff3c8783310bd41ef41f.camel@googlemail.com> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> <87pnmjgfte.fsf@wheatstone.g10code.de> <4ff5eb5f79ddc56a2f4a67d2e61866087986110b.camel@googlemail.com> <4be79b20-d08e-9d12-9c29-20ee5ce986dc@andrewg.com> <4c3bf9977a349af9e547ff3c8783310bd41ef41f.camel@googlemail.com> Message-ID: <1c012f87-60a2-bdf9-24f1-a680a0fc4fab@andrewg.com> On 10/07/2019 10:18, Dirk Gottschalk wrote: > A compromised key will not be deleted in Werners scenario, just > stripped down to primary key and revocation. Not a full Detetion. The > confirmation is for the scenario when the full dataset should be > deleted. Porobably I misunderstood Werner. Maybe *I* misunderstood Werner. :-) I don't think we should ever delete the full dataset (i.e. including the primary). We still need to be able to distribute revocations, and that's only going to work if they're attached to something. Compromised keys shouldn't be searchable by ID, so deleting everything except the primary makes sense in such cases. Merely superseded keys should be searchable by ID because we may wish to verify historical signatures, and that's only possible if they are stored in full. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rainer.perske at uni-muenster.de Wed Jul 10 11:20:57 2019 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Wed, 10 Jul 2019 11:20:57 +0200 (CEST) Subject: Privacy of real name In-Reply-To: <201907100923.42449.bernhard@intevation.de> Message-ID: Hello, May be I miss the context (I do not follow this thread thoroughly) but this remark ... > Because if the real name is not enough to identify a person, it is > not personal data. ... may not remain uncontested. A real name like Thomas M?ller might be not enough to identify a person, because there are thousands of them but a real name like mine (Rainer Perske) is enough. There are only two persons with this name all over the world, one in Berlin (Germany) and one in M?nster (Germany), and only one of them (me) is likely to use OpenPGP. So if you see some OpenPGP related datum connected with the name "Rainer Perske" you can be quite certain that this datum belongs to me. Whatever you do: A real name is a highly sensitive personal datum and necessarily belongs to the data to be privacy protected. Please avoid mistakes that could discredit OpenPGP in this context. Best regards and thank you very much to all involved people for all your commitment to OpenPGP! -- Rainer Perske Abteilung Systembetrieb und Leiter der Zertifizierungsstelle (WWUCA) Zentrum f?r Informationsverarbeitung (Universit?tsrechenzentrum) Westf?lische Wilhelms-Universit?t Zentrum f?r Informationsverarbeitung Rainer Perske R?ntgenstra?e 7-13 48149 M?nster Tel.: +49 251 83-31582 Fax.: +49 251 83-31555 E-Mail: rainer.perske at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/Mitarbeiter/RainerPerske.shtml B?ro: Raum 006, R?ntgenstra?e 11 Lageplan: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474 Zertifizierungsstelle der Universit?t M?nster (WWUCA): Tel.: +49 251 83-31590 Fax.: +49 251 83-31555 E-Mail: ca at uni-muenster.de WWW: https://www.uni-muenster.de/WWUCA/ Zentrum f?r Informationsverarbeitung (ZIV): Tel.: +49 251 83-31600 (Mo-Fr 7:30-17:30 Uhr) Fax.: +49 251 83-31555 E-Mail: ziv at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5470 bytes Desc: S/MIME cryptographic signature URL: From bernhard at intevation.de Wed Jul 10 13:44:20 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 10 Jul 2019 13:44:20 +0200 Subject: Privacy of real name In-Reply-To: References: Message-ID: <201907101344.20613.bernhard@intevation.de> Am Mittwoch 10 Juli 2019 11:20:57 schrieb Rainer Perske: > > Because if the real name is not enough to identify a person, it is > > not personal data. > > ... may not remain uncontested. > > A real name like Thomas M?ller might be not enough to identify a > person, because there are thousands of them but a real name like mine > (Rainer Perske) is enough. But then the condition of the if clause above is not given and it is personal data. To give some context: We are discussing how to deal with subcases of an improved keyserver that distributes user ids, which is a helper function of end-to-end crypto with OpenPGP. The question is when to decide that it wasn't the user itself that used the name, but someone else. The approach we think about is post-publication handling, like blog-providers, social networks and search engines. > A real name is a highly sensitive personal datum and > necessarily belongs to the data to be privacy protected. If we see bytes in two groups with an upper and a lower letter, we can assume it is name, but we often cannot decide if it is and if it is personal data. For the proposed model this is not necessary, though. Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Jul 10 13:46:03 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 10 Jul 2019 13:46:03 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" (was: Launching a new keyserver on keys.openpgp.org!) In-Reply-To: References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907100932.30130.bernhard@intevation.de> Message-ID: <201907101346.03275.bernhard@intevation.de> Am Mittwoch 10 Juli 2019 11:05:57 schrieb Micha? G?rny via Gnupg-devel: > I was considering the case where somebody uploads his photo as UID. How are > you going to protect against somebody using my face, for example? a) We don't allow that much data. b) You can apply for deletion of the pubkey afterwards. c) If the same algorithm is used to transfer more image data, deploy a filter that does not allow it. -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Jul 10 13:51:54 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 10 Jul 2019 13:51:54 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <5354b53e-c015-9ab5-dfb7-c660c88811ca@andrewg.com> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907100915.45998.bernhard@intevation.de> <5354b53e-c015-9ab5-dfb7-c660c88811ca@andrewg.com> Message-ID: <201907101351.54336.bernhard@intevation.de> Am Mittwoch 10 Juli 2019 11:01:09 schrieb Andrew Gallagher: > On 10/07/2019 08:15, Bernhard Reiter wrote: > > Once a pubkey is found to distribute personal data of A which A does not > > like, the full pubkey is not distributed anymore. > > A validating, non-synchronising keyserver can perform this function in > the same way that any other website can, by simply deleting the data on > (reasonable) request. Yes, but I want to build a synchronising keyserver network. ;) This is why the keyserver receiving the explicit non-permission must put this in their list and share it with others, so the pubkey does not get distributed by any (reasonable) keyserver anymore. Once we know a pubkey is rouge, it shall not be distributed anymore, because it means the key owner does not respect somebody's personal data preferences. If this is by mistake, a new key can be generated using a different uid which is improved in this regard. Best, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Wed Jul 10 14:06:42 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 10 Jul 2019 13:06:42 +0100 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <201907101351.54336.bernhard@intevation.de> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907100915.45998.bernhard@intevation.de> <5354b53e-c015-9ab5-dfb7-c660c88811ca@andrewg.com> <201907101351.54336.bernhard@intevation.de> Message-ID: <4719a569-d244-c9a0-af20-cc7cb2337a40@andrewg.com> On 10/07/2019 12:51, Bernhard Reiter wrote: > Am Mittwoch 10 Juli 2019 11:01:09 schrieb Andrew Gallagher: >> >> A validating, non-synchronising keyserver can perform this function in >> the same way that any other website can, by simply deleting the data on >> (reasonable) request. > > Yes, but I want to build a synchronising keyserver network. ;) Then it can't be a validating network, because there's no way to cryptographically validate a reasonable request, not without trusting root authorities to sign legal documents. > This is why the keyserver receiving the explicit non-permission must put this > in their list and share it with others, so the pubkey does not get > distributed by any (reasonable) keyserver anymore. There are two ways for the key subject to deny permission - either cryptographically, which only works if they are in possession of the private key; or non-cryptographically, which only works if there is a single source of (legally compelled?) truth. That's why I proposed separating the keyserver network into validating keyservers (hagrid, keybase.io) which validate non-cryptographic key content but don't synchronise with each other, and caching keyservers which sync but refer to the validating keyservers as a source of non-cryptographic content. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rainer.perske at uni-muenster.de Wed Jul 10 16:12:57 2019 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Wed, 10 Jul 2019 16:12:57 +0200 (CEST) Subject: Privacy of real name In-Reply-To: <201907101344.20613.bernhard@intevation.de> Message-ID: Dear Bernhard Reiter, thank you for your clarification! -- Rainer Perske Abteilung Systembetrieb und Leiter der Zertifizierungsstelle (WWUCA) Zentrum f?r Informationsverarbeitung (Universit?tsrechenzentrum) Westf?lische Wilhelms-Universit?t Zentrum f?r Informationsverarbeitung Rainer Perske R?ntgenstra?e 7-13 48149 M?nster Tel.: +49 251 83-31582 Fax.: +49 251 83-31555 E-Mail: rainer.perske at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/Mitarbeiter/RainerPerske.shtml B?ro: Raum 006, R?ntgenstra?e 11 Lageplan: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474 Zertifizierungsstelle der Universit?t M?nster (WWUCA): Tel.: +49 251 83-31590 Fax.: +49 251 83-31555 E-Mail: ca at uni-muenster.de WWW: https://www.uni-muenster.de/WWUCA/ Zentrum f?r Informationsverarbeitung (ZIV): Tel.: +49 251 83-31600 (Mo-Fr 7:30-17:30 Uhr) Fax.: +49 251 83-31555 E-Mail: ziv at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5470 bytes Desc: S/MIME cryptographic signature URL: From rjh at sixdemonbag.org Wed Jul 10 14:52:45 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 10 Jul 2019 08:52:45 -0400 Subject: Preserving non-central and privacy with a "permission recording keyserver" (was: Launching a new keyserver on keys.openpgp.org!) In-Reply-To: <2581277c-c891-7db6-cb71-24ba568b5e14@andrewg.com> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <0ad6850a6cd807f2e2e1903cd04d7b2b803a960b.camel@gentoo.org> <2581277c-c891-7db6-cb71-24ba568b5e14@andrewg.com> Message-ID: > Real names are not unique. For any given real name it is almost > guaranteed that someone else in the world has the same name. For a dark and terrifying example, consider the other Robert Hansen who grew up in northwest Iowa. https://en.wikipedia.org/wiki/Robert_Hansen Or consider the other Robert Hansen who spoke at Black Hat: https://graylinegroup.com/robert-hansen/ Back in the late '90s there were a few Robert Hansens in comp.os.linux.* and we often got confused for each other, including this guy: https://en.wikipedia.org/wiki/Robert_Hanssen In a final example of namespace collision: the serial killer Robert Hansen from northwest Iowa was eventually apprehended thanks to contributions from an FBI agent named John Douglas. A different John Douglas is an old friend of mine from high school. The upshot of all this is: saying "real names are not unique" is an overstatement. Name collisions occur _all the time_. If your system incorporates real names, this is something you need to think about now, not later. From wk at gnupg.org Wed Jul 10 19:54:49 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Jul 2019 19:54:49 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <1c012f87-60a2-bdf9-24f1-a680a0fc4fab@andrewg.com> (Andrew Gallagher's message of "Wed, 10 Jul 2019 10:27:19 +0100") References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> <87pnmjgfte.fsf@wheatstone.g10code.de> <4ff5eb5f79ddc56a2f4a67d2e61866087986110b.camel@googlemail.com> <4be79b20-d08e-9d12-9c29-20ee5ce986dc@andrewg.com> <4c3bf9977a349af9e547ff3c8783310bd41ef41f.camel@googlemail.com> <1c012f87-60a2-bdf9-24f1-a680a0fc4fab@andrewg.com> Message-ID: <87tvbtepw6.fsf@wheatstone.g10code.de> On Wed, 10 Jul 2019 10:27, andrewg at andrewg.com said: > I don't think we should ever delete the full dataset (i.e. including the > primary). We still need to be able to distribute revocations, and that's > only going to work if they're attached to something. Some folks are talking about privacy reasons not to distribute the user-id. I don't buy this argument because the user has already given his consent (with most MUAs and with gpg's command line) to use a mail address along with a key and the specific format is a requirement. Anyway in the case of a compromised key it might make sense to delete everything but the primary key and the revocation signature: Anyone who has access to the compromised key can add user-ids and other stuff to the key at will and thus harm the repudiation of the user (We all know that people don't look at details of a key, like [REVOKED], when they see some kind of interesting data in the key). But that's up to discussion. > except the primary makes sense in such cases. Merely superseded keys > should be searchable by ID because we may wish to verify historical A key on a keyserver should never be searchable by user-id. It is not required and only an attractor to use the keyserver as free and searchable data storage. We only need lookups by fingerprint. Keys should in general be discovered by other reliable mail to key mapping services. If that is not possible there is always the fallback to first send a signed mail and the recipients tool can then lookup the key via the fingerprint (which is embedded in the signature) at a keyserver. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Wed Jul 10 20:05:31 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 10 Jul 2019 19:05:31 +0100 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <87tvbtepw6.fsf@wheatstone.g10code.de> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> <87pnmjgfte.fsf@wheatstone.g10code.de> <4ff5eb5f79ddc56a2f4a67d2e61866087986110b.camel@googlemail.com> <4be79b20-d08e-9d12-9c29-20ee5ce986dc@andrewg.com> <4c3bf9977a349af9e547ff3c8783310bd41ef41f.camel@googlemail.com> <1c012f87-60a2-bdf9-24f1-a680a0fc4fab@andrewg.com> <87tvbtepw6.fsf@wheatstone.g10code.de> Message-ID: On 2019/07/10 18:54, Werner Koch wrote: > On Wed, 10 Jul 2019 10:27, andrewg at andrewg.com said: > >> I don't think we should ever delete the full dataset (i.e. including the >> primary). We still need to be able to distribute revocations, and that's >> only going to work if they're attached to something. > > Some folks are talking about privacy reasons not to distribute the > user-id. I don't buy this argument because the user has already given > his consent (with most MUAs and with gpg's command line) to use a mail > address along with a key and the specific format is a requirement. The problem with the consent argument is that consent must be active and explicit; you cannot presume consent just because someone has used a service. But I don't think the consent argument is relevant, because (IMO) keyservers fall under "subject has placed the information in the public domain" - so long as there has been a reasonable verification step to ensure that it was the data subject that did it. The real trick is vindicating the right to deletion... > Anyway in the case of a compromised key it might make sense to delete > everything but the primary key and the revocation signature: Agreed. > A key on a keyserver should never be searchable by user-id. It is not > required and only an attractor to use the keyserver as free and > searchable data storage. We only need lookups by fingerprint. Keys > should in general be discovered by other reliable mail to key mapping > services. If that is not possible there is always the fallback to first > send a signed mail and the recipients tool can then lookup the key via > the fingerprint (which is embedded in the signature) at a keyserver. That works for email userids. But email is only one use case for PGP, so there is still a need for some form of lookup by ID, at least in the short term. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From look at my.amazin.horse Wed Jul 10 20:39:19 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Wed, 10 Jul 2019 20:39:19 +0200 Subject: Key discovery vision (was: Preserving non-central and privacy..) In-Reply-To: <87tvbtepw6.fsf@wheatstone.g10code.de> References: <87tvbtepw6.fsf@wheatstone.g10code.de> <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> <87pnmjgfte.fsf@wheatstone.g10code.de> <4ff5eb5f79ddc56a2f4a67d2e61866087986110b.camel@googlemail.com> <4be79b20-d08e-9d12-9c29-20ee5ce986dc@andrewg.com> <4c3bf9977a349af9e547ff3c8783310bd41ef41f.camel@googlemail.com> <1c012f87-60a2-bdf9-24f1-a680a0fc4fab@andrewg.com> Message-ID: <3UE3NAI9R66TR.3RGZNO3HE0VSA@my.amazin.horse> > A key on a keyserver should never be searchable by user-id. It is not > required and only an attractor to use the keyserver as free and > searchable data storage. We only need lookups by fingerprint. Keys > should in general be discovered by other reliable mail to key mapping > services. I agree with this, mostly. Ideally, key discovery should always work in-band alongside regular e-mail communications (-> Autocrypt), aided by a priori discovery from the target domain (-> WKD). This latter method must be optional, because not everybody wants to publish their email/pubkey binding. And for good reason: e2e spam is only not an issue right now because it's too obscure. However - for the time being, neither Autocrypt nor WKD are deployed widely enough to actually fulfill this role. Thus, we do need some kind of "wkd-lookaside" that just works?. > If that is not possible there is always the fallback to first send a signed > mail and the recipients tool can then lookup the key via the fingerprint > (which is embedded in the signature) at a keyserver. Attachments are userspace. No user wants to have "signature.asc" or "publickey.asc" attachments on their email messages. It makes you look like a nerd. If we want to have users who aren't comfortable with looking like a nerd, we must stop trespassing on their message content. This might sound extreme, because it means dropping or changing every mechanism we have that relies on MIME thingies that accidentally look like attachments, notably pgp/mime signatures and attached keys. I don't think it is. Users care about stuff like this, and deferring the issue to user education does not scale. - V From dirk.gottschalk1980 at googlemail.com Wed Jul 10 23:28:47 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Wed, 10 Jul 2019 23:28:47 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <87tvbtepw6.fsf@wheatstone.g10code.de> References: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> <87pnmjgfte.fsf@wheatstone.g10code.de> <4ff5eb5f79ddc56a2f4a67d2e61866087986110b.camel@googlemail.com> <4be79b20-d08e-9d12-9c29-20ee5ce986dc@andrewg.com> <4c3bf9977a349af9e547ff3c8783310bd41ef41f.camel@googlemail.com> <1c012f87-60a2-bdf9-24f1-a680a0fc4fab@andrewg.com> <87tvbtepw6.fsf@wheatstone.g10code.de> Message-ID: <87ea52c944d6cb00e793125747b7788e63318723.camel@googlemail.com> Hello Werner Am Mittwoch, den 10.07.2019, 19:54 +0200 schrieb Werner Koch: > On Wed, 10 Jul 2019 10:27, andrewg at andrewg.com said: > > > I don't think we should ever delete the full dataset (i.e. > > including the > > primary). We still need to be able to distribute revocations, and > > that's > > only going to work if they're attached to something. > > Some folks are talking about privacy reasons not to distribute the > user-id. I don't buy this argument because the user has already > given his consent (with most MUAs and with gpg's command line) to use > a mail address along with a key and the specific format is a > requirement. Yes, that's my thaught. [...] > A key on a keyserver should never be searchable by user-id. It is > not required and only an attractor to use the keyserver as free and > searchable data storage. We only need lookups by fingerprint. Keys > should in general be discovered by other reliable mail to key mapping > services. If that is not possible there is always the fallback to > first send a signed mail and the recipients tool can then lookup the > key via the fingerprint (which is embedded in the signature) at a > keyserver. Then, the --search-keys option og gpg CLI is obsolete. That would be okay, but this option should be disables in newer versions of gpg. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From look at my.amazin.horse Wed Jul 10 23:42:46 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Wed, 10 Jul 2019 23:42:46 +0200 Subject: Preserving non-central and privacy with a "permission recording keyserver" In-Reply-To: <87ea52c944d6cb00e793125747b7788e63318723.camel@googlemail.com> References: <87ea52c944d6cb00e793125747b7788e63318723.camel@googlemail.com> <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> <201907091150.44819.bernhard@intevation.de> <792a268e705bf002540e596eb5662199e9c81ad4.camel@googlemail.com> <87pnmjgfte.fsf@wheatstone.g10code.de> <4ff5eb5f79ddc56a2f4a67d2e61866087986110b.camel@googlemail.com> <4be79b20-d08e-9d12-9c29-20ee5ce986dc@andrewg.com> <4c3bf9977a349af9e547ff3c8783310bd41ef41f.camel@googlemail.com> <1c012f87-60a2-bdf9-24f1-a680a0fc4fab@andrewg.com> <87tvbtepw6.fsf@wheatstone.g10code.de> Message-ID: <3HOOBE9W6UNTK.2BLZ7OZF9RNKI@my.amazin.horse> > Then, the --search-keys option og gpg CLI is obsolete. That would be > okay, but this option should be disables in newer versions of gpg. This is in progress: https://dev.gnupg.org/T4599 - V From dkg at fifthhorseman.net Fri Jul 12 04:45:32 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 11 Jul 2019 22:45:32 -0400 Subject: gpgme-json chromium/firefox packaging In-Reply-To: <201907101012.46496.maximilian.krambach@intevation.de> References: <201907101012.46496.maximilian.krambach@intevation.de> Message-ID: <87pnmg3r8z.fsf@fifthhorseman.net> Hi Maximilian-- On Wed 2019-07-10 10:12:37 +0200, Maximilian Krambach wrote: > I have been tasked to prepare "debian packages" for the gpgme-json browser > integration, to ease installation of native messaging between gnupg and browser > extensions. great, thanks for working on this! I assume you're aware of https://bugs.debian.org/911189 (in cc as well). That's the best place to talk about the debian packaging for this stuff. > I'm working on a patch for salsa.debian.org/debian/gpgme/, as I think this is > probably the best place for it. Sounds reasonable to me. > Basically, the two packages (chromium-gpgme and firefox-gpgme) just need to > ensure that the gpgme-json binary ships, and that a configuration file is > present at paths the browsers like. > > My question: > Is it okay and maintainable to add "approved" extension ids (in this case, > mailvelope) to these configuration files? > > In the end, it is an authorization between the extension(s) and the browser > (based on ids assigned by the browser publisher). > gpgme-json itself does not care who communicates with them (as long as it stays > the same actor). Still, I have the feelings that some link between worlds is > created that may not be desired. This is an excellent question, and one that i did not figure out the answer to when i was briefly researching the situation. I wonder whether it makes more sense (and whether it's possible) to ship the gpgme-json binary and wrapper files in one package, without any "approved" extension IDs. And then in the extension-specific package (e.g. the "mailvelope" package), include the approved extension IDs. Does that even make sense? I don't remember the exact layouts expected. Thanks for stepping up to do this work! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rjh at sixdemonbag.org Fri Jul 12 23:12:58 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 12 Jul 2019 17:12:58 -0400 Subject: Crash on no input specified Message-ID: <76e10fbb-502e-2095-da09-f54e3621ffdf@sixdemonbag.org> While doing some testing on Fedora 30, I came across an interesting defect: I can concoct a list of recipients which, if used without a file specified on the command line, results in both output written to the screen and a hard crash. GnuPG 2.2.16 using libgcrypt 1.8.4. ===== [rjh at localhost ~]$ gpg --armor --encrypt --sign --trust-model always -r 0x43F54688E0C5670C -r 0xE045FE37AD62C09F -r 0xB1B51B00227E6279 -r 0x5A11CC0668C218E6 -r 0x5CE84B8A08DA0BBA -r 0xA52C55A2525A9864 -r 0xB6ABE088B62E904D -r 0x2925BBE582874330 -r 0xEECF453F78E1E99B gpg: pubkey_encrypt failed: Provided object is too short -----BEGIN PGP MESSAGE----- [much output snipped] KtNV31DFkcpeBy1iGfqKfu3acoTYufpjteR73Ogpg: pubkey_encrypt failed: Provided object is too short gpg: Ohhhh jeeee: Assertion "a->filter == block_filter" in iobuf_set_partial_body_length_mode failed (iobuf.c:2528) Aborted (core dumped) ===== Running this within gdb gives: ===== Program received signal SIGABRT, Aborted. __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 return ret; (gdb) backtrace #0 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff7b13895 in __GI_abort () at abort.c:79 #2 0x00005555555fe370 in do_logv (level=6, ignore_arg_ptr=ignore_arg_ptr at entry=0, extrastring=, extrastring at entry=0x0, prefmt=prefmt at entry=0x0, fmt=, fmt at entry=0x555555636288 "Assertion \"%s\" in %s failed (%s:%d)\n", arg_ptr=arg_ptr at entry=0x7fffffffbc60) at logging.c:859 #3 0x00005555555fedd1 in log_log (level=level at entry=6, fmt=fmt at entry=0x555555636288 "Assertion \"%s\" in %s failed (%s:%d)\n") at logging.c:872 #4 0x00005555555ff5a6 in _log_assert ( expr=expr at entry=0x55555563891e "a->filter == block_filter", file=file at entry=0x5555556385e2 "iobuf.c", line=line at entry=2528, func=func at entry=0x5555556389a0 <__FUNCTION__.10483> "iobuf_set_partial_body_length_mode") at logging.c:1091 #5 0x000055555560be32 in iobuf_set_partial_body_length_mode ( a=a at entry=0x555555676820, len=len at entry=0) at iobuf.c:2539 #6 0x000055555557bcb3 in do_plaintext (pt=, ctb=, out=) at build-packet.c:758 #7 build_packet (out=out at entry=0x555555676820, pkt=pkt at entry=0x7fffffffbdd0) at build-packet.c:153 #8 0x00005555555b49a6 in write_plaintext_packet (out=0x555555676820, inp=inp at entry=0x5555556769b0, fname=fname at entry=0x0, ptmode=98) at sign.c:678 #9 0x00005555555b653c in sign_file (ctrl=0x555555665090, filenames=0x0, detached=, locusr=, encryptflag=1, remusr=, outfile=0x0) at sign.c:1066 #10 0x000055555556a668 in main (argc=, argv=) at gpg.c:4240 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From henning.schild at siemens.com Thu Jul 18 16:58:20 2019 From: henning.schild at siemens.com (Henning Schild) Date: Thu, 18 Jul 2019 16:58:20 +0200 Subject: gpgsm: decrypting session key failed: Invalid session key Message-ID: <20190718165820.456e2c70@md1za8fc.ad001.siemens.net> Hi, this is a bug report email, at least i expect it is a bug. An increasing amount of x509 encrypted email i receive can not be decrypted with gpgsm anymore. At first i assumed that the senders keys would be somehow different and trigger the bug in gpgsm. Later i found that it could also be their mail client, but whatever it is on the remote end i expect it to be a bug in gpgsm. The same files can be decrypted with openssl just fine. Affected versions: gpgsm <= latest master (gnupg-2.2.7-609-g4195ce15f) Platform Linux: x86_64 Expected result: Mail can be decrypted and read. Actual result: Decryption fails with "gpgsm: decrypting session key failed: Invalid session key" Details: (from latest git build) $ /foo/gnupg/sm/gpgsm --debug-level guru --decrypt smime_bad.p7m ... gpgsm: DBG: chan_5 -> PKDECRYPT gpgsm: DBG: chan_5 <- S INQUIRE_MAXLEN 4096 gpgsm: DBG: chan_5 <- INQUIRE CIPHERTEXT gpgsm: DBG: chan_5 -> [ 44 20 28 37 3a 65 6e 63 2d 76 61 6c 28 33 3a 72 ...(273 byte(s) skipped) ] gpgsm: DBG: chan_5 -> END Vim: Reading from stdin... gpgsm: DBG: chan_5 <- S PADDING 0 gpgsm: DBG: chan_5 <- [ 44 20 28 35 3a 76 61 6c 75 65 33 32 3a e5 ff cd ...(31 byte(s) skipped) ] gpgsm: DBG: chan_5 <- OK gpgsm: DBG: pkcs1 encoded session key: e5ffcd51107897682fc0d805173d85ce7088fddabda33ac74da73b0813c04593 gpgsm: decrypting session key failed: Invalid session key gpgsm: message decryption failed: Invalid session key Hope that helps. I would be happy to provide more information. I have many of those _bad.p7m files. regards, Henning From henning.schild at siemens.com Wed Jul 24 10:46:28 2019 From: henning.schild at siemens.com (Henning Schild) Date: Wed, 24 Jul 2019 10:46:28 +0200 Subject: gpgsm: decrypting session key failed: Invalid session key In-Reply-To: <20190718165820.456e2c70@md1za8fc.ad001.siemens.net> References: <20190718165820.456e2c70@md1za8fc.ad001.siemens.net> Message-ID: <20190724104628.617360b6@md1za8fc.ad001.siemens.net> Should i rather open an issue on https://dev.gnupg.org/. I think i read somewhere that this list can be/is used for reporting bugs. regards, Henning Am Thu, 18 Jul 2019 16:58:20 +0200 schrieb Henning Schild via Gnupg-devel : > Hi, > > this is a bug report email, at least i expect it is a bug. > > An increasing amount of x509 encrypted email i receive can not be > decrypted with gpgsm anymore. At first i assumed that the senders keys > would be somehow different and trigger the bug in gpgsm. Later i found > that it could also be their mail client, but whatever it is on the > remote end i expect it to be a bug in gpgsm. > The same files can be decrypted with openssl just fine. > > Affected versions: gpgsm <= latest master (gnupg-2.2.7-609-g4195ce15f) > Platform Linux: x86_64 > > Expected result: > Mail can be decrypted and read. > > Actual result: > Decryption fails with "gpgsm: decrypting session key failed: Invalid > session key" > > Details: (from latest git build) > $ /foo/gnupg/sm/gpgsm --debug-level guru --decrypt smime_bad.p7m > ... > gpgsm: DBG: chan_5 -> PKDECRYPT > gpgsm: DBG: chan_5 <- S INQUIRE_MAXLEN 4096 > gpgsm: DBG: chan_5 <- INQUIRE CIPHERTEXT > gpgsm: DBG: chan_5 -> [ 44 20 28 37 3a 65 6e 63 2d 76 61 6c 28 33 3a > 72 ...(273 byte(s) skipped) ] gpgsm: DBG: chan_5 -> END > Vim: Reading from stdin... > gpgsm: DBG: chan_5 <- S PADDING 0 > gpgsm: DBG: chan_5 <- [ 44 20 28 35 3a 76 61 6c 75 65 33 32 3a e5 ff > cd ...(31 byte(s) skipped) ] gpgsm: DBG: chan_5 <- OK > gpgsm: DBG: pkcs1 encoded session key: > e5ffcd51107897682fc0d805173d85ce7088fddabda33ac74da73b0813c04593 > gpgsm: decrypting session key failed: Invalid session key gpgsm: > message decryption failed: Invalid session key > > > Hope that helps. I would be happy to provide more information. I have > many of those _bad.p7m files. > > regards, > Henning > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From gniibe at fsij.org Fri Jul 26 04:43:38 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 26 Jul 2019 11:43:38 +0900 Subject: gpgsm: decrypting session key failed: Invalid session key In-Reply-To: <20190718165820.456e2c70@md1za8fc.ad001.siemens.net> References: <20190718165820.456e2c70@md1za8fc.ad001.siemens.net> Message-ID: <87o91hqzvp.fsf@iwagami.gniibe.org> Henning Schild via Gnupg-devel wrote: > An increasing amount of x509 encrypted email i receive can not be > decrypted with gpgsm anymore. Is there any change of cipher used? > Details: (from latest git build) > $ /foo/gnupg/sm/gpgsm --debug-level guru --decrypt smime_bad.p7m > ... > gpgsm: DBG: chan_5 -> PKDECRYPT > gpgsm: DBG: chan_5 <- S INQUIRE_MAXLEN 4096 > gpgsm: DBG: chan_5 <- INQUIRE CIPHERTEXT > gpgsm: DBG: chan_5 -> [ 44 20 28 37 3a 65 6e 63 2d 76 61 6c 28 33 3a 72 ...(273 byte(s) skipped) ] > gpgsm: DBG: chan_5 -> END > Vim: Reading from stdin... > gpgsm: DBG: chan_5 <- S PADDING 0 > gpgsm: DBG: chan_5 <- [ 44 20 28 35 3a 76 61 6c 75 65 33 32 3a e5 ff cd ...(31 byte(s) skipped) ] > gpgsm: DBG: chan_5 <- OK > gpgsm: DBG: pkcs1 encoded session key: e5ffcd51107897682fc0d805173d85ce7088fddabda33ac74da73b0813c04593 > gpgsm: decrypting session key failed: Invalid session key > gpgsm: message decryption failed: Invalid session key The encoded session key is 32-byte, which looks like a key of AES-256. My guess is, this is the point where we need a fix: diff --git a/sm/decrypt.c b/sm/decrypt.c index ec9800840..af509fea1 100644 --- a/sm/decrypt.c +++ b/sm/decrypt.c @@ -75,7 +75,7 @@ prepare_decryption (ctrl_t ctrl, const char *hexkeygrip, const char *desc, log_printhex (seskey, seskeylen, "pkcs1 encoded session key:"); n=0; - if (seskeylen == 24 || seskeylen == 16) + if (seskeylen == 32 || seskeylen == 24 || seskeylen == 16) { /* Smells like a 3-DES or AES-128 key. This might happen * because a SC has already done the unpacking. A better -- From henning.schild at siemens.com Fri Jul 26 11:28:31 2019 From: henning.schild at siemens.com (Henning Schild) Date: Fri, 26 Jul 2019 11:28:31 +0200 Subject: gpgsm: decrypting session key failed: Invalid session key In-Reply-To: <87o91hqzvp.fsf@iwagami.gniibe.org> References: <20190718165820.456e2c70@md1za8fc.ad001.siemens.net> <87o91hqzvp.fsf@iwagami.gniibe.org> Message-ID: <20190726112831.42124049@md1za8fc.ad001.siemens.net> Am Fri, 26 Jul 2019 11:43:38 +0900 schrieb NIIBE Yutaka : > Henning Schild via Gnupg-devel wrote: > > An increasing amount of x509 encrypted email i receive can not be > > decrypted with gpgsm anymore. > > Is there any change of cipher used? I did not analyze further. It seems to be newer versions of Outlook that produce mail i can not decrypt anymore. > > Details: (from latest git build) > > $ /foo/gnupg/sm/gpgsm --debug-level guru --decrypt smime_bad.p7m > > ... > > gpgsm: DBG: chan_5 -> PKDECRYPT > > gpgsm: DBG: chan_5 <- S INQUIRE_MAXLEN 4096 > > gpgsm: DBG: chan_5 <- INQUIRE CIPHERTEXT > > gpgsm: DBG: chan_5 -> [ 44 20 28 37 3a 65 6e 63 2d 76 61 6c 28 33 > > 3a 72 ...(273 byte(s) skipped) ] gpgsm: DBG: chan_5 -> END > > Vim: Reading from stdin... > > gpgsm: DBG: chan_5 <- S PADDING 0 > > gpgsm: DBG: chan_5 <- [ 44 20 28 35 3a 76 61 6c 75 65 33 32 3a e5 > > ff cd ...(31 byte(s) skipped) ] gpgsm: DBG: chan_5 <- OK > > gpgsm: DBG: pkcs1 encoded session key: > > e5ffcd51107897682fc0d805173d85ce7088fddabda33ac74da73b0813c04593 > > gpgsm: decrypting session key failed: Invalid session key gpgsm: > > message decryption failed: Invalid session key > > The encoded session key is 32-byte, which looks like a key of AES-256. > > My guess is, this is the point where we need a fix: Sweet, that simple change did the trick! Do you know how to turn that into an upstream patch. My guess is that we are still talking about a dirty hack here and some documentation, test-cases need to updated. Maybe even more code to deal with AES-256 will be required? regards, Henning > diff --git a/sm/decrypt.c b/sm/decrypt.c > index ec9800840..af509fea1 100644 > --- a/sm/decrypt.c > +++ b/sm/decrypt.c > @@ -75,7 +75,7 @@ prepare_decryption (ctrl_t ctrl, const char > *hexkeygrip, const char *desc, log_printhex (seskey, seskeylen, > "pkcs1 encoded session key:"); > n=0; > - if (seskeylen == 24 || seskeylen == 16) > + if (seskeylen == 32 || seskeylen == 24 || seskeylen == 16) > { > /* Smells like a 3-DES or AES-128 key. This might happen > * because a SC has already done the unpacking. A better From dkg at fifthhorseman.net Mon Jul 29 21:40:50 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 29 Jul 2019 15:40:50 -0400 Subject: S-expressions, trailing NULs, libgcrypt and gpg-agent Message-ID: <878ssgtyrh.fsf@fifthhorseman.net> Hi GnuPG/libgcrypt folks-- i've been trying to dig more deeply into GnuPG and libgcrypt's use of S-expressions, in particular the inclusion of non-standard trailing NUL bytes. https://dev.gnupg.org/T4652 is one such example in GnuPG itself -- the S-expression returned by the agent in response to PKDECRYPT command contains an extra NUL byte -- but it looks like a potential issue baked deep in libgcrypt too. In particular, this line in _gcry_sexp_sprint() in src/sexp.c seems problematic: *d++ = 0; /* for convenience we make a C string */ The inclusion of a trailing NUL is clearly not called for by the traditional S-expression definitions or documentation (https://people.csail.mit.edu/rivest/Sexp.txt) which focuses on providing length-prefixed strings and other standardized formats that don't rely on a trailing NUL terminator (and indeed, may embed NUL bytes on their own). So a consumer of an S-expression that has a trailing NUL appended needs to do something special with it. This causes problems for things like nettle's sexp-conv tool: 0 dkg at alice:~$ printf '(3:abc)' | sexp-conv (abc) 0 dkg at alice:~$ printf '(3:abc)\0' | sexp-conv (abc) Invalid token. 1 dkg at alice:~$ The inclusion of a trailing NUL also seems to be an invitation to misparse the data, because legitimate S-expressions can contain embedded NULs, so there's no way to use a standard C-string function like strlen() on such an expression safely. That said, some S-expression parsers in C might use functions like strtol() or strtoul(), which are outright dangerous to use on an arbitrary buffer if you can't guarantee that some sort of terminating non-numeric character will be present in the stream (strtoul could read off the end of the buffer in that case). This is arguably a bug in strtoul(), but that's an issue with POSIX, which we can't fix here, other than to say "don't use it for parsing arbitrary potentially-adversarial S-expression-like-things". But it's more than a little ironic to fail at parsing a canonically-length-prefixed format due to a missing delimiter :( The right answer seems to be to demand that all S-expression parsers be aggressively defensive when parsing S-expressions, especially from an unknown source. Sadly, libgcrypt explicitly documents the spurious trailing NUL byte in its API: -- Function: size_t gcry_sexp_sprint (gcry_sexp_t SEXP, int MODE, char *BUFFER, size_t MAXLENGTH) Copies the S-expression object SEXP into BUFFER using the format specified in MODE. MAXLENGTH must be set to the allocated length of BUFFER. The function returns the actual length of valid bytes put into BUFFER or 0 if the provided buffer is too short. Passing 'NULL' for BUFFER returns the required length for BUFFER. For convenience reasons an extra byte with value 0 is appended to the buffer. I'm not sure what "convenience" is intended to mean here -- but it looks to me like a hassle for users of libgcrypt. The user that consumes such a buffer cannot use a standard S-expression parser on the result (because of the spurious trailing NUL), but they also can't treat it as a NUL-terminated string. Even weirder, gcry_sexp_sprint () returns a different length value when invoked with BUFFER = NULL than it does when MAXLENGTH is as large as it needs to be. (e.g. when BUFFER == NULL, it might return 4, but when supplying it with a large enough buffer to write in, it will return 3 -- but will also write a NUL byte to the fourth octet). No such documentation is available for clients of gpg-agent who want to use PKDECRYPT or PKSIGN, though. I don't know what justifies the inclusion of the extra trailing NUL byte there. These idiosyncrasies make it difficult for a user of gcrypt or client of gpg-agent to reliably consume an S-expression with any standards-compliant S-expression tools/parsers, because they have to know about and keep track of this odd variation. If the goal is interoperability with other tools, it would be great to be able to reduce the cognitive load on adopters. How to fix? ----------- I'm struggling to imagine how this could be safely corrected, because the documentation is explicit about baking in the bug. I guess an SONAME bump for gcrypt might be appropriate, but i also can't imagine being confident in fixing anything that relies on this behavior because it is a subtle difference and not easy to catch in an automated way (not like a change in the arguments to a function, or a function rename). A cleaner fix on the libgcrypt side would be to add a new function: gcry_sexp_sprint2 (gcry_sexp_t SEXP, int MODE, char *BUFFER, size_t MAXLENGTH) which is identical to gcry_sexp_sprint () except that it does not add the trailng NUL byte. Then you could deprecate gcry_sexp_sprint, and callers could convert to the new one explicitly, without requiring an SONAME bump. When the project is ready to fully remove gcry_sexp_sprint(), that can happen at the next SONAME bump. I don't really know to fix gpg-agent's PKDECRYPT or PKSIGN functions safely. As Andre points out in T4652, due to forwarded agents, we can't guarantee that we're talking to the same version of the backend. It looks like we could add an option to PKDECRYPT to return the value without a trailing NUL (invoked as "pkdecrypt --no-trailing-nul" or something), but i don't know how you'd know as a client of the agent whether that's possible or not ("getinfo cmd_has_option" appears to be unreliable: https://dev.gnupg.org/T4661). Perhaps an additional OPTION would be better, so a caller can test at runtime? But pretty much all of my ideas here involve at least one additional roundtrip between the agent and the client of the agent, which -- especially for high-latency forwarded connections -- adds to the lag of an operation that is already one of the elements that makes gpg slower than it needs to be. Short term takeaway? -------------------- Anyway, i think my conclusion for the short term is that anyone parsing S-expressions from GnuPG or libgcrypt needs to assume that there will be an extra trailing NUL that needs to be stripped off before handling. If the overall S-expression is expected to be a list and not an atom, it is probably safe to simply strip all trailing NUL(s?) backwards, down to the trailing close-paren. However, if the overall S-expression might just be an atom, the only option is to assume that a single literal NUL has been added to the end, and to explicitly strip ignore it, until we get a cleaner resolution for the long term. (otherwise you could get into trouble when parsing a token like `4:abc\0\0' and "overstrip" the NUL that is part of the intended literal) Does anyone see any cleaner way out of this situation for users that interact with either the agent or libgcrypt? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: