From wk at gnupg.org Fri May 3 10:42:49 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 May 2019 10:42:49 +0200 Subject: Trust model tofu+pgp and User ID in Signer's UID packet In-Reply-To: <684177cc-36b5-7d6c-8ff1-4f37dbeb765d@metacode.biz> (Wiktor Kwapisiewicz via Gnupg-devel's message of "Thu, 25 Apr 2019 13:48:18 +0200") References: <684177cc-36b5-7d6c-8ff1-4f37dbeb765d@metacode.biz> Message-ID: <87lfzo53p2.fsf@wheatstone.g10code.de> On Thu, 25 Apr 2019 13:48, gnupg-devel at gnupg.org said: > As I've seen previously OpenKeychain embeds full User ID as Signer's > UID (that is "John Doe ") but GnuPG users only They should not do that becuase only the addrspec identifies the user. The real name in a mail address is often changed. > e-mail ("john at example.com"). It seems when GnuPG encounters Signer's > UID in full form it cannot get TOFU validity. Right, in gpg the user id from the signature is only sanitized of bad characters and then used verbatim. Using only the addrspec part, if it exists, is a better idea. I 'll change that for 2.2. 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 May 3 10:57:00 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 May 2019 10:57:00 +0200 Subject: Trust model tofu+pgp and User ID in Signer's UID packet In-Reply-To: <684177cc-36b5-7d6c-8ff1-4f37dbeb765d@metacode.biz> (Wiktor Kwapisiewicz via Gnupg-devel's message of "Thu, 25 Apr 2019 13:48:18 +0200") References: <684177cc-36b5-7d6c-8ff1-4f37dbeb765d@metacode.biz> Message-ID: <87h8ab6hlv.fsf@wheatstone.g10code.de> Hi, the attached patch is for master but it should also apply to 2.2. Would you be so kind and give it a try? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-Use-just-the-addrspec-from-the-Signer-s-UID.patch Type: text/x-diff Size: 1721 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 Fri May 3 13:20:30 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Fri, 3 May 2019 13:20:30 +0200 Subject: Trust model tofu+pgp and User ID in Signer's UID packet In-Reply-To: <87h8ab6hlv.fsf@wheatstone.g10code.de> References: <684177cc-36b5-7d6c-8ff1-4f37dbeb765d@metacode.biz> <87h8ab6hlv.fsf@wheatstone.g10code.de> Message-ID: <9bf14ef6-e13f-e482-49d7-92bec115c9ed@metacode.biz> Hi Werner, On 03.05.2019 10:57, Werner Koch wrote: > the attached patch is for master but it should also apply to 2.2. Would > you be so kind and give it a try? I did try it on master and yes, it does work. The message printed changes from (before patch): gpg: Good signature from "John Doe " [full] gpg: WARNING: We do NOT trust this key! gpg: The signature is probably a FORGERY. To this (after patching): gpg: Good signature from "John Doe " [full] gpg: john at example.com: Verified 2 signatures in the past 59 minutes. Encrypted 0 messages. Thanks for the quick fix! For the record it seems there is a minor issue when the patch is applied on 2.2.15 as mailbox_from_userid changed the number of arguments. 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 Fri May 3 15:49:31 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 May 2019 15:49:31 +0200 Subject: Trust model tofu+pgp and User ID in Signer's UID packet In-Reply-To: <9bf14ef6-e13f-e482-49d7-92bec115c9ed@metacode.biz> (Wiktor Kwapisiewicz's message of "Fri, 3 May 2019 13:20:30 +0200") References: <684177cc-36b5-7d6c-8ff1-4f37dbeb765d@metacode.biz> <87h8ab6hlv.fsf@wheatstone.g10code.de> <9bf14ef6-e13f-e482-49d7-92bec115c9ed@metacode.biz> Message-ID: <87y33n4phw.fsf@wheatstone.g10code.de> On Fri, 3 May 2019 13:20, wiktor at metacode.biz said: > I did try it on master and yes, it does work. Thanks for testing. > For the record it seems there is a minor issue when the patch is > applied on 2.2.15 as mailbox_from_userid changed the number of > arguments. Possible, I didn't tried. 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 May 3 16:10:48 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 May 2019 16:10:48 +0200 Subject: Is ECC ready and increase the default RSA key size to 3072 bits? In-Reply-To: <201904250842.18173.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 25 Apr 2019 08:42:13 +0200") References: <20190418072148.GN1226@zeromail.org> <87o952xfxm.fsf@fifthhorseman.net> <201904250842.18173.bernhard@intevation.de> Message-ID: <87r29f4oif.fsf@wheatstone.g10code.de> On Thu, 25 Apr 2019 08:42, bernhard at intevation.de said: > Is ECC ready to be the default? > My estimation is: It is not, and then we should switch the default to RSA3072 > until it is. 2.3 will use ed25519/cv25519 as default algorithms for new keys. All other major implementations support ed25519 and thus we are ready to switch this summer. 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 wk at gnupg.org Fri May 3 16:18:21 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 May 2019 16:18:21 +0200 Subject: [PATCH] doc: clarify dirmngr use-tor documentation In-Reply-To: <20190419142149.8679-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 19 Apr 2019 10:21:49 -0400") References: <20190419142149.8679-1-dkg@fifthhorseman.net> Message-ID: <87muk34o5u.fsf@wheatstone.g10code.de> On Fri, 19 Apr 2019 10:21, dkg at fifthhorseman.net said: > reloading dirmngr wouldn't allow me to clear --use-tor. Does that > mean i just need to restart dirmngr to clear --use-tor, instead of > reloading? Is that a deliberate design decision, or an accident of > implementation? If it's deliberate, what do i (as a user) gain from Right. You need to restart dirmngr and it is not sufficient to SIGHUP it. This is to make it extra hard to bypass Tor if it has been used before in this session. > -or even be reloading gpg-agent. The use of @option{--no-use-tor} > +or even by reloading dirmngr. The use of @option{--no-use-tor} Thanks. Fixed. 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 May 3 16:26:23 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 May 2019 16:26:23 +0200 Subject: Storing key on multiple smartcards In-Reply-To: <87pnpeodk1.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of "Mon, 22 Apr 2019 13:43:10 +0900") References: <87tvf6loi8.fsf@iwagami.gniibe.org> <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com> <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com> <87zhomg44u.fsf@iwagami.gniibe.org> <7b36dcc1-6c8e-a83d-8dc2-a26c4cb9e65e@tsundere.moe> <87pnpeodk1.fsf@iwagami.gniibe.org> Message-ID: <87imur4nsg.fsf@wheatstone.g10code.de> On Mon, 22 Apr 2019 13:43, gniibe at fsij.org said: > Then, we don't need the serial number as shadow-info in private key file. The information is also used to prompt the user to insert a specific card. The serial number is a good way to identify a card because it is printed onto the card. However some configurable way to name a card is also useful. I am currently working on recording all serial numbers used with a token based key in the shadow key info file. The new format allows easy manual editing of that info and also allows to put a "Label:" line into the the file to be prompted with e.g. "The green token on my keyring". 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 dkg at fifthhorseman.net Fri May 3 16:50:01 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 03 May 2019 10:50:01 -0400 Subject: [PATCH] doc: clarify dirmngr use-tor documentation In-Reply-To: <87muk34o5u.fsf@wheatstone.g10code.de> References: <20190419142149.8679-1-dkg@fifthhorseman.net> <87muk34o5u.fsf@wheatstone.g10code.de> Message-ID: <87k1f7oana.fsf@fifthhorseman.net> On Fri 2019-05-03 16:18:21 +0200, Werner Koch wrote: > On Fri, 19 Apr 2019 10:21, dkg at fifthhorseman.net said: > >> reloading dirmngr wouldn't allow me to clear --use-tor. Does that >> mean i just need to restart dirmngr to clear --use-tor, instead of >> reloading? Is that a deliberate design decision, or an accident of >> implementation? If it's deliberate, what do i (as a user) gain from > > Right. You need to restart dirmngr and it is not sufficient to SIGHUP > it. This is to make it extra hard to bypass Tor if it has been used > before in this session. Thanks for thinking about this! This isn't "extra hard" though -- it just means "gpgconf --kill dirmngr" instead of "gpgconf --reload dirmngr", right? (or SIGTERM instead of SIGHUP) Is this marginal increase in "hardness" worth the additional confusion and complexity in configuration? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From robbat2 at gentoo.org Mon May 6 06:25:23 2019 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Mon, 6 May 2019 04:25:23 +0000 Subject: Storing key on multiple smartcards In-Reply-To: <87imur4nsg.fsf@wheatstone.g10code.de> References: <87tvf6loi8.fsf@iwagami.gniibe.org> <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com> <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com> <87zhomg44u.fsf@iwagami.gniibe.org> <7b36dcc1-6c8e-a83d-8dc2-a26c4cb9e65e@tsundere.moe> <87pnpeodk1.fsf@iwagami.gniibe.org> <87imur4nsg.fsf@wheatstone.g10code.de> Message-ID: On Fri, May 03, 2019 at 04:26:23PM +0200, Werner Koch wrote: > On Mon, 22 Apr 2019 13:43, gniibe at fsij.org said: > > > Then, we don't need the serial number as shadow-info in private key file. > > The information is also used to prompt the user to insert a specific > card. The serial number is a good way to identify a card because it is > printed onto the card. However some configurable way to name a card is > also useful. It's NOT always printed on cards. I have multiple NitroKey Pro units, and aside from my own labelling, there are no unit-specific identifiers on the units themselves, or even on the internal cards. Consider me entirely in favour of being able to specify an arbitrary label. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robbat2 at gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1113 bytes Desc: not available URL: From bernhard at intevation.de Mon May 6 08:55:05 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 6 May 2019 08:55:05 +0200 Subject: Is ECC ready and increase the default RSA key size to 3072 bits? In-Reply-To: <87r29f4oif.fsf@wheatstone.g10code.de> References: <20190418072148.GN1226@zeromail.org> <201904250842.18173.bernhard@intevation.de> <87r29f4oif.fsf@wheatstone.g10code.de> Message-ID: <201905060855.05674.bernhard@intevation.de> Am Freitag 03 Mai 2019 16:10:48 schrieb Werner Koch: > On Thu, 25 Apr 2019 08:42, bernhard at intevation.de said: > > Is ECC ready to be the default? > > My estimation is: It is not, and then we should switch the default to > > RSA3072 until it is. > > 2.3 will use ed25519/cv25519 as default algorithms for new keys. ?All > other major implementations support ed25519 and thus we are ready to > switch this summer. What will the status of a 2.3.0 release be? (Is it a "development" line or ready for packaging?) Would it make sense to announce the step so people could flag potential implementations that may be interesting from an interoperability side? 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 gniibe at fsij.org Tue May 7 03:21:41 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 07 May 2019 10:21:41 +0900 Subject: Storing key on multiple smartcards In-Reply-To: <87imur4nsg.fsf@wheatstone.g10code.de> References: <87tvf6loi8.fsf@iwagami.gniibe.org> <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com> <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com> <87zhomg44u.fsf@iwagami.gniibe.org> <7b36dcc1-6c8e-a83d-8dc2-a26c4cb9e65e@tsundere.moe> <87pnpeodk1.fsf@iwagami.gniibe.org> <87imur4nsg.fsf@wheatstone.g10code.de> Message-ID: <871s1bnjoa.fsf@iwagami.gniibe.org> Hello, I merged the scdaemon change of mine to master. Now, PKSIGN/PKAUTH/PKDECRYPT command can be used with KEYGRIP directly, and it is scdaemon which selects card (among possibly multiple cards). Werner Koch wrote: > The information is also used to prompt the user to insert a specific > card. The serial number is a good way to identify a card because it is > printed onto the card. However some configurable way to name a card is > also useful. > > I am currently working on recording all serial numbers used with a token > based key in the shadow key info file. The new format allows easy > manual editing of that info and also allows to put a "Label:" line into > the the file to be prompted with e.g. "The green token on my keyring". Yes. Support of label (and serial number) is orthogonal to ongoing change of mine. * * * My plan to change gpg-agent is: By gpg-agent's offering private key information in a better way, gpg frontend can be modified to select a key easier (so that user can have better UI). Now, gpg-agent KEYINFO command is like this: # KEYINFO [--[ssh-]list] [--data] [--ssh-fpr[=algo]] [--with-ssh] # # Return information about the key specified by the KEYGRIP. If the # key is not available GPG_ERR_NOT_FOUND is returned. If the option # --list is given the keygrip is ignored and information about all # available keys are returned. If --ssh-list is given information # about all keys listed in the sshcontrol are returned. With --with-ssh # information from sshcontrol is always added to the info. Unless --data # is given, the information is returned as a status line using the format: # # KEYINFO # # KEYGRIP is the keygrip. # # TYPE is describes the type of the key: # 'D' - Regular key stored on disk, # 'T' - Key is stored on a smartcard (token), # 'X' - Unknown type, # '-' - Key is missing. # # SERIALNO is an ASCII string with the serial number of the # smartcard. If the serial number is not known a single # dash '-' is used instead. # # IDSTR is the IDSTR used to distinguish keys on a smartcard. If it # is not known a dash is used instead. # # CACHED is 1 if the passphrase for the key was found in the key cache. # If not, a '-' is used instead. # # PROTECTION describes the key protection type: # 'P' - The key is protected with a passphrase, # 'C' - The key is not protected, # '-' - Unknown protection. # # FPR returns the formatted ssh-style fingerprint of the key. It is only # printed if the option --ssh-fpr has been used. If ALGO is not given # to that option the default ssh fingerprint algo is used. Without the # option a '-' is printed. # # TTL is the TTL in seconds for that key or '-' if n/a. # # FLAGS is a word consisting of one-letter flags: # 'D' - The key has been disabled, # 'S' - The key is listed in sshcontrol (requires --with-ssh), # 'c' - Use of the key needs to be confirmed, # '-' - No flags given. # # More information may be added in the future. I'm going to modify this, to distinguish a key on card which is inserted, and a key on card which is not inserted. This can be either: (1) For key on inserted card, add another flag into FLAGS (say, 'A' for active), or (2) Introduce new TYPE (say, 'O' for offline) and change the semantics of 'T' meaning inserted card. Currently, both of gpg frontend and gpg-agent need to have code of loop for enumerating active cards. Using KEYINFO command of scdaemon, gpg-agent can merge card key information and disk key information. -- From andrewg at andrewg.com Tue May 7 16:14:10 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 7 May 2019 15:14:10 +0100 Subject: poldi localdb structure Message-ID: Hi, all. I just installed poldi on a new laptop for the first time in a while, and noticed that the structure of the localdb is unfriendly, particularly now that the command line tools are no longer available. At the moment, an entry is added to the `users` file mapping a userid onto a card id, and then a file is created under `keys` that maps the card id to the public key. Surely it makes more sense to map the userid directly onto the public key (cf. monkeysphere's `authorized_user_ids`), and then let scdaemon worry about which card contains the private key material? And if we're going that direction, why not use monkeysphere's user keyring as the localdb? O_o -- 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 wk at gnupg.org Wed May 8 08:18:57 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 08 May 2019 08:18:57 +0200 Subject: [PATCH] doc: clarify dirmngr use-tor documentation In-Reply-To: <87k1f7oana.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 03 May 2019 10:50:01 -0400") References: <20190419142149.8679-1-dkg@fifthhorseman.net> <87muk34o5u.fsf@wheatstone.g10code.de> <87k1f7oana.fsf@fifthhorseman.net> Message-ID: <87bm0d1nam.fsf@wheatstone.g10code.de> On Fri, 3 May 2019 10:50, dkg at fifthhorseman.net said: > This isn't "extra hard" though -- it just means "gpgconf --kill dirmngr" > instead of "gpgconf --reload dirmngr", right? (or SIGTERM instead of > SIGHUP) GPA and Kleopatra can do an reload automatically on changing an option. They don't provide a GUI element to restart dirmngr. > Is this marginal increase in "hardness" worth the additional confusion > and complexity in configuration? Probably not; we may change it in 2.3 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 wk at gnupg.org Wed May 8 08:26:04 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 08 May 2019 08:26:04 +0200 Subject: Storing key on multiple smartcards In-Reply-To: <871s1bnjoa.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of "Tue, 07 May 2019 10:21:41 +0900") References: <87tvf6loi8.fsf@iwagami.gniibe.org> <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com> <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com> <87zhomg44u.fsf@iwagami.gniibe.org> <7b36dcc1-6c8e-a83d-8dc2-a26c4cb9e65e@tsundere.moe> <87pnpeodk1.fsf@iwagami.gniibe.org> <87imur4nsg.fsf@wheatstone.g10code.de> <871s1bnjoa.fsf@iwagami.gniibe.org> Message-ID: <877eb11myr.fsf@wheatstone.g10code.de> On Tue, 7 May 2019 10:21, gniibe at fsij.org said: > # TYPE is describes the type of the key: > # 'D' - Regular key stored on disk, > # 'T' - Key is stored on a smartcard (token), > # 'X' - Unknown type, > # '-' - Key is missing. > # > # SERIALNO is an ASCII string with the serial number of the > # smartcard. If the serial number is not known a single > # dash '-' is used instead. > # > # IDSTR is the IDSTR used to distinguish keys on a smartcard. If it > # is not known a dash is used instead. > # > # CACHED is 1 if the passphrase for the key was found in the key cache. > # If not, a '-' is used instead. > # > # PROTECTION describes the key protection type: > # 'P' - The key is protected with a passphrase, > # 'C' - The key is not protected, > # '-' - Unknown protection. > # > # FPR returns the formatted ssh-style fingerprint of the key. It is only > # printed if the option --ssh-fpr has been used. If ALGO is not given > # to that option the default ssh fingerprint algo is used. Without the > # option a '-' is printed. > # > # TTL is the TTL in seconds for that key or '-' if n/a. > # > # FLAGS is a word consisting of one-letter flags: > # 'D' - The key has been disabled, > # 'S' - The key is listed in sshcontrol (requires --with-ssh), > # 'c' - Use of the key needs to be confirmed, > # '-' - No flags given. > # > # More information may be added in the future. > > I'm going to modify this, to distinguish a key on card which is > inserted, and a key on card which is not inserted. This can be either: > > (1) For key on inserted card, add another flag into FLAGS (say, 'A' for > active), I think that is the proper solution. > (2) Introduce new TYPE (say, 'O' for offline) and change the semantics > of 'T' meaning inserted card. Alsthough I don't think we will run into problems with that it is not as clear as using an extra flag. 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 dkg at fifthhorseman.net Wed May 8 13:57:42 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 08 May 2019 07:57:42 -0400 Subject: [PATCH] doc: clarify dirmngr use-tor documentation In-Reply-To: <87bm0d1nam.fsf@wheatstone.g10code.de> References: <20190419142149.8679-1-dkg@fifthhorseman.net> <87muk34o5u.fsf@wheatstone.g10code.de> <87k1f7oana.fsf@fifthhorseman.net> <87bm0d1nam.fsf@wheatstone.g10code.de> Message-ID: <87ef59yx8p.fsf@fifthhorseman.net> On Wed 2019-05-08 08:18:57 +0200, Werner Koch wrote: > On Fri, 3 May 2019 10:50, dkg at fifthhorseman.net said: > >> This isn't "extra hard" though -- it just means "gpgconf --kill dirmngr" >> instead of "gpgconf --reload dirmngr", right? (or SIGTERM instead of >> SIGHUP) > > GPA and Kleopatra can do an reload automatically on changing an option. > They don't provide a GUI element to restart dirmngr. so if you change this option in GPA or Kleopatra, it doesn't actually change? That sounds perplexing. >> Is this marginal increase in "hardness" worth the additional confusion >> and complexity in configuration? > > Probably not; we may change it in 2.3 Thanks. I've opened https://dev.gnupg.org/T4488 to track this issue. --dkg -------------- 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 May 8 15:23:08 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Wed, 08 May 2019 15:23:08 +0200 Subject: Trust deepths (tsign) Message-ID: Hi all. As we all know, with tsign, you can set a trust deepth and a trust domain. I did not find any way to change this options afterwards. Is this intented? Bernhard Reiter suggested I should ask this question on the developers list. I know, one can delete the key, reimport it an set a new trust lebel, but this seems not to be the best way, IMHO. Regards, Dirk -- Dirk Gottschalk Ardennenstrasse 25 52076 Aachen, Germany GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase.io: 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 dgouttegattat at incenp.org Wed May 8 17:16:35 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 8 May 2019 16:16:35 +0100 Subject: Trust deepths (tsign) In-Reply-To: References: Message-ID: <20190508151634.6rdzfxikduwa5cds@CHS-TMB-078.qmcr.qmul.ac.uk> Hi, On Wed, May 08, 2019 at 03:23:08PM +0200, Dirk Gottschalk via Gnupg-devel wrote: >As we all know, with tsign, you can set a trust deepth and a trust >domain. > >I did not find any way to change this options afterwards. Is this >intented? Yes. A trust signature (tsign) is first and foremost, well, a signature. You cannot change it after it has been emitted. >I know, one can delete the key, reimport it an set a new trust lebel, >but this seems not to be the best way, IMHO. If the trust signature is only present on your own keyring (meaning that after signing the key you have not sent it back to its owner, or uploaded to a keyserver, or published it in any way), then you can simply delete the trust signature (`delsig` command in gpg's key editor). Otherwise, if the signature is already out, then there's no point in removing it from your keyring (any later refresh from a keyserver would import the signature back). What you can do instead is to *revoke* the first signature and then emit a new trust signature. Hope that helps, - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From look at my.amazin.horse Sun May 12 12:36:55 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sun, 12 May 2019 12:36:55 +0200 Subject: [PATCH GnuPG 1/2] gpg: fix fpr comparison in keyserver screener In-Reply-To: <20190512103655.25693-1-look@my.amazin.horse> References: <20190512103655.25693-1-look@my.amazin.horse> Message-ID: <20190512103655.25693-2-look@my.amazin.horse> * g10/keyserver.c (keyserver_retrieval_screener): Only compare actual fpr_len --- g10/keyserver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/g10/keyserver.c b/g10/keyserver.c index 04802d1a5..5b5cf1c13 100644 --- a/g10/keyserver.c +++ b/g10/keyserver.c @@ -1055,7 +1055,7 @@ keyserver_retrieval_screener (kbnode_t keyblock, void *opaque) { if (desc[n].mode == KEYDB_SEARCH_MODE_FPR) { - if (fpr_len == desc[n].fprlen && !memcmp (fpr, desc[n].u.fpr, 32)) + if (fpr_len == desc[n].fprlen && !memcmp (fpr, desc[n].u.fpr, fpr_len)) return 0; } else if (desc[n].mode == KEYDB_SEARCH_MODE_LONG_KID) -- 2.20.1 From look at my.amazin.horse Sun May 12 12:36:54 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sun, 12 May 2019 12:36:54 +0200 Subject: [PATCH gpg] allow import without user ids Message-ID: <20190512103655.25693-1-look@my.amazin.horse> This patch allows import of keys that have no user ids, if they are already known. This allows update of subkeys, revocation certificates, etc from sources that don't deal with user ids. See also https://dev.gnupg.org/T4393 Second commit is simple bugfix to the keyserver screener, which memcmp'd 32 bytes rather than the actual length of the fpr to compare. Signed-Off-By: Vincent Breitmoser From look at my.amazin.horse Sun May 12 12:36:56 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sun, 12 May 2019 12:36:56 +0200 Subject: [PATCH GnuPG 2/2] gpg: allow import of previously known keys, even without UIDs In-Reply-To: <20190512103655.25693-1-look@my.amazin.horse> References: <20190512103655.25693-1-look@my.amazin.horse> Message-ID: <20190512103655.25693-3-look@my.amazin.horse> * g10/import.c (import_one): Allow import of keys that have no user ids, if we already know them. Keys are still rejected if they contained invalid user ids, or none that pass a given filter criteria. --- g10/import.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/g10/import.c b/g10/import.c index 00bc47cc1..89ec18840 100644 --- a/g10/import.c +++ b/g10/import.c @@ -1806,16 +1806,6 @@ import_one (ctrl_t ctrl, log_printf ("\n"); } - - /* Unless import-drop-uids has been requested we don't allow import - * of a key without UIDs. */ - if (!uidnode && !(options & IMPORT_DROP_UIDS)) - { - if (!silent) - log_error( _("key %s: no user ID\n"), keystr_from_pk(pk)); - return 0; - } - if (screener && screener (keyblock, screener_arg)) { log_error (_("key %s: %s\n"), keystr_from_pk (pk), @@ -1888,9 +1878,9 @@ import_one (ctrl_t ctrl, } /* Delete invalid parts and without the drop option bail out if - * there are no user ids. */ + * there were user ids, but none was actually valid. */ if (!delete_inv_parts (ctrl, keyblock, keyid, options) - && !(options & IMPORT_DROP_UIDS) ) + && uidnode && !(options & IMPORT_DROP_UIDS) ) { if (!silent) { @@ -1985,6 +1975,13 @@ import_one (ctrl_t ctrl, err = 0; stats->skipped_new_keys++; } + else if (err && !uidnode && !(options & IMPORT_DROP_UIDS) ) + { + if (!silent) + log_info( _("key %s: new key but contains no user ID - skipped\n"), keystr(keyid)); + err = 0; + stats->no_user_id++; + } else if (err) /* Insert this key. */ { /* Note: ERR can only be NO_PUBKEY or UNUSABLE_PUBKEY. */ -- 2.20.1 From dkg at fifthhorseman.net Mon May 13 18:19:20 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 May 2019 12:19:20 -0400 Subject: [PATCH GnuPG 2/2] gpg: allow import of previously known keys, even without UIDs In-Reply-To: <20190512103655.25693-3-look@my.amazin.horse> References: <20190512103655.25693-1-look@my.amazin.horse> <20190512103655.25693-3-look@my.amazin.horse> Message-ID: <871s12wcmv.fsf@fifthhorseman.net> Thanks for this series, Vincent! I like the motivation behind it. I think it is concretely useful to import an OpenPGP certificate as part of a merge even if the incoming cert does not have a cryptographically-valid self-sig over any user ID. This permits the use of public keystores that perform the "redacting User IDs" mitigation described at https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03#section-5.1 In particular, it allows gpg to perform "Certificate Update with Redacted User IDs": https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03#section-5.1.1 (other operations later in section 5.1 that might involve synthesizing user IDs are not yet supported, even with this patch, and that's ok) It would be great to add a test to the test suite for this behavior -- to show what does *not* work before the patch is applied, and then to have the test suite succeed after the patches are applied. This would also help us avoid regressions on this behavior in the future. For example, here is a severely stripped down OpenPGP certificate. Just a primary key and one user ID and a self-sig: -----BEGIN PGP PUBLIC KEY BLOCK----- Comment: [A] primary key, user ID, and self-sig expiring in 2021 mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ 631VAN20CHRlc3Qga2V5iJYEExYIAD4WIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC XNmUGQIbAwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAIQ9qWmqja +0G1AQDdQiwhXxjXLMqoth+D4SigVHTJK8ORwifzsy3UE7mPGwD/aZ67XbAF/lgI kv2O1Jo0u9BL9RNNF+L0DM7rAFbfMAs= =1eII -----END PGP PUBLIC KEY BLOCK----- Here is a cert for the same primary key, but with a subkey and no user ID attached: -----BEGIN PGP PUBLIC KEY BLOCK----- Comment: [B] primary key, subkey, subkey binding sig (no user ID) mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ 631VAN24OARc2ZQhEgorBgEEAZdVAQUBAQdABsd5ha0AWXdXcSmfeiWIfrNcGqQK j++lwwWDAOlkVicDAQgHiHgEGBYIACAWIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC XNmUIQIbDAAKCRAIQ9qWmqja++vFAP98G1L+1/rWTGbsnxOAV2RocBYIroAvsbkR Ly6FdP8YNwEA7jOgT05CoKIe37MstpOz23mM80AK369Ca3JMmKKCQgg= =xuDu -----END PGP PUBLIC KEY BLOCK----- And here is a cert for the same primary key, with the user ID packet stripped entirely, but with updated self-sig (issued after the initial one) that contains a later expiration date over that same user ID: -----BEGIN PGP PUBLIC KEY BLOCK----- Comment: [C] primary key and self-sig expiring in 2024 (no user ID) mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ 631VAN2IlgQTFggAPgIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBLRpj5W8 2H/gSMzKKQhD2paaqNr7BQJc2ZR1BQkJZgHcAAoJEAhD2paaqNr79soA/0lWkUsu 3NLwgbni6EzJxnTzgeNMpljqNpipHAwfix9hAP93AVtFdC8g7hdUZxawobl9lnSN 9ohXOEBWvdJgVv2YAg== =KWIK -----END PGP PUBLIC KEY BLOCK----- If i do "gpg --import" on A, then B, then C, and then i do "gpg --edit-key test clean save" and "gpg --list-keys", i think gpg display have a merged certificate that expires in 2024, and has a subkey, like this: pub ed25519 2019-05-13 [SC] [expires: 2024-05-11] B4698F95BCD87FE048CCCA290843DA969AA8DAFB uid [ unknown] test key sub cv25519 2019-05-13 [E] but in practice, the imports of both B and C fail with: gpg: key 0843DA969AA8DAFB: no user ID and the result is instead the same as if only A were present: pub ed25519 2019-05-13 [SC] [expires: 2021-05-12] B4698F95BCD87FE048CCCA290843DA969AA8DAFB uid [ unknown] test key Feel free to use these example objects in the test suite if that's useful. On Sun 2019-05-12 12:36:56 +0200, Vincent Breitmoser wrote: > * g10/import.c (import_one): Allow import of keys that have no user ids, > if we already know them. Keys are still rejected if they contained > invalid user ids, or none that pass a given filter criteria. Your commit message here doesn't seem to match the intent of this patch, for several reasons: * It talks about several different keys, but it would be good to clarify in each circumstance whether we're talking about: a) the known copy of the OpenPGP certificate, b) the incoming copy of the OpenPGP certificate, or c) the merged copy of the OpenPGP certificate. * "contained invalid user ids" is different from "contained no valid user IDs" * "validity" for user IDs in the OpenPGP typically means something subtly different from "has a cryptographically correct self-sig from the primary key". It would be good to avoid mixing those up. As a nit-pick, i'd also convert the description to refer to the certificate in the singular instead of plural where possible, because it's easier to read and make sense of (esp. when the cert itself might have multiple elements internally). rewriting to what i *think* the intent of the series is, i'd have written it this way: * g10/import.c (import_one): Accept an incoming OpenPGP certificate that has no user id, as long as we already have a local variant of the cert that matches the primary key. Import still fails if the resulting merged certificate contains no self-signed user ids that pass any given filter criteria. Is this your intent? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ilf at zeromail.org Mon May 13 19:35:10 2019 From: ilf at zeromail.org (ilf) Date: Mon, 13 May 2019 19:35:10 +0200 Subject: Keyservers and GDPR In-Reply-To: <20180523092715.GC1663@zeromail.org> References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> Message-ID: <20190513173510.GA24471@zeromail.org> Almost one year ago, there was a big debate about the GDPR and keyservers. Now I would like to know: Did any keyserver admin(s) receive any (serious) GDPR-related complaint? Or even an official complaint by a data protection authority? Or even a penalty like a fine? I assume not, at least for the latter two. The fines by German DPAs have been rather low: https://www.welt.de/finanzen/article193326155/DSGVO-Verstoesse-Bundeslaender-ziehen-Bussgeld-Bilanz.html So far, I stand by last year's statement: > tl;dr: Keep calm and keep running keyservers. -- ilf If you upload your address book to "the cloud", I don't want to be in it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon May 13 19:44:11 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 May 2019 13:44:11 -0400 Subject: [PATCH GnuPG 2/2] gpg: allow import of previously known keys, even without UIDs In-Reply-To: <871s12wcmv.fsf@fifthhorseman.net> References: <20190512103655.25693-1-look@my.amazin.horse> <20190512103655.25693-3-look@my.amazin.horse> <871s12wcmv.fsf@fifthhorseman.net> Message-ID: <87sgtiuu50.fsf@fifthhorseman.net> On Mon 2019-05-13 12:19:20 -0400, Daniel Kahn Gillmor wrote: > It would be great to add a test to the test suite for this behavior -- > to show what does *not* work before the patch is applied, and then to > have the test suite succeed after the patches are applied. This would > also help us avoid regressions on this behavior in the future. Following up on this test regime, here are 2 additional OpenPGP certificates that use the same primary key and lack user IDs, but dealing with revocations of key material: -----BEGIN PGP PUBLIC KEY BLOCK----- Comment: [D] primary key, subkey, subkey revocation (no user ID) mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ 631VAN24OARc2ZQhEgorBgEEAZdVAQUBAQdABsd5ha0AWXdXcSmfeiWIfrNcGqQK j++lwwWDAOlkVicDAQgHiHgEKBYIACAWIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC XNmnkAIdAgAKCRAIQ9qWmqja+ylaAQDmIKf86BJEq4OpDqU+V9D+wn2cyuxbyWVQ 3r9LiL9qNwD/QAjyrhSN8L3Mfq+wdTHo5i0yB9ZCCpHLXSbhCqfWZwQ= =dwx2 -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP PUBLIC KEY BLOCK----- Comment: [E] primary key, revocation signature over primary (no user ID) mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ 631VAN2IeAQgFggAIBYhBLRpj5W82H/gSMzKKQhD2paaqNr7BQJc2ZQZAh0AAAoJ EAhD2paaqNr7qAwA/2jBUpnN0BxwRO/4CrxvrLIsL+C9aSXJUOTv8XkP4lvtAQD3 XsDFfFNgEueiTfF7HtOGt5LPmRqVvUpQSMVgJJW6CQ== =tM90 -----END PGP PUBLIC KEY BLOCK----- I believe that failing to import these revocation certificates represents a security risk to users of GnuPG, because it means leaving the user with a certificate that GnuPG knows is revoked, but it is left unrevoked. --dkg -------------- 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 May 13 21:38:23 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 May 2019 15:38:23 -0400 Subject: [PATCH GnuPG 1/2] gpg: fix fpr comparison in keyserver screener In-Reply-To: <20190512103655.25693-2-look@my.amazin.horse> References: <20190512103655.25693-1-look@my.amazin.horse> <20190512103655.25693-2-look@my.amazin.horse> Message-ID: <87lfzauouo.fsf@fifthhorseman.net> On Sun 2019-05-12 12:36:55 +0200, Vincent Breitmoser wrote: > * g10/keyserver.c (keyserver_retrieval_screener): Only compare actual > fpr_len > --- > g10/keyserver.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/g10/keyserver.c b/g10/keyserver.c > index 04802d1a5..5b5cf1c13 100644 > --- a/g10/keyserver.c > +++ b/g10/keyserver.c > @@ -1055,7 +1055,7 @@ keyserver_retrieval_screener (kbnode_t keyblock, void *opaque) > { > if (desc[n].mode == KEYDB_SEARCH_MODE_FPR) > { > - if (fpr_len == desc[n].fprlen && !memcmp (fpr, desc[n].u.fpr, 32)) > + if (fpr_len == desc[n].fprlen && !memcmp (fpr, desc[n].u.fpr, fpr_len)) > return 0; > } > else if (desc[n].mode == KEYDB_SEARCH_MODE_LONG_KID) fwiw, this looks like it is only relevant on the master branch (presumably used for testing v5 keys?) -- the STABLE-BRANCH-2-2 branch doesn't have this stanza. aiui, Vincent is saying here that uninitialized memory might be compared here in the case of a v4 fingerprint. I haven't tested this myself. I'd recommend considering this as a distinct change from the other patch in this series, rather than treating them as interdependent. --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 Wed May 15 07:30:54 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 15 May 2019 07:30:54 +0200 Subject: [PATCH GnuPG 1/2] gpg: fix fpr comparison in keyserver screener In-Reply-To: <87lfzauouo.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 13 May 2019 15:38:23 -0400") References: <20190512103655.25693-1-look@my.amazin.horse> <20190512103655.25693-2-look@my.amazin.horse> <87lfzauouo.fsf@fifthhorseman.net> Message-ID: <87pnokthbl.fsf@wheatstone.g10code.de> On Mon, 13 May 2019 15:38, dkg at fifthhorseman.net said: > aiui, Vincent is saying here that uninitialized memory might be compared > here in the case of a v4 fingerprint. I haven't tested this myself. Yep, the keyserver screen does not yet work in master. 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 gniibe at fsij.org Thu May 16 01:58:23 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 16 May 2019 08:58:23 +0900 Subject: Storing key on multiple smartcards In-Reply-To: <871s1bnjoa.fsf@iwagami.gniibe.org> References: <87tvf6loi8.fsf@iwagami.gniibe.org> <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com> <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com> <87zhomg44u.fsf@iwagami.gniibe.org> <7b36dcc1-6c8e-a83d-8dc2-a26c4cb9e65e@tsundere.moe> <87pnpeodk1.fsf@iwagami.gniibe.org> <87imur4nsg.fsf@wheatstone.g10code.de> <871s1bnjoa.fsf@iwagami.gniibe.org> Message-ID: <87sgtf1d9c.fsf@iwagami.gniibe.org> Hello, Before changing the output of KEYINFO command of gpg-agent (for T4244), I modified gpg-agent to relax the assumption/requirment of the map between serialno and keys. In GnuPG, so far, there used to be an assumption that serialno determines. Now, by the master commit of 1091f22511e1a8259eb5c998f5c207ee95723a4a , we can use a token for backup which has different serialno. I think that T4301 (using backup key in a different token) is now handled. I think that a bit more changes will be needed for better UI. For now, it is only possible to use back up token, when the token is active (after gpg --card-status [all]). Perhaps, it is better if KEYINFO command of scdaemon initiates card/token scanning at first. Let us consider more. T3416 would include other use cases. For using signing backup key in a different token, it should work well. For something like selecting key in an active token, gpg-frontend changes are needed as well. I keep considering about that. If any suggestion for a good solution, please let me know. -- From look at my.amazin.horse Tue May 21 20:03:08 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 21 May 2019 20:03:08 +0200 Subject: [PATCH v2 GnuPG] allow import without user ids In-Reply-To: <20190512103655.25693-1-look@my.amazin.horse> References: <20190512103655.25693-1-look@my.amazin.horse> Message-ID: <20190521180310.32443-1-look@my.amazin.horse> I included dkg's testing series, as expected the test only passes once the second patch is applied. Only three out of five of dkg's files are currently used: import of subkey revocations that have no binding signature, as well as out-of-place user id signatures, is out of scope for this patch. I included the others anyways, since may be userful later on (without regenerating the whole series). I also noticed that the way I handled invalid uids before didn't make much sense: just because there is some invalid uid in a key, doesn't mean cryptographically valid new packets can't be imported. I changed the patch to reflect that. Signed-Off-By: Vincent Breitmoser From look at my.amazin.horse Tue May 21 20:03:09 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 21 May 2019 20:03:09 +0200 Subject: [PATCH GnuPG 1/2] tests: Add test case for import without uid In-Reply-To: <20190521180310.32443-1-look@my.amazin.horse> References: <20190512103655.25693-1-look@my.amazin.horse> <20190521180310.32443-1-look@my.amazin.horse> Message-ID: <20190521180310.32443-2-look@my.amazin.horse> --- tests/openpgp/Makefile.am | 1 + tests/openpgp/import-incomplete.scm | 53 +++++++++++++++++++ .../import-incomplete/primary+revocation.asc | 9 ++++ .../primary+subkey+sub-revocation.asc | 10 ++++ .../import-incomplete/primary+subkey.asc | 10 ++++ .../import-incomplete/primary+uid-sig.asc | 10 ++++ .../openpgp/import-incomplete/primary+uid.asc | 10 ++++ 7 files changed, 103 insertions(+) create mode 100755 tests/openpgp/import-incomplete.scm create mode 100644 tests/openpgp/import-incomplete/primary+revocation.asc create mode 100644 tests/openpgp/import-incomplete/primary+subkey+sub-revocation.asc create mode 100644 tests/openpgp/import-incomplete/primary+subkey.asc create mode 100644 tests/openpgp/import-incomplete/primary+uid-sig.asc create mode 100644 tests/openpgp/import-incomplete/primary+uid.asc diff --git a/tests/openpgp/Makefile.am b/tests/openpgp/Makefile.am index e5be42b41..d886bc8f7 100644 --- a/tests/openpgp/Makefile.am +++ b/tests/openpgp/Makefile.am @@ -78,6 +78,7 @@ XTESTS = \ gpgv-forged-keyring.scm \ armor.scm \ import.scm \ + import-incomplete.scm \ import-revocation-certificate.scm \ ecc.scm \ 4gb-packet.scm \ diff --git a/tests/openpgp/import-incomplete.scm b/tests/openpgp/import-incomplete.scm new file mode 100755 index 000000000..d40229362 --- /dev/null +++ b/tests/openpgp/import-incomplete.scm @@ -0,0 +1,53 @@ +#!/usr/bin/env gpgscm + +;; Copyright (C) 2016 g10 Code GmbH +;; +;; This file is part of GnuPG. +;; +;; GnuPG is free software; you can redistribute it and/or modify +;; it under the terms of the GNU General Public License as published by +;; the Free Software Foundation; either version 3 of the License, or +;; (at your option) any later version. +;; +;; GnuPG is distributed in the hope that it will be useful, +;; but WITHOUT ANY WARRANTY; without even the implied warranty of +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;; GNU General Public License for more details. +;; +;; You should have received a copy of the GNU General Public License +;; along with this program; if not, see . + +(load (in-srcdir "tests" "openpgp" "defs.scm")) +(setup-environment) + +(call-check `(,(tool 'gpg) --import ,(in-srcdir "tests" "openpgp" "import-incomplete" "primary+uid.asc"))) + +(info "Test import of new subkey, from a certificate without uid") +(define keyid "573EA710367356BB") +(call-check `(,(tool 'gpg) --import ,(in-srcdir "tests" "openpgp" "import-incomplete" "primary+subkey.asc"))) +(tr:do + (tr:pipe-do + (pipe:gpg `(--list-keys --with-colons ,keyid))) + (tr:call-with-content + (lambda (c) + ;; XXX we do not have a regexp library + (unless (any (lambda (line) + (and (string-prefix? line "sub:") + (string-contains? line "573EA710367356BB"))) + (string-split-newlines c)) + (exit 1))))) + +(info "Test import of revocation, from a certificate without uid") +(call-check `(,(tool 'gpg) --import ,(in-srcdir "tests" "openpgp" "import-incomplete" "primary+revocation.asc"))) +(tr:do + (tr:pipe-do + (pipe:gpg `(--list-keys --with-colons ,keyid))) + (tr:call-with-content + (lambda (c) + ;; XXX we do not have a regexp library + (unless (any (lambda (line) + (and (string-prefix? line "pub:r:") + (string-contains? line "0843DA969AA8DAFB"))) + (string-split-newlines c)) + (exit 1))))) + diff --git a/tests/openpgp/import-incomplete/primary+revocation.asc b/tests/openpgp/import-incomplete/primary+revocation.asc new file mode 100644 index 000000000..6b7b60802 --- /dev/null +++ b/tests/openpgp/import-incomplete/primary+revocation.asc @@ -0,0 +1,9 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- +Comment: [E] primary key, revocation signature over primary (no user ID) + +mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ +631VAN2IeAQgFggAIBYhBLRpj5W82H/gSMzKKQhD2paaqNr7BQJc2ZQZAh0AAAoJ +EAhD2paaqNr7qAwA/2jBUpnN0BxwRO/4CrxvrLIsL+C9aSXJUOTv8XkP4lvtAQD3 +XsDFfFNgEueiTfF7HtOGt5LPmRqVvUpQSMVgJJW6CQ== +=tM90 +-----END PGP PUBLIC KEY BLOCK----- diff --git a/tests/openpgp/import-incomplete/primary+subkey+sub-revocation.asc b/tests/openpgp/import-incomplete/primary+subkey+sub-revocation.asc new file mode 100644 index 000000000..83a51a549 --- /dev/null +++ b/tests/openpgp/import-incomplete/primary+subkey+sub-revocation.asc @@ -0,0 +1,10 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- +Comment: [D] primary key, subkey, subkey revocation (no user ID) + +mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ +631VAN24OARc2ZQhEgorBgEEAZdVAQUBAQdABsd5ha0AWXdXcSmfeiWIfrNcGqQK +j++lwwWDAOlkVicDAQgHiHgEKBYIACAWIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC +XNmnkAIdAgAKCRAIQ9qWmqja+ylaAQDmIKf86BJEq4OpDqU+V9D+wn2cyuxbyWVQ +3r9LiL9qNwD/QAjyrhSN8L3Mfq+wdTHo5i0yB9ZCCpHLXSbhCqfWZwQ= +=dwx2 +-----END PGP PUBLIC KEY BLOCK----- diff --git a/tests/openpgp/import-incomplete/primary+subkey.asc b/tests/openpgp/import-incomplete/primary+subkey.asc new file mode 100644 index 000000000..dc47a02d8 --- /dev/null +++ b/tests/openpgp/import-incomplete/primary+subkey.asc @@ -0,0 +1,10 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- +Comment: [B] primary key, subkey, subkey binding sig (no user ID) + +mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ +631VAN24OARc2ZQhEgorBgEEAZdVAQUBAQdABsd5ha0AWXdXcSmfeiWIfrNcGqQK +j++lwwWDAOlkVicDAQgHiHgEGBYIACAWIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC +XNmUIQIbDAAKCRAIQ9qWmqja++vFAP98G1L+1/rWTGbsnxOAV2RocBYIroAvsbkR +Ly6FdP8YNwEA7jOgT05CoKIe37MstpOz23mM80AK369Ca3JMmKKCQgg= +=xuDu +-----END PGP PUBLIC KEY BLOCK----- diff --git a/tests/openpgp/import-incomplete/primary+uid-sig.asc b/tests/openpgp/import-incomplete/primary+uid-sig.asc new file mode 100644 index 000000000..134607d0e --- /dev/null +++ b/tests/openpgp/import-incomplete/primary+uid-sig.asc @@ -0,0 +1,10 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- +Comment: [C] primary key and self-sig expiring in 2024 (no user ID) + +mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ +631VAN2IlgQTFggAPgIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBLRpj5W8 +2H/gSMzKKQhD2paaqNr7BQJc2ZR1BQkJZgHcAAoJEAhD2paaqNr79soA/0lWkUsu +3NLwgbni6EzJxnTzgeNMpljqNpipHAwfix9hAP93AVtFdC8g7hdUZxawobl9lnSN +9ohXOEBWvdJgVv2YAg== +=KWIK +-----END PGP PUBLIC KEY BLOCK----- diff --git a/tests/openpgp/import-incomplete/primary+uid.asc b/tests/openpgp/import-incomplete/primary+uid.asc new file mode 100644 index 000000000..055f30086 --- /dev/null +++ b/tests/openpgp/import-incomplete/primary+uid.asc @@ -0,0 +1,10 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- +Comment: [A] primary key, user ID, and self-sig expiring in 2021 + +mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ +631VAN20CHRlc3Qga2V5iJYEExYIAD4WIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC +XNmUGQIbAwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAIQ9qWmqja ++0G1AQDdQiwhXxjXLMqoth+D4SigVHTJK8ORwifzsy3UE7mPGwD/aZ67XbAF/lgI +kv2O1Jo0u9BL9RNNF+L0DM7rAFbfMAs= +=1eII +-----END PGP PUBLIC KEY BLOCK----- -- 2.20.1 From look at my.amazin.horse Tue May 21 20:03:10 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 21 May 2019 20:03:10 +0200 Subject: [PATCH GnuPG 2/2] gpg: allow import of previously known keys, even without UIDs In-Reply-To: <20190521180310.32443-1-look@my.amazin.horse> References: <20190512103655.25693-1-look@my.amazin.horse> <20190521180310.32443-1-look@my.amazin.horse> Message-ID: <20190521180310.32443-3-look@my.amazin.horse> * g10/import.c (import_one): Accept an incoming OpenPGP certificate that has no user id, as long as we already have a local variant of the cert that matches the primary key. --- g10/import.c | 49 +++++++++++-------------------------------------- 1 file changed, 11 insertions(+), 38 deletions(-) diff --git a/g10/import.c b/g10/import.c index 00bc47cc1..2be214e63 100644 --- a/g10/import.c +++ b/g10/import.c @@ -1769,7 +1769,6 @@ import_one (ctrl_t ctrl, size_t an; char pkstrbuf[PUBKEY_STRING_SIZE]; int merge_keys_done = 0; - int any_filter = 0; KEYDB_HANDLE hd = NULL; if (r_valid) @@ -1806,16 +1805,6 @@ import_one (ctrl_t ctrl, log_printf ("\n"); } - - /* Unless import-drop-uids has been requested we don't allow import - * of a key without UIDs. */ - if (!uidnode && !(options & IMPORT_DROP_UIDS)) - { - if (!silent) - log_error( _("key %s: no user ID\n"), keystr_from_pk(pk)); - return 0; - } - if (screener && screener (keyblock, screener_arg)) { log_error (_("key %s: %s\n"), keystr_from_pk (pk), @@ -1887,20 +1876,10 @@ import_one (ctrl_t ctrl, } } - /* Delete invalid parts and without the drop option bail out if - * there are no user ids. */ - if (!delete_inv_parts (ctrl, keyblock, keyid, options) - && !(options & IMPORT_DROP_UIDS) ) - { - if (!silent) - { - log_error( _("key %s: no valid user IDs\n"), keystr_from_pk(pk)); - if (!opt.quiet ) - log_info(_("this may be caused by a missing self-signature\n")); - } - stats->no_user_id++; - return 0; - } + /* Delete invalid parts, and note if we have any valid ones left. + * We will later abort import if this key is new but contains + * no valid uids. */ + delete_inv_parts (ctrl, keyblock, keyid, options); /* Get rid of deleted nodes. */ commit_kbnode (&keyblock); @@ -1910,24 +1889,11 @@ import_one (ctrl_t ctrl, { apply_keep_uid_filter (ctrl, keyblock, import_filter.keep_uid); commit_kbnode (&keyblock); - any_filter = 1; } if (import_filter.drop_sig) { apply_drop_sig_filter (ctrl, keyblock, import_filter.drop_sig); commit_kbnode (&keyblock); - any_filter = 1; - } - - /* If we ran any filter we need to check that at least one user id - * is left in the keyring. Note that we do not use log_error in - * this case. */ - if (any_filter && !any_uid_left (keyblock)) - { - if (!opt.quiet ) - log_info ( _("key %s: no valid user IDs\n"), keystr_from_pk (pk)); - stats->no_user_id++; - return 0; } /* The keyblock is valid and ready for real import. */ @@ -1985,6 +1951,13 @@ import_one (ctrl_t ctrl, err = 0; stats->skipped_new_keys++; } + else if (err && !any_uid_left (keyblock) && !(options & IMPORT_DROP_UIDS) ) + { + if (!silent) + log_info( _("key %s: new key but contains no user ID - skipped\n"), keystr(keyid)); + err = 0; + stats->no_user_id++; + } else if (err) /* Insert this key. */ { /* Note: ERR can only be NO_PUBKEY or UNUSABLE_PUBKEY. */ -- 2.20.1 From dkg at fifthhorseman.net Wed May 22 03:41:06 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 21 May 2019 21:41:06 -0400 Subject: [PATCH v2 GnuPG] allow import without user ids In-Reply-To: <20190521180310.32443-1-look@my.amazin.horse> References: <20190512103655.25693-1-look@my.amazin.horse> <20190521180310.32443-1-look@my.amazin.horse> Message-ID: <87k1ej8dvx.fsf@fifthhorseman.net> On Tue 2019-05-21 20:03:08 +0200, Vincent Breitmoser wrote: > I included dkg's testing series, as expected the test only passes once the > second patch is applied. thanks for this, Vincent! > Only three out of five of dkg's files are currently used: import of subkey > revocations that have no binding signature, as well as out-of-place user id > signatures, is out of scope for this patch. I think i understand why you think user ID self-sigs are out of scope for this series -- they don't follow the user ID they're supposed to follow, and they're not necessarily a security concern. I don't understand why you think subkey revocation is out of scope for this patch. If i import primary+uid.asc followed by primary+subkey.asc after your patch applies, then i should have a certificate with a functioning subkey on it. That's your first test, which is good. But if i then import primary+subkey+sub-revocation.asc, the subkey should show as revoked, no? Otherwise, the user will believe that the subkey is still valid. That's a significant security issue, comparable in some ways to the failed import of the revocation certificate in your final test. Could you add this subkey revocation test between the two tests? You'd be looking for a revoked subkey, i think. > I also noticed that the way I handled invalid uids before didn't make much > sense: just because there is some invalid uid in a key, doesn't mean > cryptographically valid new packets can't be imported. I changed the patch to > reflect that. i think the changes you've made look good, but i confess that the logic in the existing codebase is complex enough that i am not confident in my ability to understand it, let alone these modifications. Having the test suite is super helpful here to reason about it. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From laurent.feron at free.fr Wed May 22 13:21:45 2019 From: laurent.feron at free.fr (laurent.feron at free.fr) Date: Wed, 22 May 2019 13:21:45 +0200 (CEST) Subject: python + pgpme + openpgp card In-Reply-To: <1165648916.210338268.1558524016984.JavaMail.root@spooler3-g27.priv.proxad.net> Message-ID: <301808503.210340427.1558524105498.JavaMail.root@spooler3-g27.priv.proxad.net> Hello, It seems that I cannot manage keys on a card in Python language. Someone can confirm? Regards Laurent From ilf at zeromail.org Sat May 25 14:53:08 2019 From: ilf at zeromail.org (ilf) Date: Sat, 25 May 2019 14:53:08 +0200 Subject: Keyservers and GDPR In-Reply-To: <20190513173510.GA24471@zeromail.org> References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org> Message-ID: <20190525125307.GA13759@zeromail.org> FTR: I have not received a single reply. Happy GDPR day :) ilf: > Now I would like to know: Did any keyserver admin(s) receive any > (serious) GDPR-related complaint? Or even an official complaint by a > data protection authority? Or even a penalty like a fine? -- ilf If you upload your address book to "the cloud", I don't want to be in it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wk at gnupg.org Sun May 26 10:43:11 2019 From: wk at gnupg.org (Werner Koch) Date: Sun, 26 May 2019 10:43:11 +0200 Subject: Keyservers and GDPR In-Reply-To: <20190525125307.GA13759@zeromail.org> (ilf's message of "Sat, 25 May 2019 14:53:08 +0200") References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org> <20190525125307.GA13759@zeromail.org> Message-ID: <87y32tmwrk.fsf@wheatstone.g10code.de> On Sat, 25 May 2019 14:53, ilf at zeromail.org said: > ilf: >> Now I would like to know: Did any keyserver admin(s) receive any >> (serious) GDPR-related complaint? Or even an official complaint by a >> data protection authority? Or even a penalty like a fine? You mean from the left over 5 servers in the default hkps pool: pgpkeys.eu 51.38.91.189 AS16276 (UK) pgpkeys.uk 192.146.137.98 AS57672 (UK) pgpkeys.co.uk 192.146.137.99 AS57672 (UK) fks.pgpkeys.eu 46.4.246.179 AS24940 (DE, Hetzner) keys2.kfwebs.net 37.191.231.105 AS57963 (NO) which according to rumours have only two or three different operators? 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 gnupg-devel at spodhuis.org Mon May 27 04:39:09 2019 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Sun, 26 May 2019 22:39:09 -0400 Subject: Keyservers and GDPR In-Reply-To: <87y32tmwrk.fsf@wheatstone.g10code.de> References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org> <20190525125307.GA13759@zeromail.org> <87y32tmwrk.fsf@wheatstone.g10code.de> Message-ID: <20190527023908.GA20175@phil-pennock> On 2019-05-26 at 10:43 +0200, Werner Koch wrote: > On Sat, 25 May 2019 14:53, ilf at zeromail.org said: > You mean from the left over 5 servers in the default hkps pool: > > pgpkeys.eu 51.38.91.189 AS16276 (UK) > pgpkeys.uk 192.146.137.98 AS57672 (UK) > pgpkeys.co.uk 192.146.137.99 AS57672 (UK) > fks.pgpkeys.eu 46.4.246.179 AS24940 (DE, Hetzner) > keys2.kfwebs.net 37.191.231.105 AS57963 (NO) > > which according to rumours have only two or three different operators? My old SKS membership file had both pgpkeys.co.uk and pgpkeys.eu maintained by Daniel Austin; the off-by-one for pgpkeys.uk suggests Daniel runs that one too. That covers the first four. kfwebs.net is Kristian Fiskerstrand, who runs the pool tracking system and sks-keyservers.net. hkps is limited because Kristian doesn't hand out certs to anyone who shows up with a new keyserver and asks; he tends to do so with people who've been around and part of the community, because of the fairly obvious problems with assuming TLS is buying you anything when entirely unknown-to-others folks run the servers. Kristian takes a lot of flak for not giving people the power they want just because they ask for it. With the various problems of SKS today, I tentatively suggest that not defaulting to the HKPS pool and choosing a different target for the keys.gnupg.net CNAME might be beneficial. has the criteria; I suspect that >> subset.pool.sks-keyservers.net << is likely to be the best choice for GnuPG; the meaning of "subset" changes over time, picking newer servers, but for a while now that's been "updated SKS software able to handle Curve25519 keys". Spitballing crazy design now: The only way to get back HKPS while still having diversity and yet still some accountability is likely to be by requiring DNSSEC-signed reverse-DNS which points to matching DNSSEC-signed forward DNS to prove domain matching, and a trigger record in DNS indicating to use TLS; once there's a forward-name which doesn't require central coordination, you can verify normally and "anyone" can run a keyserver again. With all the pros and cons that entails. GnuPG can pretty much define what it wants here. Including changing the URL scheme name if needed to avoid confusion. TLSA records are available for opportunistic TLS. Effectively, "DANE for HKP with work-arounds to handle the pool nature and bounce into a verifiable name for arbitrary pool names". Shove a TLSA record in reverse DNS to indicate it's supported and you're good. Hrm, probably don't strictly need the reverse DNS to be DNSSEC-signed, as long as the TLSA-or-other-marker is present and the forward DNS is still signed. There's ways around it, but none of it will make folks who object to DNSSEC happy. Tough. -Phil From ilf at zeromail.org Mon May 27 10:59:28 2019 From: ilf at zeromail.org (ilf) Date: Mon, 27 May 2019 10:59:28 +0200 Subject: Keyservers and GDPR In-Reply-To: References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org> Message-ID: <20190527085928.GD882@zeromail.org> Tobias Mueller: >> So far, I stand by last year's statement: >>> tl;dr: Keep calm and keep running keyservers. > Are you standing by your statement because you believe that processing > that data is lawful or because you don't fear the consequences of a > potentially unlawful processing of data? I stand by my statement because of the reasons I explained last year. https://lists.gnupg.org/pipermail/gnupg-devel/2018-May/033708.html -- ilf If you upload your address book to "the cloud", I don't want to be in it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From muelli at cryptobitch.de Mon May 27 09:45:05 2019 From: muelli at cryptobitch.de (Tobias Mueller) Date: Mon, 27 May 2019 09:45:05 +0200 Subject: Keyservers and GDPR In-Reply-To: <20190513173510.GA24471@zeromail.org> References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org> Message-ID: Hi, On Mon, 2019-05-13 at 19:35 +0200, ilf wrote: > So far, I stand by last year's statement: > > > tl;dr: Keep calm and keep running keyservers. > Are you standing by your statement because you believe that processing that data is lawful or because you don't fear the consequences of a potentially unlawful processing of data? Cheers, Tobi From deloptes at gmail.com Mon May 27 13:47:19 2019 From: deloptes at gmail.com (deloptes) Date: Mon, 27 May 2019 13:47:19 +0200 Subject: Keyservers and GDPR In-Reply-To: <20190527085928.GD882@zeromail.org> References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org> <20190527085928.GD882@zeromail.org> Message-ID: Hi all, sorry for stepping in as I am not working on this topic, but following the GDPA story for longer time I never read that we could simply prompt and agree with the terms of the authority hosting the information of the public key. The date and signature and probably reference to a version of the agreement can be added to the key and it won't be much of overhead. Isn't it more simple? Of course one should take care how the key servers exchange information in a secure way, but IMO on the surface it is a matter of an agreement between the person and the authority hosting the information of the public key. As Tobias Mueller was writing, it is all about handling personal information with care and not about fines. Of course all of this should stand in court as well, because there are many lawyers and companies that make money by legally blackmailing business entities that down not comply to GDPA. regards On Mon, May 27, 2019 at 11:02 AM ilf wrote: > Tobias Mueller: > >> So far, I stand by last year's statement: > >>> tl;dr: Keep calm and keep running keyservers. > > Are you standing by your statement because you believe that processing > > that data is lawful or because you don't fear the consequences of a > > potentially unlawful processing of data? > > I stand by my statement because of the reasons I explained last year. > https://lists.gnupg.org/pipermail/gnupg-devel/2018-May/033708.html > > -- > ilf > > If you upload your address book to "the cloud", I don't want to be in it. > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.fiskerstrand at sumptuouscapital.com Mon May 27 13:30:42 2019 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 27 May 2019 13:30:42 +0200 Subject: [Sks-devel] Keyservers and GDPR In-Reply-To: <20190527023908.GA20175@phil-pennock> References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org> <20190525125307.GA13759@zeromail.org> <87y32tmwrk.fsf@wheatstone.g10code.de> <20190527023908.GA20175@phil-pennock> Message-ID: <3d5ceb8d-a090-c650-4829-a55f460cbc7e@sumptuouscapital.com> On 5/27/19 4:39 AM, Phil Pennock wrote: > hkps is limited because Kristian doesn't hand out certs to anyone who > shows up with a new keyserver and asks; he tends to do so with people > who've been around and part of the community, because of the fairly > obvious problems with assuming TLS is buying you anything when entirely > unknown-to-others folks run the servers. Kristian takes a lot of flak > for not giving people the power they want just because they ask for it. > > With the various problems of SKS today, I tentatively suggest that not > defaulting to the HKPS pool and choosing a different target for the > keys.gnupg.net CNAME might be beneficial. Adding some meta-info to this one. In addition to the above-mentioned concerns about new actors (in particular those not part of strong-set), it is also a question of capacity of the keyservers, so hkps pool is requiring load-balanced setup with minimum of 3 nodes on modern hardware (e.g a node today requires a minimum of 8 GiB of RAM to be responsive during merge of certain keys). The propagation time between the servers in the broader pool became quite big and servers dropping in-out sporadically due to merges. Now, this is somewhat better for the general pool since https://dev.gnupg.org/T4175 results in retry on failover for 5xx codes, but has caused a lot of problem reports in the past and not all distros ship this in stable versions. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws -------------- 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 May 28 17:53:44 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 May 2019 17:53:44 +0200 Subject: [Announce] GnuPG 2.2.16 released Message-ID: <87sgsyk22f.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.16. This is a maintenance release; 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.16 ==================================== * gpg,gpgsm: Fix deadlock on Windows due to a keybox sharing violation. [#4505] * gpg: Allow deletion of subkeys with --delete-key. This finally makes the bang-suffix work as expected for that command. [#4457] * gpg: Replace SHA-1 by SHA-256 in self-signatures when updating them with --quick-set-expire or --quick-set-primary-uid. [#4508] * gpg: Improve the photo image viewer selection. [#4334] * gpg: Fix decryption with --use-embedded-filename. [#4500] * gpg: Remove hints on using the --keyserver option. [#4512] * gpg: Fix export of certain secret keys with comments. [#4490] * gpg: Reject too long user-ids in --quick-gen-key. [#4532] * gpg: Fix a double free in the best key selection code. [#4462] * gpg: Fix the key generation dialog for switching back from EdDSA to ECDSA. * gpg: Use AES-192 with SHA-384 to comply with RFC-6637. * gpg: Use only the addrspec from the Signer's UID subpacket to mitigate a problem with another implementation. * gpg: Skip invalid packets during a keyring listing and sync diagnostics with the output. * gpgsm: Avoid confusing diagnostic when signing with the default key. [#4535] * agent: Do not delete any secret key in --dry-run mode. * agent: Fix failures on 64 bit big-endian boxes related to URIs in a keyfile. [#4501] * agent: Stop scdaemon after a reload with disable-scdaemon newly configured. [#4326] * dirmngr: Improve caching algorithm for WKD domains. * dirmngr: Support other hash algorithms than SHA-1 for OCSP. [#3966] * gpgconf: Make --homedir work for --launch. [#4496] * gpgconf: Before --launch check for a valid config file. [#4497] * wkd: Do not import more than 5 keys from one WKD address. * wkd: Accept keys which are stored in armored format in the directory. * The installer for Windows now comes with signed binaries. Release-info: https://dev.gnupg.org/T4509 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.16 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.16.tar.bz2 (6542k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.16.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.16_20190528.exe (4183k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.16_20190528.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. 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.16.tar.bz2 you would use this command: gpg --verify gnupg-2.2.16.tar.bz2.sig gnupg-2.2.16.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.16.tar.bz2, you run the command like this: sha1sum gnupg-2.2.16.tar.bz2 and check that the output matches the next line: f956c8cebee3a6ddb2ce6e6e058d474d056dd9e0 gnupg-2.2.16.tar.bz2 8d2214dc3dd4a34c69953b1c9254520fd07033f1 gnupg-w32-2.2.16_20190528.tar.xz caf09d6e0e47d87675f1805409a503ce0cf93a4e gnupg-w32-2.2.16_20190528.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 wk at gnupg.org Wed May 29 08:56:10 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 May 2019 08:56:10 +0200 Subject: Keyservers and GDPR In-Reply-To: <20190527023908.GA20175@phil-pennock> (Phil Pennock's message of "Sun, 26 May 2019 22:39:09 -0400") References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org> <20190525125307.GA13759@zeromail.org> <87y32tmwrk.fsf@wheatstone.g10code.de> <20190527023908.GA20175@phil-pennock> Message-ID: <877ea921h1.fsf@wheatstone.g10code.de> On Sun, 26 May 2019 22:39, gnupg-devel at spodhuis.org said: > With the various problems of SKS today, I tentatively suggest that not > defaulting to the HKPS pool and choosing a different target for the > keys.gnupg.net CNAME might be beneficial. FWIW, keys.gnupg.net is since gnupg 2.2.7 not a CNAME name but aliased by dirmngr in this way: hkps://keys.gnupg.net -> hkps://hkps.pool.sks-keyservers.net https://keys.gnupg.net -> https://hkps.pool.sks-keyservers.net hkp://keys.gnupg.net -> hkp://hkps.pool.sks-keyservers.net http://keys.gnupg.net -> http://hkps.pool.sks-keyservers.net hkps://http-keys.gnupg.net -> hkps://ha.pool.sks-keyservers.net https://http-keys.gnupg.net -> https://ha.pool.sks-keyservers.net hkp://http-keys.gnupg.net -> hkp://ha.pool.sks-keyservers.net http://http-keys.gnupg.net -> http://ha.pool.sks-keyservers.net keys.gnupg.net -> hkps://hkps.pool.sks-keyservers.net http-keys.gnupg.net -> hkps://ha.pool.sks-keyservers.net this was needed to void problems with server name matching. Thus we can't change that easily. Anyway, it is suggested tha the default keyserver is used which is hkps://hkps.pool.sks-keyservers.net To change this the keyserver option in dirmngr.conf needs to be used. > suspect that >> subset.pool.sks-keyservers.net << is likely to be the > best choice for GnuPG; the meaning of "subset" changes over time, I am pretty sure that changing to this as the default will raise a lot of concerns from the folks who want to elimiated the use of the string "http://". 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 wk at gnupg.org Wed May 29 09:07:26 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 May 2019 09:07:26 +0200 Subject: [Sks-devel] Keyservers and GDPR In-Reply-To: <3d5ceb8d-a090-c650-4829-a55f460cbc7e@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Mon, 27 May 2019 13:30:42 +0200") References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org> <20190525125307.GA13759@zeromail.org> <87y32tmwrk.fsf@wheatstone.g10code.de> <20190527023908.GA20175@phil-pennock> <3d5ceb8d-a090-c650-4829-a55f460cbc7e@sumptuouscapital.com> Message-ID: <8736kx20y9.fsf@wheatstone.g10code.de> On Mon, 27 May 2019 13:30, kristian.fiskerstrand at sumptuouscapital.com said: > requiring load-balanced setup with minimum of 3 nodes on modern hardware > (e.g a node today requires a minimum of 8 GiB of RAM to be responsive > during merge of certain keys). The propagation time between the servers Which would support my point to redesign the keyservers to - Inhibit searches by user id. - Drop all key signatures except for self-signatures and designated revocations. The first change will make Gnupg --search-keys useless and that command could thus be changed to do a --locate-key with disabled local keyring. The second requires that key-signatures must be send to the key owner directly, which is anyway what most people do. And obviously the key owner needs to distribute them by other means than the keyservers to make the few WoT users happy. Right, this requires that self-signatures are verified on upload. 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 andrewg at andrewg.com Wed May 29 09:33:00 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 29 May 2019 08:33:00 +0100 Subject: [Sks-devel] Keyservers and GDPR In-Reply-To: <8736kx20y9.fsf@wheatstone.g10code.de> References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org> <20190525125307.GA13759@zeromail.org> <87y32tmwrk.fsf@wheatstone.g10code.de> <20190527023908.GA20175@phil-pennock> <3d5ceb8d-a090-c650-4829-a55f460cbc7e@sumptuouscapital.com> <8736kx20y9.fsf@wheatstone.g10code.de> Message-ID: > On 29 May 2019, at 08:07, Werner Koch wrote: > > Right, this requires that self-signatures are verified on upload. ...and on reconciliation? A From dirkx at webweaving.org Wed May 29 09:42:56 2019 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Wed, 29 May 2019 09:42:56 +0200 Subject: [Sks-devel] Keyservers and GDPR In-Reply-To: <8736kx20y9.fsf@wheatstone.g10code.de> References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> <20190513173510.GA24471@zeromail.org> <20190525125307.GA13759@zeromail.org> <87y32tmwrk.fsf@wheatstone.g10code.de> <20190527023908.GA20175@phil-pennock> <3d5ceb8d-a090-c650-4829-a55f460cbc7e@sumptuouscapital.com> <8736kx20y9.fsf@wheatstone.g10code.de> Message-ID: <038536C5-0F94-4280-82E3-CA7772C8BF31@webweaving.org> On 29 May 2019, at 09:07, Werner Koch wrote: > Which would support my point to redesign the keyservers to > > - Inhibit searches by user id. What is the reasoning behind this (as signing keys just are on the uploaded key with a keyid ? so we are talking about the key its own data) ? And pair this if needed with a submission protocol that insists on having the private key. That would also openup, from a GDPR perspective, allowing the signing key ids back in. Dw. From alex at nitrokey.com Wed May 29 10:50:12 2019 From: alex at nitrokey.com (Alexander Paetzelt | Nitrokey) Date: Wed, 29 May 2019 10:50:12 +0200 Subject: python + pgpme + openpgp card In-Reply-To: <301808503.210340427.1558524105498.JavaMail.root@spooler3-g27.priv.proxad.net> References: <301808503.210340427.1558524105498.JavaMail.root@spooler3-g27.priv.proxad.net> Message-ID: <1b53c775-a2df-4fcb-fc57-ceb0ee4aae53@nitrokey.com> Hi Laurent, yes, as far as I know pgpme has no smart card functionality at all (yet). You need to use other python libraries for OpenPGP Card usage. Though there is no full-featured pyhthon library for OpenPGP Cards either. At least none I know of. There are rudimentary ones though. Sorry, but I am too lazy to provide links right know, but they are easily found :) Kind regards Alex On 22.05.19 13:21, laurent.feron at free.fr wrote: > Hello, > It seems that I cannot manage keys on a card in Python language. Someone can confirm? > Regards > Laurent > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel >