From spam.trap.mailing.lists at gmail.com Fri Jan 1 10:18:47 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Fri, 1 Jan 2021 10:18:47 +0100 Subject: Happy New Year! Message-ID: Happy New Year to Werner, Andre, the sequoia team, Casey, the Old Guard and all GnuPG hackers and users around the world! Best regards Stefan From cqcallaw at brainvitamins.net Fri Jan 1 22:30:00 2021 From: cqcallaw at brainvitamins.net (cqcallaw) Date: Fri, 01 Jan 2021 21:30:00 +0000 Subject: Happy New Year! In-Reply-To: References: Message-ID: Happy New Year and best wishes to all! ??????? Original Message ??????? On Friday, January 1, 2021 1:18 AM, Stefan Claas via Gnupg-users wrote: > Happy New Year to Werner, Andre, the sequoia team, Casey, the Old > Guard and all GnuPG hackers and users around the world! > > Best regards > Stefan > > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From spam.trap.mailing.lists at gmail.com Sat Jan 2 10:51:20 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 2 Jan 2021 10:51:20 +0100 Subject: Plan B - Who carries the torch? Message-ID: Hi all, hope you all had a Happy New Year and that your are all healthy! I am currently in the mood to discuss things here and there publicity and regarding GnuPG and the OpenPGP ecosystem I was wondering about the following. I assume the following: Werner is globally known as the author of GnuPG and it is generally accepted that GnuPG is a defacto security standard globally besides S/MIME when it comes for example to private email communications. Werner, like me and a couple of others, as some may know are no longer in their twenties so that it can be assumed, when in 10 years Google and IBM have Quantum Computers, which make our classic encryption like ECC probably useless that then people may have a problem. I assume the worst case scenario that when Werner retires and starts to enjoy life with his family and friends and let's say Andre would change his career path who carries then the torch, so to speak? Would dkg take over and do also gpg4win developement? My understanding is that sequoia pgp, due to the fact that it is written in Rust may probably see not it's light in major Linux distributions as an apt-get option, or in case Casey would decide (once Hockeypuck is finished) that he writes a Golang GnuPG that would be then distributed in major Linux distros. So, ladies and gentlemen any thoughts or insights which can be shared? Regards Stefan From karel-v_g at tutanota.com Sat Jan 2 12:13:19 2021 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Sat, 2 Jan 2021 12:13:19 +0100 (CET) Subject: Precompiled Windows-Binaries with Large-Secmem-Support Message-ID: Hello! I know there are and have been fierce discussions about the useful length of RSA-Keys. I don't want to dive deeper into that, and I hope this special question has not been discussed recently: The generation of large RSA-Keys is extremely well hidden for normal users, it requires batch-mode, enable-large-rsa and a special file with instructions. Thus the danger for inexperienced users to mess up their keys is rather low. Nevertheless the officially available precompiled Windows-Binaries come without support for these large keys (at least those included into GPG4Win). May I suggest to compile future builds for Windows with enable-large-secmem?! Thanks for discussing and considering. Karel From rjh at sixdemonbag.org Sat Jan 2 22:55:49 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 02 Jan 2021 16:55:49 -0500 Subject: Plan B - Who carries the torch? In-Reply-To: References: Message-ID: <4c2ccf67cfe9c987971dae1c968c299de88a626a.camel@sixdemonbag.org> > I assume the following: Werner is globally known as the author of > GnuPG and it is generally accepted that GnuPG is a defacto security > standard globally besides S/MIME when it comes for example to private > email communications. No. OpenPGP is; GnuPG is just one implementation of the OpenPGP standard. There are others. > in their twenties so that it can be assumed, when in 10 years Google > and IBM have Quantum Computers, which make our classic encryption > like > ECC probably useless that then people may have a problem. Quantum computing has been ten years away since 1992, which is when I first heard about it. I would be extraordinarily cautious about believing the hype. Getting enough qubits together to form the necessary quantum logic is only a very small part of the overall picture. Read up on Grover's algorithm sometime, and think about just how unreasonable the requirements are: they're so unreasonable as to make the prospect of breaking crypto via Grover's actually _slower_ than the classical way. > I assume the worst case scenario that when Werner retires and starts > to enjoy life with his family and friends and let's say Andre would > change his career path who carries then the torch, so to speak? Who cares? Seriously. OpenPGP has survived as long as it has mostly by a miracle involving the diligence of a handful of people, but in many ways it's embarrassingly ... well, not obsolete. Definitely obsolescent, though. A cryppie at Johns Hopkins, Matthew Green, describes OpenPGP as a showcase of the best cryptographical techniques of the mid-1990s, and he's not wrong. Someday, we'll decide OpenPGP has done enough and should be retired. And that will be okay. I hope that someone else comes along and works on a newer standard using the best cryptographical techniques of the 2020s, and I hope this new standard breaks backwards compatibility with OpenPGP. Breaks it flagrantly, violently, and spectacularly. > So, ladies and gentlemen any thoughts or insights which can be > shared? Yeah. Less time worrying about how to make OpenPGP continue for another twenty years, more time spent about how to make a next- generation cryptographic tool that will occupy the same space OpenPGP did but will do it better and with more modern techniques. From rjh at sixdemonbag.org Sat Jan 2 22:58:31 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 02 Jan 2021 16:58:31 -0500 Subject: Precompiled Windows-Binaries with Large-Secmem-Support In-Reply-To: References: Message-ID: > I know there are and have been fierce discussions about the useful > length of RSA-Keys. I don't want to dive deeper into that, and I hope > this special question has not been discussed recently: If you're going to propose a change like that, you need to make a case for it. * Who currently is being harmed by not supporting RSA-16384? * Why is RSA-16384 necessary for them? "Because I think it would be cool" is a good answer if you're the one writing the patch and volunteering to do long-term support of it. All other people need to be able to answer it. From spam.trap.mailing.lists at gmail.com Sun Jan 3 00:20:18 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 3 Jan 2021 00:20:18 +0100 Subject: Plan B - Who carries the torch? In-Reply-To: <4c2ccf67cfe9c987971dae1c968c299de88a626a.camel@sixdemonbag.org> References: <4c2ccf67cfe9c987971dae1c968c299de88a626a.camel@sixdemonbag.org> Message-ID: On Sat, Jan 2, 2021 at 10:56 PM Robert J. Hansen wrote: > > in their twenties so that it can be assumed, when in 10 years Google > > and IBM have Quantum Computers, which make our classic encryption > > like > > ECC probably useless that then people may have a problem. > > Quantum computing has been ten years away since 1992, which is when I > first heard about it. I would be extraordinarily cautious about > believing the hype. Getting enough qubits together to form the > necessary quantum logic is only a very small part of the overall > picture. Read up on Grover's algorithm sometime, and think about just > how unreasonable the requirements are: they're so unreasonable as to > make the prospect of breaking crypto via Grover's actually _slower_ > than the classical way. Well, I do not follow any hype but you, as a well educated person knows like many others, I strongly assume, that people interested in this topic can play already with Quantum Computer Resistant algorythms, freely available. Not only this, but when folks, I judge as professionals in their field, are doing work related to this topic, i.e. NIST [1] I guess it would not hurt to mention this. Last year, for example, was the ECC conference and it was mentioned that IBM and Google would be capable in ten years to have Quantum Computers with a million qubits, or so and not only a couple. Besides Quantum Computers I would guess that also research in the field of other technologies are done, wich can, as understood, rival Quantum Computers and are cheaper to produce and to maintain. [2] > > > I assume the worst case scenario that when Werner retires and starts > > to enjoy life with his family and friends and let's say Andre would > > change his career path who carries then the torch, so to speak? > > Who cares? For example me, and now maybe others ... :-) > Seriously. OpenPGP has survived as long as it has mostly by a miracle > involving the diligence of a handful of people, but in many ways it's > embarrassingly ... well, not obsolete. Definitely obsolescent, though. > A cryppie at Johns Hopkins, Matthew Green, describes OpenPGP as a > showcase of the best cryptographical techniques of the mid-1990s, and > he's not wrong. > > Someday, we'll decide OpenPGP has done enough and should be retired. > And that will be okay. I hope that someone else comes along and works > on a newer standard using the best cryptographical techniques of the > 2020s, and I hope this new standard breaks backwards compatibility with > OpenPGP. Breaks it flagrantly, violently, and spectacularly. > > > So, ladies and gentlemen any thoughts or insights which can be > > shared? > > Yeah. Less time worrying about how to make OpenPGP continue for > another twenty years, more time spent about how to make a next- > generation cryptographic tool that will occupy the same space OpenPGP > did but will do it better and with more modern techniques. Thank you very much for your thoughts, which I agree. Question however remains, who will do this? Cypherpunks, for example, are dead, which had IMHO a great influence in the past. [1] [2] Regards Stefan From karel-v_g at tutanota.com Sun Jan 3 15:21:58 2021 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Sun, 3 Jan 2021 15:21:58 +0100 (CET) Subject: Precompiled Windows-Binaries with Large-Secmem-Support In-Reply-To: References: Message-ID: > > "Because I think it would be cool" is a good answer if you're the one > writing the patch and volunteering to do long-term support of it. All > other people need to be able to answer it. > Hello! I suspect the tone of your reply and the fact that you put me near script kiddies is due to the previous discussions about key length?! So let me set the record straight on a few things: I did not talk about 16384bit keys, nor did I suggest or demand a patch for GnuPG. I merely asked why the official Windows binaries (at least those inGPG4Win) are not compiled with the already existing option "enable-large-secmem", which would allow keys up to 8192bit in batch mode operation, and suggested to do so in future versions. Much has already been argued about the sense or nonsense, we don't need to repeat that here. But the option is already implemented and used in other ready-made packages, e.g. in Debian Buster. So to the best of my knowledge beyond a setting switch when compiling new versions, there would be no long-term support effort in the code. So why not also under Windows? Karel From karel-v_g at tutanota.com Sun Jan 3 15:35:46 2021 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Sun, 3 Jan 2021 15:35:46 +0100 (CET) Subject: Plan B - Who carries the torch? Message-ID: >Yeah. Less time worrying about how to make OpenPGP continue for>another twenty years, more time spent about how to make a next->generation cryptographic tool that will occupy the same space OpenPGP>did but will do it better and with more modern techniques. I totally agree with you on that. Though I have no idea how to do it, I think in the midterm we need something totally new with modern crypto-technology, easy to use and lean. Like WireGuard for VPN or the modern messengers. Unfortunately OpenPGP and S/MIME have not managed to conquer a broad public and sometimes even not to keep up with modern standards in the last twenty years. Sorry for criticising without suggesting a solution.Karel From wk at gnupg.org Sun Jan 3 20:19:10 2021 From: wk at gnupg.org (Werner Koch) Date: Sun, 03 Jan 2021 20:19:10 +0100 Subject: Precompiled Windows-Binaries with Large-Secmem-Support In-Reply-To: (karel-v's message of "Sun, 3 Jan 2021 15:21:58 +0100 (CET)") References: Message-ID: <871rf1q15d.fsf@wheatstone.g10code.de> > I merely asked why the official Windows binaries (at least those > inGPG4Win) are not compiled with the already existing option > "enable-large-secmem", which would allow keys up to 8192bit in batch That option has only been introduced to satisfy the needs of a few nerds and for helping with research tasks. Those who need this should know how to setup up a build and distribution system needed for their special needs. 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 look at my.amazin.horse Mon Jan 4 14:08:08 2021 From: look at my.amazin.horse (Vincent Breitmoser) Date: Mon, 04 Jan 2021 14:08:08 +0100 Subject: Plan B - Who carries the torch? In-Reply-To: References: Message-ID: <3RASJYPBO15QH.3DATLLBX232F8@my.amazin.horse> > My understanding is that sequoia pgp, due to the fact that it is written in Rust may > probably see not it's light in major Linux distributions as an apt-get option While it's true that Rust crates aren't straightforward to package in Debian, sequoia-the-library in version 1.0.0 is indeed packaged in Debian bullseye as of 2020-12-16, so should make its way through the apt ecosystem through the year. https://packages.debian.org/testing/source/rust-sequoia-openpgp https://sequoia-pgp.org/blog/2020/12/16/202012-1.0/ - V From spam.trap.mailing.lists at gmail.com Mon Jan 4 16:23:33 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Mon, 4 Jan 2021 16:23:33 +0100 Subject: Plan B - Who carries the torch? In-Reply-To: <3RASJYPBO15QH.3DATLLBX232F8@my.amazin.horse> References: <3RASJYPBO15QH.3DATLLBX232F8@my.amazin.horse> Message-ID: On Mon, Jan 4, 2021 at 3:27 PM Vincent Breitmoser via Gnupg-users wrote: > > > > My understanding is that sequoia pgp, due to the fact that it is written in Rust may > > probably see not it's light in major Linux distributions as an apt-get option > > While it's true that Rust crates aren't straightforward to package in Debian, > sequoia-the-library in version 1.0.0 is indeed packaged in Debian bullseye as of > 2020-12-16, so should make its way through the apt ecosystem through the year. > > https://packages.debian.org/testing/source/rust-sequoia-openpgp > > https://sequoia-pgp.org/blog/2020/12/16/202012-1.0/ Ah, cool. I was not (yet) aware of it. And seeing dkg listed as a package maintainer is a bonus too, IMHO. :-) Best regards Stefan From angel at pgp.16bits.net Tue Jan 5 03:31:23 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Tue, 05 Jan 2021 03:31:23 +0100 Subject: Plan B - Who carries the torch? In-Reply-To: References: Message-ID: On 2021-01-03 at 15:35 +0100, karel-v_g--- via Gnupg-users wrote: > > Yeah. Less time worrying about how to make OpenPGP continue > > for>another twenty years, more time spent about how to make a next- > > >generation cryptographic tool that will occupy the same space > > OpenPGP>did but will do it better and with more modern techniques. > I totally agree with you on that. Though I have no idea how to do it, > I think in the midterm we need something totally new with modern > crypto-technology, easy to use and lean. Like WireGuard for VPN or > the modern messengers. Changing OpenPGP standard to use a Quantum-resistant algorithm would be "easy". With really big quote marks in bold typeface. But simple in theory. First, you would need a new public key algorithm resistant to the new attack e.g. Quantum-resistant. I don't think a new simmetric cipher would be needed, current AES options should stand even in Quantumcalypsis. Then, you will need to assign an algo id for the new algorithm and set the way the parameters will be stored in the key. You get all implementations to add support for that new algorithm (well, at least all implementations used by people you care about). Finally, every user will need to discard their now-useless keys, generate new ones and rebuild the chain of turst from the ground up. Right now, we don't even have the candidate on what such algorithm will be. Hopefully, it will appear long before that Quantumcalypsis. Then, getting one or two implementations to support it may be simple, but the OpenPGP ecosystem is a very fossilized environment. We still haven't reached broad ECC support. There are some implementations which still don't support it at all. And in other cases the program would support it, but the user happens to use an ancient version that they didn't update for many years. As for the need of creating new keys and rebuilding the WoT, that's sadly a consequence of the way openpgp keys are structured. There's no clean way to progressively migrate into a new asymmetric algorithm. For symmetric ciphers you do that with multiple subkeys, but not for asymmetric keys. Well, you _could_ do that, but either the main key uses the new algorithm (and thus old clients wouldn't be able to use the key, so no reason for adding a classic subkey) or if the main key used a classic algorithm, that would be the key being attacked, so there is still no point for that. At most, you could use two separate keys, one using "new" and other "classic" crypto, and use them selectively (depending on who you communicate with) or in parallel (i.e. always signing everything with both keys). It would be nice to have a way to attach a new, modern, key to a backwards-compatible key, but that seems hard to construct (the fingerprint would *not* cover the new key, or otherwise, you would need to (ab)use an ignored portion of the public key block). Regards ?ngel From gniibe at fsij.org Tue Jan 5 04:22:23 2021 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 05 Jan 2021 12:22:23 +0900 Subject: [developer preview] smartcard + opengp as a linux gadget In-Reply-To: <20201227041724.110c1395@vincent> References: <20201227041724.110c1395@vincent> Message-ID: <87eej0dq4w.fsf@iwagami.gniibe.org> Vincent Pelletier wrote: > I would like to announce my implementation of a software CCID card > reader targeting the Linux gadget subsystem, along with a smartcard OS > and openpgp card application to use with this reader. Great. (And thanks for the patches for tests of Gnuk. I'll apply those, soon.) FWIW, it was around 2008/2009, when Daiki Ueno had an implementation of USB token toolkit with Linux gadget, called "Tandoori" (IIRC). I think that the purpose was similar. However, today, I can't find any code. All that I found is a record of symposium called ComSys2008 (in Japanese): https://iss.ndl.go.jp/books/R100000002-I000009985680-00 Historically, it was done before Gnuk. -- From jeandavid8 at verizon.net Tue Jan 5 13:27:14 2021 From: jeandavid8 at verizon.net (Jean-David Beyer) Date: Tue, 5 Jan 2021 07:27:14 -0500 Subject: Plan B - Who carries the torch? In-Reply-To: References: Message-ID: On 1/4/21 9:31 PM, ???ngel wrote: > Finally, every user will need to discard their now-useless keys, > generate new ones and rebuild the chain of turst from the ground up. Building a web of trust is so hopeless, from my point of view, that I have abandonned gnupg. I have made keys for myself, obtained enigmail for my Firefox browser, etc. But those with whom I correspond by e-mail has diminished to almost the vanishing point. They use text messages on their cell phones, Facebook messages, etc. While a few worry about the "CIA" snooping on them, none will consider gnupg and enigmail. So for me, it is pointless. -- .~. Jean-David Beyer /V\ Shrewsbury, New Jersey /( )\ Red Hat Enterprise Linux ^^-^^ up 4 days, 13 hours, 37 minutes From jeandavid8 at verizon.net Tue Jan 5 14:50:59 2021 From: jeandavid8 at verizon.net (Jean-David Beyer) Date: Tue, 5 Jan 2021 08:50:59 -0500 Subject: Plan B - Who carries the torch? In-Reply-To: <20210105132441.qetwkmhwikezuikm@chatter.i7.local> References: <20210105132441.qetwkmhwikezuikm@chatter.i7.local> Message-ID: <95b8f7aa-62af-0dc0-cf3a-93eb03a384cf@verizon.net> On 1/5/21 8:24 AM, Konstantin Ryabitsev wrote: > On Tue, Jan 05, 2021 at 07:27:14AM -0500, Jean-David Beyer via Gnupg-users wrote: >> Building a web of trust is so hopeless, from my point of view, that I have >> abandonned gnupg. I have made keys for myself, obtained enigmail for my >> Firefox browser, etc. But those with whom I correspond by e-mail has >> diminished to almost the vanishing point. They use text messages on their >> cell phones, Facebook messages, etc. While a few worry about the "CIA" >> snooping on them, none will consider gnupg and enigmail. So for me, it is >> pointless. >> >> -- >> .~. Jean-David Beyer >> /V\ Shrewsbury, New Jersey >> /( )\ Red Hat Enterprise Linux >> ^^-^^ up 4 days, 13 hours, 37 minutes > I noticed your signature, so I must point out that RHEL and the Linux Kernel > development process rely heavily on GnuPG and the web of trust. Every time you > update packages on your system, large parts of the supply chain were verified > using GnuPG, relying on the integrity of the trust store shipped with RHEL. > > So, you may not see it in your person-to-person communication, but you use > GnuPG every day. > > -K I sit corrected: $ rpm -qf /usr/bin/gpg gnupg2-2.2.9-1.el8.x86_64 I posted, not so much to criticize GnuPG as to criticize my associates who talk security paranoia, but refuse to do anything about it. When all is said and done, more is said than done. At least, with my associates. -- .~. Jean-David Beyer /V\ Shrewsbury, New Jersey /( )\ Red Hat Enterprise Linux ^^-^^ up 4 days, 15 hours, 2 minutes From konstantin at linuxfoundation.org Tue Jan 5 14:24:41 2021 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Tue, 5 Jan 2021 08:24:41 -0500 Subject: Plan B - Who carries the torch? In-Reply-To: References: Message-ID: <20210105132441.qetwkmhwikezuikm@chatter.i7.local> On Tue, Jan 05, 2021 at 07:27:14AM -0500, Jean-David Beyer via Gnupg-users wrote: > Building a web of trust is so hopeless, from my point of view, that I have > abandonned gnupg. I have made keys for myself, obtained enigmail for my > Firefox browser, etc. But those with whom I correspond by e-mail has > diminished to almost the vanishing point. They use text messages on their > cell phones, Facebook messages, etc. While a few worry about the "CIA" > snooping on them, none will consider gnupg and enigmail. So for me, it is > pointless. > > -- > .~. Jean-David Beyer > /V\ Shrewsbury, New Jersey > /( )\ Red Hat Enterprise Linux > ^^-^^ up 4 days, 13 hours, 37 minutes I noticed your signature, so I must point out that RHEL and the Linux Kernel development process rely heavily on GnuPG and the web of trust. Every time you update packages on your system, large parts of the supply chain were verified using GnuPG, relying on the integrity of the trust store shipped with RHEL. So, you may not see it in your person-to-person communication, but you use GnuPG every day. -K From wk at gnupg.org Tue Jan 5 15:38:11 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Jan 2021 15:38:11 +0100 Subject: Plan B - Who carries the torch? In-Reply-To: (Jean-David Beyer via Gnupg-users's message of "Tue, 5 Jan 2021 07:27:14 -0500") References: Message-ID: <87turvmoto.fsf@wheatstone.g10code.de> On Tue, 5 Jan 2021 07:27, Jean-David Beyer said: > Building a web of trust is so hopeless, from my point of view, that I > have abandonned gnupg. I have made keys for myself, obtained enigmail Virtually nobody uses the WoT. What people use are direct key signatures. That is you verify a key's owner and then sign that key. Usually not even exportable. Verification is often done by trust on first use. And that is okay for the majority of use cases. 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 rjh at sixdemonbag.org Tue Jan 5 15:46:01 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 05 Jan 2021 09:46:01 -0500 Subject: Plan B - Who carries the torch? In-Reply-To: <87turvmoto.fsf@wheatstone.g10code.de> References: <87turvmoto.fsf@wheatstone.g10code.de> Message-ID: On Tue, 2021-01-05 at 15:38 +0100, Werner Koch via Gnupg-users wrote: > Virtually nobody uses the WoT... Strangely, the Linux kernel folks still use it a decent amount. They're the only large group I can think of offhand, though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 850 bytes Desc: This is a digitally signed message part URL: From wk at gnupg.org Tue Jan 5 16:17:37 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Jan 2021 16:17:37 +0100 Subject: Plan B - Who carries the torch? In-Reply-To: (Robert J. Hansen's message of "Tue, 05 Jan 2021 09:46:01 -0500") References: <87turvmoto.fsf@wheatstone.g10code.de> Message-ID: <87eeizmmzy.fsf@wheatstone.g10code.de> On Tue, 5 Jan 2021 09:46, Robert J. Hansen said: > Strangely, the Linux kernel folks still use it a decent amount. There are indeed use cases for the WoT; in particular if you don't known your co-worker. However, in commerical or private settings the communication patterns are different from the hacker community. 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 spam.trap.mailing.lists at gmail.com Tue Jan 5 16:46:20 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 5 Jan 2021 16:46:20 +0100 Subject: Plan B - Who carries the torch? In-Reply-To: <87turvmoto.fsf@wheatstone.g10code.de> References: <87turvmoto.fsf@wheatstone.g10code.de> Message-ID: On Tue, Jan 5, 2021 at 3:44 PM Werner Koch via Gnupg-users wrote: > > On Tue, 5 Jan 2021 07:27, Jean-David Beyer said: > > > Building a web of trust is so hopeless, from my point of view, that I > > have abandonned gnupg. I have made keys for myself, obtained enigmail > > Virtually nobody uses the WoT. What people use are direct key > signatures. That is you verify a key's owner and then sign that key. > Usually not even exportable. Verification is often done by trust on > first use. And that is okay for the majority of use cases. Not sure I understand you correctly, but why are then SKS key servers still in operation, which allows third parties to look up who signed who's key and with what trust level and GnuPG's WoT support, compared to sq and Hagrid? Regards Stefan From konstantin at linuxfoundation.org Tue Jan 5 17:34:22 2021 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Tue, 5 Jan 2021 11:34:22 -0500 Subject: Plan B - Who carries the torch? In-Reply-To: References: <87turvmoto.fsf@wheatstone.g10code.de> Message-ID: <20210105163422.jpickcr3zdvtbtld@chatter.i7.local> On Tue, Jan 05, 2021 at 09:46:01AM -0500, Robert J. Hansen via Gnupg-users wrote: > On Tue, 2021-01-05 at 15:38 +0100, Werner Koch via Gnupg-users wrote: > > Virtually nobody uses the WoT... > > Strangely, the Linux kernel folks still use it a decent amount. > They're the only large group I can think of offhand, though. Debian is much larger, though they've been moving away from the web of trust based on keysigning and towards a scheme based around signed digital documents (same idea, but certificates aren't bundled with keys themselves). The use of WoT is not really that strange. WoT works better than most alternatives in setups with decentralized infrastructure. While kernel.org does act as a "certification authority" of sorts, we merely check and enforce the web of trust before issuing accounts. Every step of the process is transparent and can be verified, per this document: https://korg.docs.kernel.org/pgpkeys.html -K From markus.rosco at neverbox.com Tue Jan 5 20:14:07 2021 From: markus.rosco at neverbox.com (markus.rosco at neverbox.com) Date: Tue, 5 Jan 2021 19:14:07 +0000 Subject: On future of GnuPG In-Reply-To: References: <87turvmoto.fsf@wheatstone.g10code.de> Message-ID: On 2021-01-05 Stefan Claas via Gnupg-users - gnupg-users at gnupg.org wrote: > ... but why are then SKS key servers > still in operation, which allows third parties to look up who signed > who's key and with what trust level and GnuPG's WoT support, compared > to sq and Hagrid? The landscape has changed dramatically from the times when the original PGP fundamentals were introduced. Today, for any secure personal communication system to be of practical use, it must be designed from the ground up observing the following simple principle: *anonymity is the necessary condition of privacy*. From rjh at sixdemonbag.org Tue Jan 5 23:07:11 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 05 Jan 2021 17:07:11 -0500 Subject: On future of GnuPG In-Reply-To: References: <87turvmoto.fsf@wheatstone.g10code.de> Message-ID: <652d31a89d4f4eaa216d792b93c0986d186e7dca.camel@sixdemonbag.org> > The landscape has changed dramatically from the times when the > original PGP fundamentals were introduced. Today, for any secure > personal communication system to be of practical use, it must > be designed from the ground up observing the following simple > principle: *anonymity is the necessary condition of privacy*. This borders on ridiculous. One of the problems we have in privacy discussions is there is no single agreed-upon definition of privacy. Privacy is defined by culture, and unless we share a culture we're very unlikely to share a privacy definition. In the United States, the prevailing culture cares a lot more about government's ability to learn things about me without a warrant than it does about the ability of corporations or businesses. And we also believe that government limiting our ability to speak infringes on our privacy: "why the hell is the government getting in my business if all I'm doing is sharing true things with my buddy?" Whereas in Europe, right-to-be-forgotten laws, enforced by the government, are seen as wins for privacy, in America they would be (a) blatantly unlawful and (b) considered massive invasions of our privacy by the government. In Europe it's a lot different. There, the prevailing culture cares a lot more about limiting the ability of businesses to learn things about a person than with limiting the ability of governments. The national security exemption in the GDPR is big enough to drive a truck through: it is so all-encompassing that I, as an American, look at the GDPR and think it's a nightmare for privacy rights. And, you know, *this is okay*. Privacy is culturally defined. Enjoy your culture, accept or reject its definition of privacy as you like. Just don't think that your culture's definition is somehow the only one, or universally agreed-upon, or... If there is no agreed-upon universal definition of privacy (and there isn't), then any attempt to make sweeping statements like "anonymity is a necessary condition of privacy" is just a bunch of freshman Philosophy 101 crap that's entirely disconnected from the real world. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 850 bytes Desc: This is a digitally signed message part URL: From spam.trap.mailing.lists at gmail.com Wed Jan 6 00:09:31 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 6 Jan 2021 00:09:31 +0100 Subject: On future of GnuPG In-Reply-To: References: <87turvmoto.fsf@wheatstone.g10code.de> Message-ID: On Tue, Jan 5, 2021 at 9:05 PM wrote: > > On 2021-01-05 Stefan Claas via Gnupg-users - gnupg-users at gnupg.org wrote: > > ... but why are then SKS key servers > > still in operation, which allows third parties to look up who signed > > who's key and with what trust level and GnuPG's WoT support, compared > > to sq and Hagrid? > > The landscape has changed dramatically from the times when the > original PGP fundamentals were introduced. Today, for any secure > personal communication system to be of practical use, it must > be designed from the ground up observing the following simple > principle: *anonymity is the necessary condition of privacy*. That the landscape has changed dramatically everyone will (hopefully) agree and your phrase is perfectly fine, but I do not consider GnuPG or OpenPGP apps as tools giving users anonymity. What you say would fit more for a cross-platform OpenSource app like Bitmessage, compared to PGP's or GnuPG's privacy philosophy. Regards Stefan From spam.trap.mailing.lists at gmail.com Wed Jan 6 00:23:37 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 6 Jan 2021 00:23:37 +0100 Subject: On future of GnuPG In-Reply-To: References: <87turvmoto.fsf@wheatstone.g10code.de> Message-ID: On Wed, Jan 6, 2021 at 12:09 AM Stefan Claas wrote: > What you say would fit more for a cross-platform OpenSource app > like Bitmessage, compared to PGP's or GnuPG's privacy philosophy. Regarding Bitmessage and OpenPGP. There was an announcement made last year about an Bitmessage OpenPGP chan, where people can discuss all things around OpenPGP anonymously and globally. I am a bit out of the loop regarding Bitmessage but here is the address for interested parties: OpenPGP BM-2cU9MZTNKThqH9nDPycVaPGAduisN6Nnm1 Regards Stefan From mailinglist at chiraag.me Wed Jan 6 00:34:50 2021 From: mailinglist at chiraag.me (=?utf-8?B?4LKa4LK/4LKw4LK+4LKX4LONIOCyqOCyn+CysOCyvuCynOCzjQ==?=) Date: Tue, 05 Jan 2021 23:34:50 +0000 Subject: On future of GnuPG In-Reply-To: References: <87turvmoto.fsf@wheatstone.g10code.de> Message-ID: 12021/00/04 08:01.47 ?????, markus.rosco at neverbox.com ??????: > > On 2021-01-05 Stefan Claas via Gnupg-users - gnupg-users at gnupg.org wrote: > > ... but why are then SKS key servers > > still in operation, which allows third parties to look up who signed > > who's key and with what trust level and GnuPG's WoT support, compared > > to sq and Hagrid? > > The landscape has changed dramatically from the times when the > original PGP fundamentals were introduced. Today, for any secure > personal communication system to be of practical use, it must > be designed from the ground up observing the following simple > principle: *anonymity is the necessary condition of privacy*. That depends heavily on your threat model, though. For many people, the goal isn't to keep their identity safe from the people they're talking with. Rather, the goal is to keep the contents of their messages safe from _everyone else_ (including CIA, NSA, shitty governments, etc). In many ways, security and anonymity are at odds, since if I can't easily verify that is the person they claim to be, I have no way of knowing if I'm telling them stuff they shouldn't know. While there are ways to ensure confidentiality and integrity of the *communication channel* while preserving anonymity, there isn't really a way of ensuring the integrity of the *conversation* while preserving anonymity. Pretty much any way of properly resolving this dilemma requires de-anonymizing both participants, and then we're right back where we started. If, instead, we acknowledge that most use cases require integrity of the communication channel *and* the conversation, then we can use common identifiers (like phone numbers) or (mostly) verifiable identities (like GPG keys hosted on WKD) to ensure the integrity of the conversation (I say mostly verifiable because there's always a chance the domain is compromised and the keys are replaced). Once anonymity isn't really as much of a concern, we get things like Signal, which is decidedly *not* anonymous (with the exception of using VOIP numbers to sign up) but is most assuredly private (they don't know what you're saying and neither does anyone else, apart from the people you're messaging). Regards, Chiraag -- ?????? ?????? Pronouns: he/him/his -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - mailinglist at chiraag.me - b0c8d720.asc Type: application/pgp-keys Size: 659 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 233 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Wed Jan 6 14:00:47 2021 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 6 Jan 2021 14:00:47 +0100 Subject: On future of GnuPG In-Reply-To: <652d31a89d4f4eaa216d792b93c0986d186e7dca.camel@sixdemonbag.org> References: <87turvmoto.fsf@wheatstone.g10code.de> <652d31a89d4f4eaa216d792b93c0986d186e7dca.camel@sixdemonbag.org> Message-ID: On 05-01-2021 23:07, Robert J. Hansen via Gnupg-users wrote: As always, it probably depends on who you have the most to fear from: your government, corporations, or maybe someone else? > In Europe it's a lot different. There, the prevailing culture cares a > lot more about limiting the ability of businesses to learn things about > a person than with limiting the ability of governments. That is changing. Now that governments are ourtsourcing censorship to corporations in their struggle against unwelcome news (these days they call that often "fake news" or "Russian propaganda" and voices are getting stronger to censor unwelcome messages directly, recently enhanced by protests against the covid measures, protection against the government are getting more important in Europe as well. But that is not yet much reflected in actual policies being made, mainly because those policies are made by the very people we need protection against. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From wk at gnupg.org Wed Jan 6 14:58:15 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Jan 2021 14:58:15 +0100 Subject: Plan B - Who carries the torch? In-Reply-To: (Stefan Claas's message of "Tue, 5 Jan 2021 16:46:20 +0100") References: <87turvmoto.fsf@wheatstone.g10code.de> Message-ID: <87zh1mkw08.fsf@wheatstone.g10code.de> On Tue, 5 Jan 2021 16:46, Stefan Claas said: > Not sure I understand you correctly, but why are then SKS key servers > still in operation, which allows third parties to look up who signed > who's key and with what trust level and GnuPG's WoT support, compared Because that is the base of the WoT and there a legitimate use cases for this. You might also want to learn on how the WoT works to see why the keyservers don't carry any information on what you call "trust level" and what we call "ownertrust". Just in case you meant the signature class (0x10..0x13 aka generic,persona,casual,positive) the default is "generic" and you need to employ the --ask-cert-level option to change the default on a key by key case. Further, the plan is to replace the SKS software by hockeypuck on the servers. Thus the existing defaults are still good defaults. 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 Wed Jan 6 15:23:22 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Jan 2021 15:23:22 +0100 Subject: On future of GnuPG In-Reply-To: <652d31a89d4f4eaa216d792b93c0986d186e7dca.camel@sixdemonbag.org> (Robert J. Hansen via Gnupg-users's message of "Tue, 05 Jan 2021 17:07:11 -0500") References: <87turvmoto.fsf@wheatstone.g10code.de> <652d31a89d4f4eaa216d792b93c0986d186e7dca.camel@sixdemonbag.org> Message-ID: <87v9cakuud.fsf@wheatstone.g10code.de> On Tue, 5 Jan 2021 17:07, Robert J. Hansen said: > I'm doing is sharing true things with my buddy?" Whereas in Europe, > right-to-be-forgotten laws, enforced by the government, are seen as > wins for privacy, in America they would be (a) blatantly unlawful and I don't think that the right not to be listed prominently in search results is related to privacy. This ruling is more similar to rules that you are not required to wear a badge that you spent some time in jail or need to state this in your CV. > In Europe it's a lot different. There, the prevailing culture cares a > lot more about limiting the ability of businesses to learn things about > a person than with limiting the ability of governments. The national Like all over the world governments work on terminating all rules which limit their power. It seems to be a never-ending task to counter that. Speaking of Germany: There are a lot of barriers between administrative entities to share data - there is not even a central database of all citizens. There is no shared access between the databases of the police and the spooks. The spooks tried to tell us that it is okay to eavesdrop as long as no German citizen is part of the communication but courts declared such a workaround as illegal. But yes, all these laws and rulings wind up faster and faster :-( 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 spam.trap.mailing.lists at gmail.com Wed Jan 6 16:28:21 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 6 Jan 2021 16:28:21 +0100 Subject: Plan B - Who carries the torch? In-Reply-To: <87zh1mkw08.fsf@wheatstone.g10code.de> References: <87turvmoto.fsf@wheatstone.g10code.de> <87zh1mkw08.fsf@wheatstone.g10code.de> Message-ID: On Wed, Jan 6, 2021 at 3:00 PM Werner Koch wrote: > > On Tue, 5 Jan 2021 16:46, Stefan Claas said: > > > Not sure I understand you correctly, but why are then SKS key servers > > still in operation, which allows third parties to look up who signed > > who's key and with what trust level and GnuPG's WoT support, compared > > Because that is the base of the WoT and there a legitimate use cases for > this. You might also want to learn on how the WoT works to see why the > keyservers don't carry any information on what you call "trust level" > and what we call "ownertrust". Just in case you meant the signature > class (0x10..0x13 aka generic,persona,casual,positive) the default is > "generic" and you need to employ the --ask-cert-level option to change > the default on a key by key case. Thanks for the reply and clarifying. > Further, the plan is to replace the SKS software by hockeypuck on the > servers. Thus the existing defaults are still good defaults. Ah, interesting. You know, what would be cool if a hockeypuck testnet would be run first, starting from zero, so that everybody interested in this new keyserver network can participate, like submitting their keys etc. and later it get's transfered to a mainnet without old useless keys, to have a fresh and clean database. I guess even the most hardcore SKS fan would agree that this should be not to much work for users, submitting only once their actual key(s) and revoked keys. Regards Stefan From dino.edwards at mydirectmail.net Wed Jan 6 15:14:32 2021 From: dino.edwards at mydirectmail.net (Dino Edwards) Date: Wed, 6 Jan 2021 14:14:32 +0000 Subject: Export private key Message-ID: <37d601428f214e9b915da9a43090cf9e@mydirectmail.net> Hello all, In the past I used to be able to export a private key using the following command: /usr/bin/gpg --homedir /opt/.gnupg/ --export-secret-key -a "SOMEKEYID" > /opt /tmp/private.key Something changed in the code and it now prompts me for the key password before it proceeds. I see the value in this, however this is problematic when I'm trying to automate the export to use in an application. What is the correct way to pass the key password in the command line in order to export the private key without getting the password prompt? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Wed Jan 6 16:47:54 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 6 Jan 2021 15:47:54 +0000 Subject: Export private key In-Reply-To: <37d601428f214e9b915da9a43090cf9e@mydirectmail.net> References: <37d601428f214e9b915da9a43090cf9e@mydirectmail.net> Message-ID: On 06/01/2021 14:14, Dino Edwards via Gnupg-users wrote: > Hello all, > > In the past I used to be able to export a private key using the > following command: > > /usr/bin/gpg --homedir /opt/.gnupg/ --export-secret-key -a "SOMEKEYID" > > /opt /tmp/private.key > > Something changed in the code and it now prompts me for the key password > before it proceeds. I see the value in this, however this is problematic > when I?m trying to automate the export to use in an application. > > What is the correct way to pass the key password in the command line in > order to export the private key without getting the password prompt? You could try: gpg --passphrase-fd 3 ...more-options... 3 From ryan at digicana.com Wed Jan 6 17:08:31 2021 From: ryan at digicana.com (Ryan McGinnis) Date: Wed, 06 Jan 2021 16:08:31 +0000 Subject: Plan B - Who carries the torch? In-Reply-To: References: <87turvmoto.fsf@wheatstone.g10code.de> Message-ID: Why does GPG continue to be developed with email uses in mind even though it's now widely accepted that GPG is a terrible way to securely communicate with another person and that a number of much more secure, much more robust, much less complicated (from the end user perspective) solutions exist? I'm guessing it's the same reason. -Ryan McGinnis http://www.bigstormpicture.com PGP Fingerprint: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD ??????? Original Message ??????? On Tuesday, January 5th, 2021 at 9:46 AM, Stefan Claas via Gnupg-users wrote: > On Tue, Jan 5, 2021 at 3:44 PM Werner Koch via Gnupg-users > > gnupg-users at gnupg.org wrote: > > > On Tue, 5 Jan 2021 07:27, Jean-David Beyer said: > > > > > Building a web of trust is so hopeless, from my point of view, that I > > > > > > have abandonned gnupg. I have made keys for myself, obtained enigmail > > > > Virtually nobody uses the WoT. What people use are direct key > > > > signatures. That is you verify a key's owner and then sign that key. > > > > Usually not even exportable. Verification is often done by trust on > > > > first use. And that is okay for the majority of use cases. > > Not sure I understand you correctly, but why are then SKS key servers > > still in operation, which allows third parties to look up who signed > > who's key and with what trust level and GnuPG's WoT support, compared > > to sq and Hagrid? > > Regards > > Stefan > > Gnupg-users mailing list > > Gnupg-users at gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From dino.edwards at mydirectmail.net Wed Jan 6 17:12:32 2021 From: dino.edwards at mydirectmail.net (Dino Edwards) Date: Wed, 6 Jan 2021 16:12:32 +0000 Subject: Export private key In-Reply-To: References: <37d601428f214e9b915da9a43090cf9e@mydirectmail.net> Message-ID: <66dddefdc65e461abaa2cefa7cd30164@mydirectmail.net> > You could try: > gpg --passphrase-fd 3 ...more-options... 3 where somefile is a file containing the passphrase, or a fifo with a coprocess writing the passphrase to it... That did not seem to work. But after searching for gpg --passphrase-fd, I found the following command that works: /usr/bin/gpg --pinentry-mode=loopback --passphrase "SOMEPASSWORD" --homedir /opt/.gnupg/ --export-secret-key -a "SOMEKEYID" > /opt /tmp/private.key From kloecker at kde.org Wed Jan 6 17:15:59 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 06 Jan 2021 17:15:59 +0100 Subject: Export private key In-Reply-To: <37d601428f214e9b915da9a43090cf9e@mydirectmail.net> References: <37d601428f214e9b915da9a43090cf9e@mydirectmail.net> Message-ID: <1707609.CCSJRuPZ3Q@breq> On Mittwoch, 6. Januar 2021 15:14:32 CET Dino Edwards via Gnupg-users wrote: > What is the correct way to pass the key password in the command line in > order to export the private key without getting the password prompt? I think we need to take a step back and look at why you want to export the private key. Maybe there is a better solution for your use case that doesn't require the usage of --export-secret-key. Regards, Ingo From gnupg-users at storiepvtride.it Wed Jan 6 17:23:00 2021 From: gnupg-users at storiepvtride.it (jman) Date: Wed, 06 Jan 2021 17:23:00 +0100 Subject: Plan B - Who carries the torch? In-Reply-To: References: <87turvmoto.fsf@wheatstone.g10code.de> Message-ID: <87y2h69grf.fsf@nyarlathotep> Ryan McGinnis via Gnupg-users writes: > Why does GPG continue to be developed with email uses in mind even > though it's now widely accepted that GPG is a terrible way to securely > communicate with another person and that a number of much more secure, much > more > robust, much less complicated (from the end user perspective) > solutions exist? genuine question, what are other proposals for communicating in a way that is as secure and decentralized but simpler to handle for an end user (especially not technically inclined)? (apologies for kind-of-stealing the thread topic) thanks. Regards, From lockywolf at gmail.com Wed Jan 6 16:36:15 2021 From: lockywolf at gmail.com (Vladimir Nikishkin) Date: Wed, 06 Jan 2021 23:36:15 +0800 Subject: On future of GnuPG In-Reply-To: <87v9cakuud.fsf@wheatstone.g10code.de> References: <87turvmoto.fsf@wheatstone.g10code.de> <652d31a89d4f4eaa216d792b93c0986d186e7dca.camel@sixdemonbag.org> <87v9cakuud.fsf@wheatstone.g10code.de> Message-ID: <87a6tm3wrs.fsf@delllaptop.lockywolf.net> >This ruling is more similar to rules that you are not required to wear >a badge that you spent some time in jail or need to state this in your CV. It is a ruling that gives more power to the government, whatever the "declared goal" actually is. The actual usage of this rule is to hide blatant evidence of corruption of government officials from public sources. Werner Koch via Gnupg-users writes: > On Tue, 5 Jan 2021 17:07, Robert J. Hansen said: > >> I'm doing is sharing true things with my buddy?" Whereas in Europe, >> right-to-be-forgotten laws, enforced by the government, are seen as >> wins for privacy, in America they would be (a) blatantly unlawful and > > I don't think that the right not to be listed prominently in search > results is related to privacy. This ruling is more similar to rules > that you are not required to wear a badge that you spent some time in > jail or need to state this in your CV. > >> In Europe it's a lot different. There, the prevailing culture cares a >> lot more about limiting the ability of businesses to learn things about >> a person than with limiting the ability of governments. The national > > Like all over the world governments work on terminating all rules which > limit their power. It seems to be a never-ending task to counter that. > > Speaking of Germany: There are a lot of barriers between administrative > entities to share data - there is not even a central database of all > citizens. There is no shared access between the databases of the police > and the spooks. The spooks tried to tell us that it is okay to > eavesdrop as long as no German citizen is part of the communication but > courts declared such a workaround as illegal. But yes, all these laws > and rulings wind up faster and faster :-( > > > Shalom-Salam, > > Werner -- Vladimir Nikishkin (MiEr, lockywolf) (Laptop) From wk at gnupg.org Wed Jan 6 18:33:53 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Jan 2021 18:33:53 +0100 Subject: Export private key In-Reply-To: <37d601428f214e9b915da9a43090cf9e@mydirectmail.net> (Dino Edwards via Gnupg-users's message of "Wed, 6 Jan 2021 14:14:32 +0000") References: <37d601428f214e9b915da9a43090cf9e@mydirectmail.net> Message-ID: <87h7nukm0u.fsf@wheatstone.g10code.de> On Wed, 6 Jan 2021 14:14, Dino Edwards said: > Something changed in the code and it now prompts me for the key > password before it proceeds. I see the value in this, however this is Yes, since version 2.1. The reasons is that the internal store for the private key uses a more modern way of protecting the key. Thus when exporting in the OpenPGP format we need to re-encrypt and thus need to ask for the passphrase. As usual since 2.1 you need to pass --pinentry-mode=loopback and for example --passphrase-fd N so that the gpg-agent (which does the re-encryption) does not pop up a pinentry but asks back. If you do not need to convey the private key in OpenPGP format you can actually do easier: Run gpg as in this example $ gpg --with-colons --with-keygrip -K USERID_OR_FPR sec:-:4096:1:CD21A80AC8C52565:1505892159:::q:::scESC:::+:::23::0: fpr:::::::::B2CCB68383325D61BAC50F9FCD21A80AC8C52565: grp:::::::::AEFF9F945E3F569062FAF62D21F1ADFF4D9A0345: uid:-::::1505892159::AE446DD05E9FF3A53C106836A52904256819CBC3::rs[...] ssb:-:4096:1:9883B66CDCF2F7EA:1505892215::::::e:::+:::23: fpr:::::::::BE280C5D679B2219748052909883B66CDCF2F7EA: grp:::::::::C1B641A6DD92DECA9E1E4FF92AA8B8F1F90BCAE2: and grep for the the grp lines (keygrips); for example: $ [...] | awk -F: '$1=="grp" {print $10}' AEFF9F945E3F569062FAF62D21F1ADFF4D9A0345 C1B641A6DD92DECA9E1E4FF92AA8B8F1F90BCAE2 Then copy the files ~/.gnupg/private-key-v1.d/AEFF9F945E3F569062FAF62D21F1ADFF4D9A0345.key ~/.gnupg/private-key-v1.d/C1B641A6DD92DECA9E1E4FF92AA8B8F1F90BCAE2.key to the target machine. They are encrypted but better use a secure channel. You also need to copy the public keys the usual way. Using this method you may also selectively share a subkey. 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 yo at jacky.wtf Wed Jan 6 17:40:33 2021 From: yo at jacky.wtf (Jacky Alcine) Date: Wed, 06 Jan 2021 08:40:33 -0800 Subject: Plan B - Who carries the torch? In-Reply-To: References: <87turvmoto.fsf@wheatstone.g10code.de> Message-ID: <059526c8-5d90-40fa-8a44-203737785551@www.fastmail.com> It's hard to look towards the future if they invest in the past. I'm definitely on the younger side of this mailing list but GPG has definitely out lasted its usefuless. The majority of people using it don't even know they do and it's probably because of the use via Debian's packaging system. E-mail is definitely the carrier pigeon of communication today and I agree that the need to decouple the association is needed but that's like trying to remove hydrogen from water. The identities are so tied to it (inb4 fingerprints - please) that it's beyond time (like since 2010 imo) for something else - anything else tbh. On Wed, Jan 6, 2021, at 08:08, Ryan McGinnis via Gnupg-users wrote: > Why does GPG continue to be developed with email uses in mind even > though it's now widely accepted that GPG is a terrible way to securely > communicate with another person and that a number of much more secure, > much more robust, much less complicated (from the end user perspective) > solutions exist? I'm guessing it's the same reason. > > -Ryan McGinnis > http://www.bigstormpicture.com > PGP Fingerprint: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD > > ??????? Original Message ??????? > > On Tuesday, January 5th, 2021 at 9:46 AM, Stefan Claas via Gnupg-users > wrote: > > > On Tue, Jan 5, 2021 at 3:44 PM Werner Koch via Gnupg-users > > > > > gnupg-users at gnupg.org wrote: > > > > > > On Tue, 5 Jan 2021 07:27, Jean-David Beyer said: > > > > > > > > Building a web of trust is so hopeless, from my point of view, that I > > > > > > > > > have abandonned gnupg. I have made keys for myself, obtained enigmail > > > > > > > Virtually nobody uses the WoT. What people use are direct key > > > > > > > signatures. That is you verify a key's owner and then sign that key. > > > > > > > Usually not even exportable. Verification is often done by trust on > > > > > > > first use. And that is okay for the majority of use cases. > > > > > Not sure I understand you correctly, but why are then SKS key servers > > > > > still in operation, which allows third parties to look up who signed > > > > > who's key and with what trust level and GnuPG's WoT support, compared > > > > > to sq and Hagrid? > > > > > Regards > > > > > Stefan > > > > > Gnupg-users mailing list > > > > > Gnupg-users at gnupg.org > > > > > http://lists.gnupg.org/mailman/listinfo/gnupg-users > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Attachments: > * signature.asc From dino.edwards at mydirectmail.net Wed Jan 6 19:10:30 2021 From: dino.edwards at mydirectmail.net (Dino Edwards) Date: Wed, 6 Jan 2021 18:10:30 +0000 Subject: Export private key In-Reply-To: <1707609.CCSJRuPZ3Q@breq> References: <37d601428f214e9b915da9a43090cf9e@mydirectmail.net> <1707609.CCSJRuPZ3Q@breq> Message-ID: <60f3fb8f24354d4481ea044ff12fede2@mydirectmail.net> -----Original Message----- From: Gnupg-users On Behalf Of Ingo Kl?cker Sent: Wednesday, January 6, 2021 11:16 AM To: gnupg-users at gnupg.org Subject: Re: Export private key On Mittwoch, 6. Januar 2021 15:14:32 CET Dino Edwards via Gnupg-users wrote: > What is the correct way to pass the key password in the command line > in order to export the private key without getting the password prompt? > I think we need to take a step back and look at why you want to export the private key. Maybe there is a better solution for your use case that doesn't require > > the usage of --export-secret-key. Hi Ingo, I believe I got it figured out. Thanks _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From bernhard at intevation.de Thu Jan 7 10:37:03 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 7 Jan 2021 10:37:03 +0100 Subject: Plan B - Who carries the torch? In-Reply-To: References: Message-ID: <202101071037.23632.bernhard@intevation.de> Hi everybody, == who could continue development? Beside other options already mentioned, a) there is a charity https://gnupg.org/verein/ which currently is small with some of the already known people, and only starts to do a few small things, but at a legal entity it has some personal reserves that could be broadened. b) g10code GmbH is also a legal entity and has some more employees than Werner and Andre. If demand is high enough, one of those organisations can pick up. (So you know: I am with GnuPG e.V. and my company Intevation works together with g10code on Gpg4win. We offer paid support for all available Free Software products in principle. So to me that is more of a long term funding problem.) Because GnuPG/Gpg4win is completely Free Software, many companies, or other organisations can pick up its development. == about its usefulness: Personally I believe GnuPG, OpenPGP and email to important and on the course to stay for many years. Main reasons are: a) email use has not gone down. It is one of the remaining really decentral systems. b) And it has become and stays an identity anchor for the majority of internet based services. For this function public keyservers (decentral, carrying signatures) are important (to complement some use cases). 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: 659 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Jan 7 10:47:35 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 7 Jan 2021 10:47:35 +0100 Subject: Smartcard readers: Cherry ST 2100 Message-ID: <202101071047.44262.bernhard@intevation.de> Hi, just wanted to report that that Cherry ST-2100 smartcard reader responded without further configuration on Debian Buster with gnupg2-2.2.20-1~bpo10+1. Do we have a good place to collect experience reports about devices and tokens? Just tested gpg --card-status, do we have a good test (plan) or list what people would want to know about a cardreader or security token? Is it possible to test a security token and then completely reset it into the state before (aka factory reset)? == Details My Linux (the famous kernel) said usb 7-3: new full-speed USB device number 2 using ohci-pci usb 7-3: New USB device found, idVendor=046a, idProduct=003e, bcdDevice= 7.10 usb 7-3: New USB device strings: Mfr=1, Product=2, SerialNumber=5 usb 7-3: Product: SmartTerminal ST-2xxx usb 7-3: Manufacturer: Cherry GmbH usb 7-3: SerialNumber: ..... 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: 659 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Thu Jan 7 16:56:15 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 07 Jan 2021 16:56:15 +0100 Subject: Smartcard readers: Cherry ST 2100 In-Reply-To: <202101071047.44262.bernhard@intevation.de> References: <202101071047.44262.bernhard@intevation.de> Message-ID: <1981050.c1UpYWs4JK@breq> On Donnerstag, 7. Januar 2021 10:47:35 CET Bernhard Reiter wrote: > Hi, > > just wanted to report that that Cherry ST-2100 smartcard reader > responded without further configuration on Debian Buster > with gnupg2-2.2.20-1~bpo10+1. > > Do we have a good place to collect experience reports about devices > and tokens? https://wiki.gnupg.org/SmartCard collects some information and further references. https://wiki.debian.org/GnuPG/CCID_Driver (referenced on the above page) lists "smartcard readers and tokens supported by the GnuPG's in-stock CCID driver". > Just tested gpg --card-status, do we have a good test (plan) or list > what people would want to know about a cardreader or security token? > > Is it possible to test a security token and then completely reset it > into the state before (aka factory reset)? Depends. Some tokens can never be fully reset (e.g. TeleSec NetKey). Others can be reset for example with gpg --card-edit's factory-reset command (which may or may not be present in gpg 2.2.20) or with the (currently unreleased) gpg-card's factory-reset command. (gpg-card, the new administration tool for smart cards, will be part of GnuPG 2.3.) Regards, Ingo From spam.trap.mailing.lists at gmail.com Fri Jan 8 18:42:06 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Fri, 8 Jan 2021 18:42:06 +0100 Subject: WKD for GitHub pages Message-ID: Hi all, I just started to set-up a github-page and have also verified the page via Brave. I tried to set-up WKD for the page, like I did in the past for my 300baud.de Domain, but fetching the key with GnuPG does not work for me. :-( My key UID there is 'stefan at sac001.github.io' It would be really nice if a kind soul can help me to fix the issue. The idea here is the following: 1. A github.io pub key can IHMO serve as a multi-purpose usage key, thus not revealing the email address. 2. GitHub should be more protected against DDOS, compared to a website, hosted on an own VPS server, IMHO. 3. One already has an SSL cert. 4. GitHub allows creating rich-content static web pages. 5. Brave verification, so that in case one Brave user like to give a tip, it is possible too. 6. If this would work properly, Windows users, for example, would have an easy way to use WKD as well, without having an own server, Domain, etc. Hope you like the idea! Here's is my URL, which leads to the GitHub project, containing the .well-known folder. https://sac001.github.io Any help would greatly appreciated! Regards Stefan From spam.trap.mailing.lists at gmail.com Fri Jan 8 19:36:54 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Fri, 8 Jan 2021 19:36:54 +0100 Subject: WKD for GitHub pages In-Reply-To: References: Message-ID: Ok, had a typo in the openpgpkey folder, ouch. Now Wiktor's WKD checker gives the proper results in the first part, not sure why not in the second part. Need to try to fetch my pub key. Regards Stefan On Fri, Jan 8, 2021 at 6:42 PM Stefan Claas wrote: > > Hi all, > > I just started to set-up a github-page and have also verified > the page via Brave. I tried to set-up WKD for the page, like > I did in the past for my 300baud.de Domain, but fetching > the key with GnuPG does not work for me. :-( > > My key UID there is 'stefan at sac001.github.io' > > It would be really nice if a kind soul can help me to fix > the issue. > > The idea here is the following: > > 1. A github.io pub key can IHMO serve as a multi-purpose usage > key, thus not revealing the email address. > > 2. GitHub should be more protected against DDOS, compared > to a website, hosted on an own VPS server, IMHO. > > 3. One already has an SSL cert. > > 4. GitHub allows creating rich-content static web pages. > > 5. Brave verification, so that in case one Brave user like > to give a tip, it is possible too. > > 6. If this would work properly, Windows users, for example, > would have an easy way to use WKD as well, without having > an own server, Domain, etc. > > Hope you like the idea! > > Here's is my URL, which leads to the GitHub project, > containing the .well-known folder. > > https://sac001.github.io > > Any help would greatly appreciated! > > Regards > Stefan From andre at colomb.de Fri Jan 8 19:05:46 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Fri, 8 Jan 2021 19:05:46 +0100 Subject: WKD for GitHub pages In-Reply-To: References: Message-ID: Hi Stefan, > I just started to set-up a github-page and have also verified > the page via Brave. I tried to set-up WKD for the page, like > I did in the past for my 300baud.de Domain, but fetching > the key with GnuPG does not work for me. :-( You could try the online WKD checker here: https://metacode.biz/openpgp/web-key-directory It reports that the policy file is missing, which I think is a hard requirement, no? Also make sure that the MIME content type and Access-Control-Allow-Origin headers are set correctly. Kind regards, Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Fri Jan 8 22:00:05 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Fri, 8 Jan 2021 22:00:05 +0100 Subject: WKD for GitHub pages In-Reply-To: References: Message-ID: On Fri, Jan 8, 2021 at 7:36 PM Stefan Claas wrote: > > Ok, had a typo in the openpgpkey folder, ouch. > > Now Wiktor's WKD checker gives the proper > results in the first part, not sure why not in the > second part. > > Need to try to fetch my pub key. Does not work, 'wrong name' I guess I could put a CNAME file into my GitHub folder, pointing to a Domain which I own and upload a new key with that Domain, but this is *not* what I want to do, because of the opportunity it would give Windows users to follow my set-up without an own server and own domain and because GitHub is globally probably not blocked and a trusted Domain for millions of programmers. Regards Stefan From spam.trap.mailing.lists at gmail.com Fri Jan 8 22:21:09 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Fri, 8 Jan 2021 22:21:09 +0100 Subject: WKD for GitHub pages In-Reply-To: References: Message-ID: On Fri, Jan 8, 2021 at 10:07 PM Andr? Colomb wrote: > > Hi Stefan, > > > I just started to set-up a github-page and have also verified > > the page via Brave. I tried to set-up WKD for the page, like > > I did in the past for my 300baud.de Domain, but fetching > > the key with GnuPG does not work for me. :-( > > You could try the online WKD checker here: > https://metacode.biz/openpgp/web-key-directory Hi Andre, I used Wiktor's WKD checker which you link to. :-) > > It reports that the policy file is missing, which I think is a hard > requirement, no? > > Also make sure that the MIME content type and > Access-Control-Allow-Origin headers are set correctly. I guess I have created a new use case, regarding WKD usage for GitHub pages and how Werner implemented WKD. I guess the only way to fix it (for many people) would be that, as of my understanding (now) the WKD check and SSL cert check would be a bit more flexible, either in allowing subdomains, like the github.io ones in form of a fix in the code or as setting in GnuPG' config file. I could be totally wrong of course, so let's see what Werner says. Regards Stefan From spam.trap.mailing.lists at gmail.com Fri Jan 8 23:05:52 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Fri, 8 Jan 2021 23:05:52 +0100 Subject: WKD for GitHub pages In-Reply-To: References: Message-ID: On Fri, Jan 8, 2021 at 10:21 PM Stefan Claas wrote: > I guess the only way to fix it (for many people) would be > that, as of my understanding (now) the WKD check > and SSL cert check would be a bit more flexible, either > in allowing subdomains, like the github.io ones in form > of a fix in the code or as setting in GnuPG' config file. > > I could be totally wrong of course, so let's see what > Werner says. Well, I guess I am right, just did a gpg --debug-level guru under cmd.exe: gpg --debug-level guru --locate-key stefan at sac001.github.io gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog gpg: DBG: [not enabled in the source] start gpg: DBG: [not enabled in the source] keydb_new gpg: DBG: [not enabled in the source] keydb_search enter gpg: DBG: keydb_search: 1 search descriptions: gpg: DBG: keydb_search 0: SUBSTR: 'stefan at sac001.github.io' gpg: DBG: keydb_search: searching keybox (resource 0 of 1) gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => EOF gpg: DBG: [not enabled in the source] keydb_search leave (not found) gpg: DBG: chan_0x00000254 <- # Home: C:/Users/Nutzer/AppData/Roaming/gnupg gpg: DBG: chan_0x00000254 <- # Config: C:/Users/Nutzer/AppData/Roaming/gnupg/dirmngr.conf gpg: DBG: chan_0x00000254 <- OK Dirmngr 2.2.25 at your service gpg: DBG: connection to the dirmngr established gpg: DBG: chan_0x00000254 -> GETINFO version gpg: DBG: chan_0x00000254 <- D 2.2.25 gpg: DBG: chan_0x00000254 <- OK gpg: DBG: chan_0x00000254 -> KEYSERVER --clear hkps://keyserver.ubuntu.com gpg: DBG: chan_0x00000254 <- OK gpg: DBG: chan_0x00000254 -> KEYSERVER gpg: DBG: chan_0x00000254 <- S KEYSERVER hkps://keyserver.ubuntu.com gpg: DBG: chan_0x00000254 <- OK gpg: DBG: chan_0x00000254 -> KEYSERVER --clear hkps://keyserver.ubuntu.com gpg: DBG: chan_0x00000254 <- OK gpg: DBG: chan_0x00000254 -> KS_GET -- =stefan at sac001.github.io gpg: DBG: chan_0x00000254 <- S PROGRESS tick ? 0 0 gpg: DBG: chan_0x00000254 <- S SOURCE https://162.213.33.8:443 gpg: DBG: chan_0x00000254 <- ERR 167772218 Keine Daten gpg: Fehler beim automatischen holen von `stefan at sac001.github.io' ?ber `keyserver': Keine Daten gpg: DBG: chan_0x00000254 -> KEYSERVER --clear hkps://keyserver.ubuntu.com gpg: DBG: chan_0x00000254 <- OK gpg: DBG: chan_0x00000254 -> DNS_CERT --dane stefan at sac001.github.io gpg: DBG: chan_0x00000254 <- ERR 167772187 Nicht gefunden gpg: Fehler beim automatischen holen von `stefan at sac001.github.io' ?ber `DANE': Nicht gefunden gpg: DBG: chan_0x00000254 -> DNS_CERT * stefan.sac001.github.io gpg: DBG: chan_0x00000254 <- ERR 167772187 Nicht gefunden gpg: Fehler beim automatischen holen von `stefan at sac001.github.io' ?ber `DNS CERT': Nicht gefunden gpg: DBG: chan_0x00000254 -> DNS_CERT --pka -- stefan at sac001.github.io gpg: DBG: chan_0x00000254 <- ERR 167772187 Nicht gefunden gpg: Fehler beim automatischen holen von `stefan at sac001.github.io' ?ber `PKA': Nicht gefunden gpg: DBG: chan_0x00000254 -> WKD_GET -- stefan at sac001.github.io gpg: DBG: chan_0x00000254 <- S SOURCE https://openpgpkey.sac001.github.io gpg: DBG: chan_0x00000254 <- S NOTE tls_cert_error 285212985 bad cert for 'openpgpkey.sac001.github.io': Hostname does not match the certificate gpg: Hinweis: Der Server benutzt eine ung?ltiges Zertifikat gpg: DBG: chan_0x00000254 <- ERR 285212985 Falscher Name gpg: Fehler beim automatischen holen von `stefan at sac001.github.io' ?ber `WKD': Falscher Name gpg: Fehler beim automatischen holen von `stefan at sac001.github.io' ?ber `LDAP': Nich implementiert gpg: error reading key: Nich implementiert gpg: DBG: chan_0x00000254 -> BYE gpg: DBG: [not enabled in the source] stop gpg: keydb: handles=1 locks=0 parse=0 get=0 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=0 not=1 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=0 cached=0 good=0 bad=0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x00000000 calls=0 bytes=0 gpg: secmem usage: 0/32768 bytes in 0 blocks Regards Stefan From andre at colomb.de Fri Jan 8 23:24:39 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Fri, 8 Jan 2021 23:24:39 +0100 Subject: WKD for GitHub pages In-Reply-To: References: Message-ID: <4a900912-c3a3-9d6f-6944-8d71579b5cc6@colomb.de> Hi Stefan, your key seems to work fine over that WKD setup. > Now Wiktor's WKD checker gives the proper > results in the first part, not sure why not in the > second part. You don't need the "Advanced" method if the direct one already works. They basically exist to provide flexibility for server admins to decide whether they want to issue a TLS certificate for the whole domain matching the e-mail address, or just serve the WKD stuff through a dedicated "openpgpkey" subdomain. The latter could be easier if the WKD webserver should be isolated from other things on the domain. In your setup, the valid TLS certificate for sac001.github.io is the only one you'll get, so the "Direct" method fits perfectly. Nice idea actually, but you'd have to check if GitHub actually allows such use for "arbitrary" data distribution. Good night. Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Fri Jan 8 23:34:59 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Fri, 8 Jan 2021 23:34:59 +0100 Subject: WKD for GitHub pages In-Reply-To: <4a900912-c3a3-9d6f-6944-8d71579b5cc6@colomb.de> References: <4a900912-c3a3-9d6f-6944-8d71579b5cc6@colomb.de> Message-ID: On Fri, Jan 8, 2021 at 11:27 PM Andr? Colomb wrote: > > Hi Stefan, > > your key seems to work fine over that WKD setup. > > > Now Wiktor's WKD checker gives the proper > > results in the first part, not sure why not in the > > second part. > > You don't need the "Advanced" method if the direct one already works. > They basically exist to provide flexibility for server admins to decide > whether they want to issue a TLS certificate for the whole domain > matching the e-mail address, or just serve the WKD stuff through a > dedicated "openpgpkey" subdomain. The latter could be easier if the WKD > webserver should be isolated from other things on the domain. > > In your setup, the valid TLS certificate for sac001.github.io is the > only one you'll get, so the "Direct" method fits perfectly. > > Nice idea actually, but you'd have to check if GitHub actually allows > such use for "arbitrary" data distribution. > > Good night. > Andr? Hi Andre, as onbe could see from my previous reply, it does not work with gpg4win and I tested it also under my Debian subsystem, which didn't worked either. :-( But (sorry to say this here on the GnuPG ML) good news is I just tested it with an older version of sequoia-pgp and guess what it works for me. :-) sq wkd get stefan at sac001.github.io -----BEGIN PGP PUBLIC KEY BLOCK----- Comment: 3731 D9F8 1352 A24D F7E5 F33A 0885 70FC E611 8FD8 Comment: Stefan Claas xjMEX/dLDhYJKwYBBAHaRw8BAQdAvkbNdsFggQBabk4URQN/Fha+qsyFsCt4Tsti hShJKlvNJlN0ZWZhbiBDbGFhcyA8c3RlZmFuQHNhYzAwMS5naXRodWIuaW8+wpAE ExYIADgWIQQ3Mdn4E1KiTffl8zoIhXD85hGP2AUCX/dLDgIbAwULCQgHAgYVCgkI CwIEFgIDAQIeAQIXgAAKCRAIhXD85hGP2HTyAQDCXANVu9GtjOV+u/Wn8Y7Ad/iR mVLo34AOrMuU6dxRIQEAjqs8nMbLJHi6DNuizrMEU1lhcV67hyV9+pzn/VCPuQHO OARf90sOEgorBgEEAZdVAQUBAQdAVOixEkd6S9j0tYAcCEIDwS5/M7XbeLjgA8Zm dJIGqygDAQgHwngEGBYIACAWIQQ3Mdn4E1KiTffl8zoIhXD85hGP2AUCX/dLDgIb DAAKCRAIhXD85hGP2Ks7AP98+j9JNC+TyfDcoYQMS+ZY85XOx7IQTg0G1JPJCrIc CAD/SnccgwcFIjW83RHjIgtTomYdIoq/l8lwEzPfKHigLQg= =wPCo -----END PGP PUBLIC KEY BLOCK----- Regards and Good Night Stefan From neal at walfield.org Sat Jan 9 11:37:14 2021 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 09 Jan 2021 11:37:14 +0100 Subject: WKD for GitHub pages In-Reply-To: References: Message-ID: <87lfd2bdlx.wl-neal@walfield.org> Hi Stefan, On Fri, 08 Jan 2021 23:05:52 +0100, Stefan Claas via Gnupg-users wrote: > On Fri, Jan 8, 2021 at 10:21 PM Stefan Claas > wrote: > > > I guess the only way to fix it (for many people) would be > > that, as of my understanding (now) the WKD check > > and SSL cert check would be a bit more flexible, either > > in allowing subdomains, like the github.io ones in form > > of a fix in the code or as setting in GnuPG' config file. > > > > I could be totally wrong of course, so let's see what > > Werner says. > > Well, I guess I am right, just did a gpg --debug-level guru > under cmd.exe: > > ... > gpg: DBG: chan_0x00000254 -> WKD_GET -- stefan at sac001.github.io > gpg: DBG: chan_0x00000254 <- S SOURCE https://openpgpkey.sac001.github.io > gpg: DBG: chan_0x00000254 <- S NOTE tls_cert_error 285212985 bad cert > for 'openpgpkey.sac001.github.io': Hostname does not match the > certificate > gpg: Hinweis: Der Server benutzt eine ung?ltiges Zertifikat > gpg: DBG: chan_0x00000254 <- ERR 285212985 Falscher Name It appears that gpg is trying the advanced lookup method, gets an error, and then doesn't fallback to the direct lookup method. This is consistent with the I-D: 3.1. Key Discovery ... There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. Only if the required sub-domain does not exist, they SHOULD fall back to the direct method. https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07 It appears that github.com's DNS is configured such that all domains under github.com resolve to github.com's web server, even subsubdomains. For instance, https://asdflkjasdfj.asdflkjasdflkj.github.com/ resolves to a 404. So, it seems that you'll need to create openpgpkey.sac001.github.com. Further, you'll have to figure out how to get a valid certificate for it. At least Firefox considers github.com's certificate to be valid for foo.github.com, but not bar.foo.github.com. :) Neal From a.yousar at informatik.hu-berlin.de Sat Jan 9 11:44:45 2021 From: a.yousar at informatik.hu-berlin.de (Annie Yousar) Date: Sat, 9 Jan 2021 11:44:45 +0100 Subject: Binding of an encryption key to an e-mail address Message-ID: <893bfb67-2767-97b0-1fdc-71438d17860f@informatik.hu-berlin.de> Hi all, if a user A has a secret (signing/certification) key K and two e-mail adresses A1 and A2, the OpenPGP key consists of the following packets: * public key K packet * user ID A1 packet * signature packet over K and A1 signed with K * user ID A2 packet * signature packet over K and A2 signed with K Is it possible to create encryption keys E1 and E2 bound respectively to A1 and A2? Looking at the packets after E1/E2 creation we got only public key packets binding E1/E2 to K but not to the adresses: * public key E1 packet * signature packet over K and E1 signed with K * public key E2 packet * signature packet over K and E2 signed with K How to create a signature packet over K, A1 and E1 signed with K in GnuPG? /Ann. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam.trap.mailing.lists at gmail.com Sat Jan 9 14:37:34 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 9 Jan 2021 14:37:34 +0100 Subject: WKD for GitHub pages In-Reply-To: <87lfd2bdlx.wl-neal@walfield.org> References: <87lfd2bdlx.wl-neal@walfield.org> Message-ID: On Sat, Jan 9, 2021 at 11:37 AM Neal H. Walfield wrote: > It appears that gpg is trying the advanced lookup method, gets an > error, and then doesn't fallback to the direct lookup method. This is > consistent with the I-D: > > 3.1. Key Discovery > > ... > > There are two variants on how to form the request URI: The advanced > and the direct method. Implementations MUST first try the advanced > method. Only if the required sub-domain does not exist, they SHOULD > fall back to the direct method. > > https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07 > > It appears that github.com's DNS is configured such that all domains > under github.com resolve to github.com's web server, even > subsubdomains. For instance, > https://asdflkjasdfj.asdflkjasdflkj.github.com/ resolves to a 404. > > So, it seems that you'll need to create openpgpkey.sac001.github.com. > Further, you'll have to figure out how to get a valid certificate for > it. At least Firefox considers github.com's certificate to be valid > for foo.github.com, but not bar.foo.github.com. Hi Neal, thanks for the reply, much appreciated! Simply said, for the average user like me, I believe GitHub is doing it right, because it is a valid option according to their SSL cert data, and Werner simply overlooked this option. I will not experiment any further, because I set-up WKD properly, which works with sequoia-pgp, for example. I have not checked other OpenPGP software. And I strongly believe that Werner can fix this issue, if he is willing to do so. Best regards Stefan From spam.trap.mailing.lists at gmail.com Sat Jan 9 15:43:14 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 9 Jan 2021 15:43:14 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <87lfd2bdlx.wl-neal@walfield.org> Message-ID: On Sat, Jan 9, 2021 at 2:37 PM Stefan Claas wrote: > Hi Neal, > > thanks for the reply, much appreciated! Simply said, for the average > user like me, I believe GitHub is doing it right, because it is a > valid option according to their SSL cert data, and Werner simply > overlooked this option. I will not experiment any further, because I > set-up WKD properly, which works with sequoia-pgp, for example. I have > not checked other OpenPGP software. > > And I strongly believe that Werner can fix this issue, if he is > willing to do so. Example: If I would be the host master of the domain bund.de with it's many subdomains and authorities would request that WKD, as an inexpensive inhouse option, has to be set-up... IMHO that would be the same case, if I am not mistaken. Regards Stefan From spam.trap.mailing.lists at gmail.com Sat Jan 9 17:41:59 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 9 Jan 2021 17:41:59 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <4a900912-c3a3-9d6f-6944-8d71579b5cc6@colomb.de> Message-ID: On Fri, Jan 8, 2021 at 11:34 PM Stefan Claas wrote: > But (sorry to say this here on the GnuPG ML) good news is > I just tested it with an older version of sequoia-pgp and guess > what it works for me. :-) > > sq wkd get stefan at sac001.github.io > -----BEGIN PGP PUBLIC KEY BLOCK----- > Comment: 3731 D9F8 1352 A24D F7E5 F33A 0885 70FC E611 8FD8 > Comment: Stefan Claas > > xjMEX/dLDhYJKwYBBAHaRw8BAQdAvkbNdsFggQBabk4URQN/Fha+qsyFsCt4Tsti > hShJKlvNJlN0ZWZhbiBDbGFhcyA8c3RlZmFuQHNhYzAwMS5naXRodWIuaW8+wpAE > ExYIADgWIQQ3Mdn4E1KiTffl8zoIhXD85hGP2AUCX/dLDgIbAwULCQgHAgYVCgkI > CwIEFgIDAQIeAQIXgAAKCRAIhXD85hGP2HTyAQDCXANVu9GtjOV+u/Wn8Y7Ad/iR > mVLo34AOrMuU6dxRIQEAjqs8nMbLJHi6DNuizrMEU1lhcV67hyV9+pzn/VCPuQHO > OARf90sOEgorBgEEAZdVAQUBAQdAVOixEkd6S9j0tYAcCEIDwS5/M7XbeLjgA8Zm > dJIGqygDAQgHwngEGBYIACAWIQQ3Mdn4E1KiTffl8zoIhXD85hGP2AUCX/dLDgIb > DAAKCRAIhXD85hGP2Ks7AP98+j9JNC+TyfDcoYQMS+ZY85XOx7IQTg0G1JPJCrIc > CAD/SnccgwcFIjW83RHjIgtTomYdIoq/l8lwEzPfKHigLQg= > =wPCo > -----END PGP PUBLIC KEY BLOCK----- If Alice and Bob would be my two minor children and we would create together a nice web presense here on GitHub, we could use WKD together on github.io pages. :-) Just uploaded to my WKD directory Alice and Bob's demo key and it works too. sq wkd get alice at sac001.github.io -----BEGIN PGP PUBLIC KEY BLOCK----- Comment: 7AD4 F939 3D41 7BBB A46C FA67 A6DE D562 6D79 841A Comment: Alice Demo xjMEX/nZ3RYJKwYBBAHaRw8BAQdA6wTK6ogT3OU2nrTEaHZlKHY776bh476vjjE0 9UpTERXNI0FsaWNlIERlbW8gPGFsaWNlQHNhYzAwMS5naXRodWIuaW8+wpAEExYI ADgWIQR61Pk5PUF7u6Rs+mem3tVibXmEGgUCX/nZ3QIbAwULCQgHAgYVCgkICwIE FgIDAQIeAQIXgAAKCRCm3tVibXmEGp3dAP9xviHVC/9GkEGyPvvW6xIM+RI+Saw4 tC4G35a0BfF2IgD7B11BEkBs8sCH1ED30rtzcQEMSyh/NmCgarrb2+pPEwfOOARf +dndEgorBgEEAZdVAQUBAQdAiRTB87bBCZm4Es5ycn/inPzqNxEazVahpDTnLXuX BjEDAQgHwngEGBYIACAWIQR61Pk5PUF7u6Rs+mem3tVibXmEGgUCX/nZ3QIbDAAK CRCm3tVibXmEGqd1AQCRBdFtUQhec2SrPEKmcnPP/qodovT8bnS83v7HwojzZQD+ NilVdXs+lZOknY7daIuBsIX8cj4FhjcvILusRUYzogE= =zpfj -----END PGP PUBLIC KEY BLOCK----- sq wkd get bob at sac001.github.io -----BEGIN PGP PUBLIC KEY BLOCK----- Comment: 9CF4 2351 254D 5D71 4460 05A9 39E0 8A8E 266D 3C87 Comment: Bob Demo xjMEX/nabxYJKwYBBAHaRw8BAQdANyaNp3WurFKBgyoWhwQ3yFmlRC097SZiPTH7 Eq7aoYbNH0JvYiBEZW1vIDxib2JAc2FjMDAxLmdpdGh1Yi5pbz7CkAQTFggAOBYh BJz0I1ElTV1xRGAFqTngio4mbTyHBQJf+dpvAhsDBQsJCAcCBhUKCQgLAgQWAgMB Ah4BAheAAAoJEDngio4mbTyHg98BAM/27zJGH+T58U9Iqgac0DcIRTRsvtqbCC9F kKxh56m3APwNAU8mNRPOMtcABhShUP6uDle2LOjS3Z4Dq3kpxoLyCs44BF/52m8S CisGAQQBl1UBBQEBB0BCjCbmoC8qyVpIO8io/sHXUrQHeZ5NOzrK7Gh1O6ArIQMB CAfCeAQYFggAIBYhBJz0I1ElTV1xRGAFqTngio4mbTyHBQJf+dpvAhsMAAoJEDng io4mbTyHLHwA/2WbvaZGlehWYFR2XNxzMl98GnzxLfdfn060V/Nb8sbpAQDxj0dL 375rY0lTSkw6EXJXHZkX8Kd5OptDzz3nltnHDg== =3fI4 -----END PGP PUBLIC KEY BLOCK----- Regards Stefan From kloecker at kde.org Sat Jan 9 19:23:24 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sat, 09 Jan 2021 19:23:24 +0100 Subject: WKD for GitHub pages In-Reply-To: References: Message-ID: <1862859.jlS65D8mFY@breq> On Samstag, 9. Januar 2021 15:43:14 CET Stefan Claas via Gnupg-users wrote: > On Sat, Jan 9, 2021 at 2:37 PM Stefan Claas > wrote: > > Hi Neal, > > > > thanks for the reply, much appreciated! Simply said, for the average > > user like me, I believe GitHub is doing it right, because it is a > > valid option according to their SSL cert data, and Werner simply > > overlooked this option. I will not experiment any further, because I > > set-up WKD properly, which works with sequoia-pgp, for example. I have > > not checked other OpenPGP software. > > > > And I strongly believe that Werner can fix this issue, if he is > > willing to do so. > > Example: If I would be the host master of the domain bund.de with it's > many subdomains and authorities would request that WKD, as an > inexpensive inhouse option, has to be set-up... > > IMHO that would be the same case, if I am not mistaken. No, it's not. Even if there's foo.bund.de, then there wouldn't be openpgpkey.foo.bund.de (unless foo.bund.de sets up the advanced variant of WKD). The problem with GitHub pages is apparently that openpgpkey.sac001.github.io resolves to an IP address (well, actually multiple addresses): $ host openpgpkey.sac001.github.io openpgpkey.sac001.github.io has address 185.199.109.153 openpgpkey.sac001.github.io has address 185.199.108.153 openpgpkey.sac001.github.io has address 185.199.110.153 openpgpkey.sac001.github.io has address 185.199.111.153 OTOH: $ host -t A bsi.bund.de bsi.bund.de has address 77.87.229.76 But: $ host -t A openpgpkey.bsi.bund.de openpgpkey.bsi.bund.de has no A record and therefore WKD would fall back to the direct method for bsi.bund.de. Regards, Ingo From spam.trap.mailing.lists at gmail.com Sat Jan 9 20:08:09 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 9 Jan 2021 20:08:09 +0100 Subject: WKD for GitHub pages In-Reply-To: <1862859.jlS65D8mFY@breq> References: <1862859.jlS65D8mFY@breq> Message-ID: On Sat, Jan 9, 2021 at 7:27 PM Ingo Kl?cker wrote: > > On Samstag, 9. Januar 2021 15:43:14 CET Stefan Claas via Gnupg-users wrote: > > Example: If I would be the host master of the domain bund.de with it's > > many subdomains and authorities would request that WKD, as an > > inexpensive inhouse option, has to be set-up... > > > > IMHO that would be the same case, if I am not mistaken. > > No, it's not. > > Even if there's foo.bund.de, then there wouldn't be openpgpkey.foo.bund.de > (unless foo.bund.de sets up the advanced variant of WKD). > > The problem with GitHub pages is apparently that openpgpkey.sac001.github.io > resolves to an IP address (well, actually multiple addresses): > > $ host openpgpkey.sac001.github.io > openpgpkey.sac001.github.io has address 185.199.109.153 > openpgpkey.sac001.github.io has address 185.199.108.153 > openpgpkey.sac001.github.io has address 185.199.110.153 > openpgpkey.sac001.github.io has address 185.199.111.153 host sac001.github.io sac001.github.io has address 185.199.111.153 sac001.github.io has address 185.199.109.153 sac001.github.io has address 185.199.110.153 sac001.github.io has address 185.199.108.153 works as well and why can sequoia-pgp handle this and not GnuPG, or gpg4win? Couldn't they not fall back then as well to the direct method? Regards Stefan From spam.trap.mailing.lists at gmail.com Sat Jan 9 20:50:54 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 9 Jan 2021 20:50:54 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <1862859.jlS65D8mFY@breq> Message-ID: On Sat, Jan 9, 2021 at 8:08 PM Stefan Claas wrote: > host sac001.github.io > sac001.github.io has address 185.199.111.153 > sac001.github.io has address 185.199.109.153 > sac001.github.io has address 185.199.110.153 > sac001.github.io has address 185.199.108.153 > > works as well and why can sequoia-pgp handle this and not GnuPG, > or gpg4win? Couldn't they not fall back then as well to the direct method? Wrong wording, not fall back but try direct method if for advanced method a cert error occurs. That would be probably only two lines of code or so. Regards Stefan From angel at pgp.16bits.net Sat Jan 9 22:56:29 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sat, 09 Jan 2021 22:56:29 +0100 Subject: Binding of an encryption key to an e-mail address In-Reply-To: <893bfb67-2767-97b0-1fdc-71438d17860f@informatik.hu-berlin.de> References: <893bfb67-2767-97b0-1fdc-71438d17860f@informatik.hu-berlin.de> Message-ID: <4a606be2fec7ee3922fe7619028a39005a6ba38e.camel@16bits.net> On 2021-01-09 at 11:44 +0100, Annie Yousar via Gnupg-users wrote: > How to create a signature packet over K, A1 and E1 signed with K in > GnuPG? Hello Ann The best way would probably be to use two pgp keys: (K1, A1, E1) and (K2, A2, E2) You could have two keys (K, A1, E1) and (K, A2, E2) and selectively handle one or the other, but they would be merged if someone imported both. Any reason not to create two keys? Best regards From kloecker at kde.org Sat Jan 9 23:06:26 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sat, 09 Jan 2021 23:06:26 +0100 Subject: WKD for GitHub pages In-Reply-To: References: Message-ID: <1779013.kBCGB1XJgi@breq> On Samstag, 9. Januar 2021 20:50:54 CET Stefan Claas via Gnupg-users wrote: > On Sat, Jan 9, 2021 at 8:08 PM Stefan Claas > wrote: > > host sac001.github.io > > sac001.github.io has address 185.199.111.153 > > sac001.github.io has address 185.199.109.153 > > sac001.github.io has address 185.199.110.153 > > sac001.github.io has address 185.199.108.153 > > > > works as well and why can sequoia-pgp handle this and not GnuPG, > > or gpg4win? Couldn't they not fall back then as well to the direct method? > > Wrong wording, not fall back but try direct method if for advanced method > a cert error occurs. The spec explicitly says: "Only if the required sub-domain does not exist, they SHOULD fall back to the direct method." Do you really think it would be a good idea if an application like gpg would simply ignore a certificate error and then try something else? Missing or wrong checks of server certificates are among the most common security problems in many apps because they open the door for MITM attacks. Yes, I know you don't suggest that gpg retrieves the key via the subdomain if the certificate check for the subdomain fails, but I still think it's wrong to ignore a potential security problem and try something else, unless the user told gpg explicitly to use the direct method only. (I haven't checked if there's an option for this.) Apparently, sequoia-pgp chose usability over following the spec to the letter. I hope they considered possible security implications. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From angel at pgp.16bits.net Sat Jan 9 23:39:25 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sat, 09 Jan 2021 23:39:25 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <87lfd2bdlx.wl-neal@walfield.org> Message-ID: <9ce0980049635897d680083dc1b1631048b29b6f.camel@16bits.net> On 2021-01-09 at 14:37 +0100, Stefan Claas via Gnupg-users wrote: > I believe GitHub is doing it right, because it is a > valid option according to their SSL cert data, and Werner simply > overlooked this option. It is not. A certificate for *.github.io doesn't cover openpgpkey.sac001.github.io See rule #2 of https://tools.ietf.org/html/rfc6125#section-6.4.3 It is also quite normal that they don't have certificates for "subsubdomains". I don't see an option in GitHub pages to configure further subdomains, and given that github usernames can't contain dots, it doesn't seem such "subsubdomains" would be used, so GitHub should probably stop resolving them. Best regards From spam.trap.mailing.lists at gmail.com Sat Jan 9 23:40:32 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 9 Jan 2021 23:40:32 +0100 Subject: WKD for GitHub pages In-Reply-To: <1779013.kBCGB1XJgi@breq> References: <1779013.kBCGB1XJgi@breq> Message-ID: On Sat, Jan 9, 2021 at 11:09 PM Ingo Kl?cker wrote: > > On Samstag, 9. Januar 2021 20:50:54 CET Stefan Claas via Gnupg-users wrote: > > On Sat, Jan 9, 2021 at 8:08 PM Stefan Claas > > wrote: > > > host sac001.github.io > > > sac001.github.io has address 185.199.111.153 > > > sac001.github.io has address 185.199.109.153 > > > sac001.github.io has address 185.199.110.153 > > > sac001.github.io has address 185.199.108.153 > > > > > > works as well and why can sequoia-pgp handle this and not GnuPG, > > > or gpg4win? Couldn't they not fall back then as well to the direct method? > > > > Wrong wording, not fall back but try direct method if for advanced method > > a cert error occurs. > > The spec explicitly says: > "Only if the required sub-domain does not exist, they SHOULD fall back to the > direct method." > > Do you really think it would be a good idea if an application like gpg would > simply ignore a certificate error and then try something else? > > Missing or wrong checks of server certificates are among the most common > security problems in many apps because they open the door for MITM attacks. > Yes, I know you don't suggest that gpg retrieves the key via the subdomain if > the certificate check for the subdomain fails, but I still think it's wrong to > ignore a potential security problem and try something else, unless the user > told gpg explicitly to use the direct method only. (I haven't checked if > there's an option for this.) > > Apparently, sequoia-pgp chose usability over following the spec to the letter. > I hope they considered possible security implications. Well, I wish Werner would chime in, because what I really don't understand why do we have two options, instead of one and why is the advanced method the first one to be checked, if we have as first one the direct method, which would tell me, as laymen, that a software would start first with the 'easier' method. Fact for me is, I do have a site, which users shows a valid SSL cert and sequoia-pgp honors this, while GnuPG and gpg4win do not honor this and give a cert error for IMHO a second option GnuPG and gpg4win offers. If for example WKD would be designed to only offer one option (advanced) well then I could understand this issue better and even then Werner could think of a GitHub subdomain solution. And if Werner would allow an option in GnuPG that users can set a flag to do this on their own 'risk' then this would be also IMHO a good option. Would be cool if GitHub staff would see this thread and discuss this with Werner. Regards Stefan From spam.trap.mailing.lists at gmail.com Sat Jan 9 23:49:35 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 9 Jan 2021 23:49:35 +0100 Subject: WKD for GitHub pages In-Reply-To: <9ce0980049635897d680083dc1b1631048b29b6f.camel@16bits.net> References: <87lfd2bdlx.wl-neal@walfield.org> <9ce0980049635897d680083dc1b1631048b29b6f.camel@16bits.net> Message-ID: On Sat, Jan 9, 2021 at 11:42 PM ?ngel wrote: > > On 2021-01-09 at 14:37 +0100, Stefan Claas via Gnupg-users wrote: > > I believe GitHub is doing it right, because it is a > > valid option according to their SSL cert data, and Werner simply > > overlooked this option. > > It is not. A certificate for *.github.io doesn't cover > openpgpkey.sac001.github.io > See rule #2 of https://tools.ietf.org/html/rfc6125#section-6.4.3 I was refering to wildcard subdomains, like my sac001.github.io subdomain, which is covered by GitHub's SSL cert. > > > It is also quite normal that they don't have certificates for > "subsubdomains". I don't see an option in GitHub pages to configure > further subdomains, and given that github usernames can't contain dots, > it doesn't seem such "subsubdomains" would be used, so GitHub should > probably stop resolving them. Yes, the openpgpkeys. part which Ingo showed with my domain and the IP addresses. Like I said in my previous reply to Ingo, It would be nice if GitHub staff would see this thread and talk with Werner. Regards Stefan From spam.trap.mailing.lists at gmail.com Sun Jan 10 00:16:52 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 10 Jan 2021 00:16:52 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <87lfd2bdlx.wl-neal@walfield.org> <9ce0980049635897d680083dc1b1631048b29b6f.camel@16bits.net> Message-ID: On Sat, Jan 9, 2021 at 11:49 PM Stefan Claas wrote: > Like I said in my previous reply to Ingo, It would be nice if GitHub staff would > see this thread and talk with Werner. Well, I just wrote GitHub support and asked if their staff can check this thread, which I linked to in my message. Let's see what the outcome is. Regards Stefan From angel at pgp.16bits.net Sun Jan 10 17:54:28 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 10 Jan 2021 17:54:28 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <1779013.kBCGB1XJgi@breq> Message-ID: <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> On 2021-01-09 at 23:40 +0100, Stefan Claas via Gnupg-users wrote: > Well, I wish Werner would chime in, because what I really don't > understand why do we have two options, instead of one and why is the > advanced method the first one to be checked, if we have as first one > the direct method, which would tell me, as laymen, that a software > would start first with the 'easier' method. The way it is defined, it makes complete sense. The advanced method allows a finer control. For example, you could have your web page in one hosting (such as a CDN you may not trust too much) and your pgp keys in a different host that you could consider more trustworthy. The terms easy and advanced refers to the difficulty of setting it up. Normally, creating a subdomain would be more complex (you need to create a second dns record, perhaps also create a new VirtualHost?). It is more powerful, but it's less accessible. You need to check the first, since the bare domain is pretty much guaranteed to exist, even without relation to openpgp keys. Plus, with the above, your lack of trust could be e.g. that you don't want them -for privacy reasons- to know which keys are being fetched. Using a separated host that is tried first solves it. > Fact for me is, I do have a site, which users shows a valid SSL cert > and sequoia-pgp honors this, while GnuPG and gpg4win do not honor > this and give a cert error for IMHO a second option GnuPG and gpg4win > offers. sequoia is in the wrong here. You don't have a valid SSL cert for openpgpkey.sac001.github.io Either they are not supporting the advanced method (maybe they follow an older draft?) or they ignore the certificate failure (which would be quite bad). The issue here is why github is publishing subdomains that nobody can use, anyway. This would usually be harder (why create a openpgp subdomain if you don't want it?), but GitHub configuration is already sufficiently advanced that it breaks this (it was simpler for them to configure their nameservers to also return that for subdomains?). Regards From spam.trap.mailing.lists at gmail.com Sun Jan 10 18:47:14 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 10 Jan 2021 18:47:14 +0100 Subject: WKD for GitHub pages In-Reply-To: <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> Message-ID: On Sun, Jan 10, 2021 at 6:01 PM ?ngel wrote: > sequoia is in the wrong here. You don't have a valid SSL cert for > openpgpkey.sac001.github.io Either they are not supporting the advanced > method (maybe they follow an older draft?) or they ignore the > certificate failure (which would be quite bad). > > > > The issue here is why github is publishing subdomains that nobody can > use, anyway. This would usually be harder (why create a openpgp > subdomain if you don't want it?), but GitHub configuration is already > sufficiently advanced that it breaks this (it was simpler for them to > configure their nameservers to also return that for subdomains?). Can you tell me/us in laymen terms how this works with gnupg.org? openpgpkey.gnupg.org has address 217.69.77.222 openpgpkey.gnupg.org has IPv6 address 2001:aa8:fff1:100::22 Regards Stefan From angel at pgp.16bits.net Sun Jan 10 23:18:47 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 10 Jan 2021 23:18:47 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> Message-ID: <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> On 2021-01-10 at 18:47 +0100, Stefan Claas via Gnupg-users wrote: > Can you tell me/us in laymen terms how this works with gnupg.org? > > openpgpkey.gnupg.org has address 217.69.77.222 > openpgpkey.gnupg.org has IPv6 address 2001:aa8:fff1:100::22 > > Regards > Stefan Sure. Let's suppose you wanted to fetch Werner's key. You want the key for wk at gnupg.org Using --with-wkd-hash parameter, we can see that this would generate nq6t9teux7edsnwdksswydu4o9i5es3f at gnupg.org Then, the key of Werner lives at https://openpgpkey.gnupg.org/.well-known/openpgpkey/gnupg.org/hu/nq6t9teux7edsnwdksswydu4o9i5es3f If openpgpkey.gnupg.org didn't exist, then it would use the direct schema, in which the key would be at https://gnupg.org/.well-known/openpgpkey/hu/nq6t9teux7edsnwdksswydu4o9i5es3f Best regards From daniel at pocock.pro Mon Jan 11 09:36:01 2021 From: daniel at pocock.pro (Daniel Pocock) Date: Mon, 11 Jan 2021 09:36:01 +0100 Subject: Reiner-SCT CyberJack secoder 2 (v2.2.0 USB 0c4b:0400) Message-ID: <0b5443d8-96c2-f19a-bec9-d91bdf60441b@pocock.pro> I was going through some old hardware and came across this device Is it useful with gnupg or any other free software? Can anybody provide any links about how to use it with free software? Or is it better to just throw it away/recycle it and use something newer? Reiner SCT cyberJack secoder 2 v2.2.0 USB: 0c4b:0400 Regards, Daniel -- Debian Developer https://danielpocock.com From spam.trap.mailing.lists at gmail.com Mon Jan 11 16:36:47 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Mon, 11 Jan 2021 16:36:47 +0100 Subject: WKD for GitHub pages In-Reply-To: <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> Message-ID: On Sun, Jan 10, 2021 at 11:22 PM ?ngel wrote: > > On 2021-01-10 at 18:47 +0100, Stefan Claas via Gnupg-users wrote: > > Can you tell me/us in laymen terms how this works with gnupg.org? > > > > openpgpkey.gnupg.org has address 217.69.77.222 > > openpgpkey.gnupg.org has IPv6 address 2001:aa8:fff1:100::22 > > > > Regards > > Stefan > > Sure. Let's suppose you wanted to fetch Werner's key. You want the key > for wk at gnupg.org Using --with-wkd-hash parameter, we can see that this > would generate nq6t9teux7edsnwdksswydu4o9i5es3f at gnupg.org > > Then, the key of Werner lives at > https://openpgpkey.gnupg.org/.well-known/openpgpkey/gnupg.org/hu/nq6t9teux7edsnwdksswydu4o9i5es3f > > If openpgpkey.gnupg.org didn't exist, then it would use the direct schema, in which the key would be at > https://gnupg.org/.well-known/openpgpkey/hu/nq6t9teux7edsnwdksswydu4o9i5es3f Thanks, so I think the culprit could be that maybe the specs were changed, when I look at your links, including the gnupg.org domain as a folder, which I never set-up when doing this for my 300baud.de domain. I checked also older WKD tutorials on the Internet and they do not mention a domain folder either. I tried to include this domain folder, this morning, named sac001 but it did not work either, whether with GnuPG or sequioa-pgp. So my guess is that GnuPG gives this cert error because it does not support wildcard subdomains, included in an SSL cert, like the GitHub one. Not sure if Let's Encrypt issues such certs. If, I could set-up two droplets at Digital Ocean, a bob.300baud.de one and an alice.300baud.de one and see what happens. Regards Stefan From spam.trap.mailing.lists at gmail.com Mon Jan 11 16:40:52 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Mon, 11 Jan 2021 16:40:52 +0100 Subject: Reiner-SCT CyberJack secoder 2 (v2.2.0 USB 0c4b:0400) In-Reply-To: <0b5443d8-96c2-f19a-bec9-d91bdf60441b@pocock.pro> References: <0b5443d8-96c2-f19a-bec9-d91bdf60441b@pocock.pro> Message-ID: On Mon, Jan 11, 2021 at 10:55 AM Daniel Pocock wrote: > > > I was going through some old hardware and came across this device > > Is it useful with gnupg or any other free software? > > Can anybody provide any links about how to use it with free software? > Or is it better to just throw it away/recycle it and use something newer? > > Reiner SCT cyberJack secoder 2 > v2.2.0 > USB: 0c4b:0400 If you have the drivers for your OS and can then run on it AusweisApp2 or the OpenSource app, which name I forgot, then you could use your nPA and let your public key(s) certify, for free, with Governikus, which gives you then a sig3. The Governikus CA is run on behalf of BSI IIRC. Regards Stefan From mailinglist at chiraag.me Mon Jan 11 16:51:57 2021 From: mailinglist at chiraag.me (=?utf-8?B?4LKa4LK/4LKw4LK+4LKX4LONIOCyqOCyn+CysOCyvuCynOCzjQ==?=) Date: Mon, 11 Jan 2021 15:51:57 +0000 Subject: WKD for GitHub pages In-Reply-To: References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> Message-ID: 12021/00/10 04:42.21 ?????, Stefan Claas via Gnupg-users ??????: > Not sure if Let's Encrypt issues such certs. If, I could set-up two droplets at > Digital Ocean, a bob.300baud.de one and an alice.300baud.de one and see > what happens. Let's Encrypt does offer such certificates. You can generate using e.g.: sudo certbot certonly --rsa-key-size 4096 --manual -d *.domain.tld (editing parameters as necessary). HTH! - Chiraag -- ?????? ?????? Pronouns: he/him/his -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - mailinglist at chiraag.me - b0c8d720.asc Type: application/pgp-keys Size: 659 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 233 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Mon Jan 11 17:32:59 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Mon, 11 Jan 2021 17:32:59 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> Message-ID: On Mon, Jan 11, 2021 at 4:55 PM ?????? ?????? via Gnupg-users wrote: > > 12021/00/10 04:42.21 ?????, Stefan Claas via Gnupg-users ??????: > > Not sure if Let's Encrypt issues such certs. If, I could set-up two droplets at > > Digital Ocean, a bob.300baud.de one and an alice.300baud.de one and see > > what happens. > > Let's Encrypt does offer such certificates. You can generate using e.g.: > > sudo certbot certonly --rsa-key-size 4096 --manual -d *.domain.tld > > (editing parameters as necessary). > > HTH! Great, thanks for the info! I will do this in the next couple of days, in case Werner does not chime in (assuming he is not 'AWOL'). Regards Stefan From andrewg at andrewg.com Mon Jan 11 18:13:04 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 11 Jan 2021 17:13:04 +0000 Subject: WKD for GitHub pages In-Reply-To: References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> Message-ID: <81ac6009-6855-e219-232a-34d4e4a6e263@andrewg.com> On 11/01/2021 16:32, Stefan Claas via Gnupg-users wrote: > I will do this in the next couple of days, in case Werner does not > chime in (assuming > he is not 'AWOL'). Stefan, please dial down the casual sniping at Werner. It's not constructive. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Mon Jan 11 19:39:48 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Mon, 11 Jan 2021 19:39:48 +0100 Subject: WKD for GitHub pages In-Reply-To: <81ac6009-6855-e219-232a-34d4e4a6e263@andrewg.com> References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> <81ac6009-6855-e219-232a-34d4e4a6e263@andrewg.com> Message-ID: On Mon, Jan 11, 2021 at 6:16 PM Andrew Gallagher wrote: > > On 11/01/2021 16:32, Stefan Claas via Gnupg-users wrote: > > I will do this in the next couple of days, in case Werner does not > > chime in (assuming > > he is not 'AWOL'). > > Stefan, please dial down the casual sniping at Werner. It's not > constructive. Ok, Andrew I hereby apologize to Werner! Regards Stefan From wk at gnupg.org Mon Jan 11 20:44:57 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Jan 2021 20:44:57 +0100 Subject: [Announce] GnuPG 2.2.27 released Message-ID: <874kjnjm12.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.27. This is a maintenance release fixing two recently introduced bugs. What is 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.27 (2021-01-11) ------------------------------------------------- * gpg: Fix regression in 2.2.24 for gnupg_remove function under Windows. [#5230] * gpgconf: Fix case with neither local nor global gpg.conf. [9f37d3e6f3] * gpgconf: Fix description of two new options. [#5221] * Build Windows installer without timestamps. Note that the Authenticode signatures still carry a timestamp. Release-info: https://dev.gnupg.org/T5234 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.27 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.27.tar.bz2 (7023k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.27.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.27_20210111.exe (4252k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.27_20210111.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. New versions of the GnuPG VS-Desktop(tm) and Gpg4win featuring this version of GnuPG will be released shortly. 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.27.tar.bz2 you would use this command: gpg --verify gnupg-2.2.27.tar.bz2.sig gnupg-2.2.27.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.27.tar.bz2, you run the command like this: sha1sum gnupg-2.2.27.tar.bz2 and check that the output matches the next line: d928d4bd0808ffb8fe20d1161501401d5d389458 gnupg-2.2.27.tar.bz2 53aaa951be77b9f59fe0981291962be3e5a21314 gnupg-w32-2.2.27_20210111.tar.xz 9f2ff2ce36b6537f895ab3306527f105ff95df8d gnupg-w32-2.2.27_20210111.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, 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/T5234 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. 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 ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and still mostly financed by donations. Three full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, or 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 and secure shape and to address all the small and larger requests made by our users. Thanks. Happy hacking in 2021, 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: ed25519 2020-08-24 [expires: 2030-06-30] Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) 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) rsa2048 2011-01-12 [expires: 2021-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- "If privacy is outlawed, only outlaws will have privacy." - PRZ 1991 -------------- 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 Mon Jan 11 21:10:01 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Jan 2021 21:10:01 +0100 Subject: Reiner-SCT CyberJack secoder 2 (v2.2.0 USB 0c4b:0400) In-Reply-To: <0b5443d8-96c2-f19a-bec9-d91bdf60441b@pocock.pro> (Daniel Pocock's message of "Mon, 11 Jan 2021 09:36:01 +0100") References: <0b5443d8-96c2-f19a-bec9-d91bdf60441b@pocock.pro> Message-ID: <87y2gzi6au.fsf@wheatstone.g10code.de> On Mon, 11 Jan 2021 09:36, Daniel Pocock said: > Reiner SCT cyberJack secoder 2 Recycle the hardware for other purposes - it is too hard to make this crap work. Reiner is notorious for not releasing specs and basing their stuff on proprietary extensions. Think Nvidea for card readers. 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 angel at pgp.16bits.net Mon Jan 11 22:59:10 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Mon, 11 Jan 2021 22:59:10 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> Message-ID: On 2021-01-11 at 16:36 +0100, Stefan Claas wrote: > On Sun, Jan 10, 2021 at 11:22 PM ?ngel wrote: > > On 2021-01-10 at 18:47 +0100, Stefan Claas wrote: > > > Can you tell me/us in laymen terms how this works with gnupg.org? > > > > Sure. Let's suppose you wanted to fetch Werner's key. You want the > > key > > for wk at gnupg.org Using --with-wkd-hash parameter, we can see that > > this > > would generate nq6t9teux7edsnwdksswydu4o9i5es3f at gnupg.org > > > > Then, the key of Werner lives at > > https://openpgpkey.gnupg.org/.well-known/openpgpkey/gnupg.org/hu/nq6t9teux7edsnwdksswydu4o9i5es3f > > > > If openpgpkey.gnupg.org didn't exist, then it would use the direct > > schema, in which the key would be at > > https://gnupg.org/.well-known/openpgpkey/hu/nq6t9teux7edsnwdksswydu4o9i5es3f > > Thanks, so I think the culprit could be that maybe the specs were > changed, when I > look at your links, including the gnupg.org domain as a folder, which > I never set-up > when doing this for my 300baud.de domain. I checked also older WKD > tutorials > on the Internet and they do not mention a domain folder either. > > I tried to include this domain folder, this morning, named sac001 but > it did not work either, whether with GnuPG or sequioa-pgp. > > So my guess is that GnuPG gives this cert error because it does not > support > wildcard subdomains, included in an SSL cert, like the GitHub one. The folder with the domain name is only used in the advanced method. Compare how the url using openpgpkey.gnupg.org above has a gnupg.org folder but the url of gnupg.org doesn't. In your case, you would place your key at https://openpgpkey.300baud.de/.well-known/openpgpkey/300baud.de/hu/ywwzopgqx5kmisb8r18gq68h13jwdg33 or -if openpgpkey.300baud.de doesn't exist- at https://300baud.de/.well-known/openpgpkey/hu/ywwzopgqx5kmisb8r18gq68h13jwdg33 note that in both cases, you still need a file named policy in the same folder that contains hu/ (just create an empty file, but it must be there) The advanced method was added in November 2018, 2.5 years ago, in version 7 of the draft: https://www.ietf.org/rfcdiff?url1=draft-koch-openpgp-webkey-service-06&url2=draft-koch-openpgp-webkey-service-07&difftype=--html It's true that draft-koch-openpgp-webkey-service doesn't specify that the https certificate must be valid. One would generally expect that https:// with no, normal rules would apply, although there is a history of ignoring certificate validation if keys are going to be validated through WoT. The "make a CNAME of your openpgpkeys subdomain to wkd.keys.openpgp.org" couldn't work with https certificate validation, thouth (or are they requesting a certificate on-the-fly?) Actually, I suspect that depending on how you build gnupg, it would validate them or not. Best regards From gniibe at fsij.org Tue Jan 12 00:52:53 2021 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 12 Jan 2021 08:52:53 +0900 Subject: Reiner-SCT CyberJack secoder 2 (v2.2.0 USB 0c4b:0400) In-Reply-To: <0b5443d8-96c2-f19a-bec9-d91bdf60441b@pocock.pro> References: <0b5443d8-96c2-f19a-bec9-d91bdf60441b@pocock.pro> Message-ID: <878s8zqbe2.fsf@iwagami.gniibe.org> Daniel Pocock writes: > Reiner SCT cyberJack secoder 2 > v2.2.0 > USB: 0c4b:0400 It's good to check the list of CCID readers by libccid: https://salsa.debian.org/rousseau/CCID/-/tree/master/readers Since I cannot find the device in this list, I'm afraid it would not work well. For some testing (try and error), you can use pyscard: https://pyscard.sourceforge.io/ Unfortunately, IMHO, smartcard access is not designed well to allow us using (proprietary or undocumented) card reader easily. I'd recommend to find a CCID card reader with TPDU exchange support (lower level direct control of smartcard). -- From spam.trap.mailing.lists at gmail.com Tue Jan 12 09:25:15 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 12 Jan 2021 09:25:15 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> Message-ID: On Mon, Jan 11, 2021 at 11:03 PM ?ngel wrote: > > On 2021-01-11 at 16:36 +0100, Stefan Claas wrote: > > On Sun, Jan 10, 2021 at 11:22 PM ?ngel wrote: > > > On 2021-01-10 at 18:47 +0100, Stefan Claas wrote: > > > > Can you tell me/us in laymen terms how this works with gnupg.org? > > > > > > Sure. Let's suppose you wanted to fetch Werner's key. You want the > > > key > > > for wk at gnupg.org Using --with-wkd-hash parameter, we can see that > > > this > > > would generate nq6t9teux7edsnwdksswydu4o9i5es3f at gnupg.org > > > > > > Then, the key of Werner lives at > > > https://openpgpkey.gnupg.org/.well-known/openpgpkey/gnupg.org/hu/nq6t9teux7edsnwdksswydu4o9i5es3f > > > > > > If openpgpkey.gnupg.org didn't exist, then it would use the direct > > > schema, in which the key would be at > > > https://gnupg.org/.well-known/openpgpkey/hu/nq6t9teux7edsnwdksswydu4o9i5es3f > > > > Thanks, so I think the culprit could be that maybe the specs were > > changed, when I > > look at your links, including the gnupg.org domain as a folder, which > > I never set-up > > when doing this for my 300baud.de domain. I checked also older WKD > > tutorials > > on the Internet and they do not mention a domain folder either. > > > > I tried to include this domain folder, this morning, named sac001 but > > it did not work either, whether with GnuPG or sequioa-pgp. > > > > So my guess is that GnuPG gives this cert error because it does not > > support > > wildcard subdomains, included in an SSL cert, like the GitHub one. > > > The folder with the domain name is only used in the advanced method. > Compare how the url using openpgpkey.gnupg.org above has a gnupg.org > folder but the url of gnupg.org doesn't. Yes, I have checked that. Noteworthy IMHO, regarding wildcard subdomains, gnupg.org does not have such entry in the DNS section, of the cert. > In your case, you would place your key at > > https://openpgpkey.300baud.de/.well-known/openpgpkey/300baud.de/hu/ywwzopgqx5kmisb8r18gq68h13jwdg33 > > or -if openpgpkey.300baud.de doesn't exist- at > > https://300baud.de/.well-known/openpgpkey/hu/ywwzopgqx5kmisb8r18gq68h13jwdg33 > > note that in both cases, you still need a file named policy in the same > folder that contains hu/ (just create an empty file, but it must be > there) When I had that in the past, for 300baud.de I had that included, it was an emtpy one. > The advanced method was added in November 2018, 2.5 years ago, in > version 7 of the draft: > https://www.ietf.org/rfcdiff?url1=draft-koch-openpgp-webkey-service-06&url2=draft-koch-openpgp-webkey-service-07&difftype=--html It would be nice to know why the advanced method was added. In case the direct method would not be sufficent or would have security issues I would think that than one replaces the direct method with advanced one and then we only need only one method, in order that this works. And if we must have two methods, why is the order not, like one would think: check direct first and if this does not work check advanced? I must admit I do not understand the programming logic. > It's true that draft-koch-openpgp-webkey-service doesn't specify that > the https certificate must be valid. One would generally expect that > https:// with no, normal rules would apply, although there is a history > of ignoring certificate validation if keys are going to be validated > through WoT. The "make a CNAME of your openpgpkeys subdomain to > wkd.keys.openpgp.org" couldn't work with https certificate validation, > thouth (or are they requesting a certificate on-the-fly?) > Actually, I suspect that depending on how you build gnupg, it would > validate them or not. It should be noted that my findings and proposal for wildcard subdomains would allow organizations and individuals to reduce costs, when using purchased SSL certs, instead of Let's Encrypt ones. Not only this but if this would work, like I mentioned in my bund.de example, organizations would have the freedom to choose WKD instead of hockeypuck or Hagrid, and they would have a compatible *inhouse* solution, via simple Web management, instead of running a server software, like hokeypuck or Hagrid. And In my example, with GitHub, I guess it would be fantastic too, to promote WKD GnuPG/sequoia-pgp usage for individuals, low on budged while not extra running an own server and purchasing a domain. Best regards Stefan From andre at colomb.de Tue Jan 12 11:27:57 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Tue, 12 Jan 2021 11:27:57 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> Message-ID: <52f3beb3-6755-0866-26d5-e5142cc11fdd@colomb.de> On 12/01/2021 09.25, Stefan Claas via Gnupg-users wrote: > It would be nice to know why the advanced method was added. In case > the direct method would not be sufficent or would have security issues > I would think that than one replaces the direct method with advanced > one and then we only need only one method, in order that this works. A domain is not automatically tied to a webserver. It might so far only be used for e-mail and just to set up WKD, one might not want to run a webserver under the second-level domain itself. Therefore the standardized "openpgpkey" subdomain, which can easily point to a different IP. That makes it easy to completely separate the infrastructure needed for WKD from anything else, like a webserver for a web page, webmail or other services. In addition, that separate server might serve WKD keys for a bunch of different domains through redirects, hence it makes sense to separate the URLs per domain. It just gives the admin additional flexibility by not forcing them to make a certain URL under the main domain work. > And if we must have two methods, why is the order not, like one would > think: check direct first and if this does not work check advanced? > I must admit I do not understand the programming logic. That's easy: If openpgpkey.example.org exists, we can be certain that example.org exists as well. So the check for the openpgpkey subdomain must come first if its mere existence decides which method is tried. Otherwise you would get HTTPS connections for every WKD request on the example.org server, which fail if the direct method is not supported. Just to make another HTTPS connection to openpgpkey.example.org to try the advanced method next. That's a lot of overhead on both the client and server side, compared to the two DNS queries you need to make either way. Hope that helps. Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dgouttegattat at incenp.org Tue Jan 12 10:25:43 2021 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 12 Jan 2021 09:25:43 +0000 Subject: WKD for GitHub pages In-Reply-To: References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> Message-ID: <20210112092543.2b7sa63x2uvbcgsr@dynein.local.incenp.org> On Tue, Jan 12, 2021 at 09:25:15AM +0100, Stefan Claas via Gnupg-users wrote: >It would be nice to know why the advanced method was added. To give more flexibility for people setting up a WKD for more than one domain. Let?s say that I manage example.org and example.net, and I want to serve keys for addresses in both domains. With the ?direct? method, I need to set up two distinct WKD servers, one for each domain. With the ?advanced? method, I can set up a single server and make openpgpkey.example.org and openpgpkey.example.net point to that single server. (SRV records would be the modern and proper way to provide such a level of indirection, instead of a subdomain. And indeed, previous versions of the WKD draft relied on SRV records. Unfortunately, resolving SRV records was problematic for some implementers using some limited languages with limited DNS capabilities, so they were scrapped in favor of the subdomain approach.) >the direct method would not be sufficent or would have security issues >I would think that than one replaces the direct method with advanced >one and then we only need only one method, in order that this works. If you have only one domain to manage and don?t need the indirection provided by the advanced method, the direct method is still perfectly fine, why replace it? >And if we must have two methods, why is the order not, like one would >think: check direct first and if this does not work check advanced? I don?t know, it feels more logical to me to look for an indirection *first*, and only if there?s no indirection you then look at the target domain itself. - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From andrewg at andrewg.com Tue Jan 12 11:47:07 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 12 Jan 2021 10:47:07 +0000 Subject: WKD for GitHub pages In-Reply-To: References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> Message-ID: <3e20eab8-a4d0-7b5d-e441-716825c1ca7e@andrewg.com> On 12/01/2021 08:25, Stefan Claas via Gnupg-users wrote: > if this would work, like I mentioned in my bund.de example, organizations > would have the freedom to choose WKD instead of hockeypuck or Hagrid, > and they would have a compatible*inhouse* solution, via simple > Web management, instead of running a server software, like hokeypuck > or Hagrid. WKD is used to publish your own keys, or keys belonging to users in your own domain. A keyserver is for publishing arbitrary other people's keys. It has never been necessary for a business to run its own keyserver in order to use PGP. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Tue Jan 12 12:27:46 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 12 Jan 2021 12:27:46 +0100 Subject: WKD for GitHub pages In-Reply-To: <3e20eab8-a4d0-7b5d-e441-716825c1ca7e@andrewg.com> References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> <3e20eab8-a4d0-7b5d-e441-716825c1ca7e@andrewg.com> Message-ID: On Tue, Jan 12, 2021 at 11:49 AM Andrew Gallagher wrote: > > On 12/01/2021 08:25, Stefan Claas via Gnupg-users wrote: > > > if this would work, like I mentioned in my bund.de example, organizations > > would have the freedom to choose WKD instead of hockeypuck or Hagrid, > > and they would have a compatible*inhouse* solution, via simple > > Web management, instead of running a server software, like hokeypuck > > or Hagrid. > > WKD is used to publish your own keys, or keys belonging to users in your > own domain. A keyserver is for publishing arbitrary other people's keys. > It has never been necessary for a business to run its own keyserver in > order to use PGP. Let me say first thank you to Damien and Andre, because I want to make it short and therefore sorry for not replying to your messages. Your are right, but we all know what happened to the SKS Network and we know also that Hagrid is perfectly fine for privacy and once a hockeypuck Network is in operation users will appreciate it too. The point for me is WKD exists and can be used as an cheap inhouse solution, for families or organizations, if it would allow cost effective wildcard subdomain support for SSL certs, which IMHO can not hurt and if the direct method would be triggered first. Regards Stefan From andrewg at andrewg.com Tue Jan 12 12:40:56 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 12 Jan 2021 11:40:56 +0000 Subject: WKD for GitHub pages In-Reply-To: References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> <3e20eab8-a4d0-7b5d-e441-716825c1ca7e@andrewg.com> Message-ID: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> On 12/01/2021 11:27, Stefan Claas wrote: > The point for me is WKD exists and can be used as an cheap inhouse > solution, for families or organizations, if it would allow cost effective > wildcard subdomain support for SSL certs, which IMHO can not hurt > and if the direct method would be triggered first. Yes, WKD is great. But as Andr? has explained, there is an overhead cost (to everyone) for trying the direct method first, so inverting this to work around the side effects of an experiment that's tied to one particular vendor's service is a *huge* ask. -- Andrew Gallagher From spam.trap.mailing.lists at gmail.com Tue Jan 12 12:47:59 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 12 Jan 2021 12:47:59 +0100 Subject: WKD for GitHub pages In-Reply-To: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> <3e20eab8-a4d0-7b5d-e441-716825c1ca7e@andrewg.com> <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> Message-ID: On Tue, Jan 12, 2021 at 12:43 PM Andrew Gallagher wrote: > > On 12/01/2021 11:27, Stefan Claas wrote: > > The point for me is WKD exists and can be used as an cheap inhouse > > solution, for families or organizations, if it would allow cost effective > > wildcard subdomain support for SSL certs, which IMHO can not hurt > > and if the direct method would be triggered first. > > Yes, WKD is great. But as Andr? has explained, there is an overhead cost > (to everyone) for trying the direct method first, so inverting this to > work around the side effects of an experiment that's tied to one > particular vendor's service is a *huge* ask. Well, I am not sure about the details for a server or a user when it comes to overhead and if you mean with one particular vendow GitHub, well that may be the beginning, for such request. But like I mentioned if people would wish to manage key distribution themselves, without using third parties, like Hagrid or hokeypuck or even running such software and servers I strongly believe that WKD could be an excellent choice, if this would be fixed. Regards Stefan From spam.trap.mailing.lists at gmail.com Tue Jan 12 13:04:02 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 12 Jan 2021 13:04:02 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> <3e20eab8-a4d0-7b5d-e441-716825c1ca7e@andrewg.com> <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> Message-ID: On Tue, Jan 12, 2021 at 12:47 PM Stefan Claas wrote: > Well, I am not sure about the details for a server or a user when it comes > to overhead and if you mean with one particular vendow GitHub, well > that may be the beginning, for such request. But like I mentioned if people > would wish to manage key distribution themselves, without using third > parties, like Hagrid or hokeypuck or even running such software and > servers I strongly believe that WKD could be an excellent choice, if > this would be fixed. And for the fun factor I could put also an .ots file from my pub key into the hu directory,thus making Mallory a bit angry ... :-D Regards Stefan From spam.trap.mailing.lists at gmail.com Tue Jan 12 14:22:22 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 12 Jan 2021 14:22:22 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> <3e20eab8-a4d0-7b5d-e441-716825c1ca7e@andrewg.com> <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> Message-ID: On Tue, Jan 12, 2021 at 1:04 PM Stefan Claas wrote: > > On Tue, Jan 12, 2021 at 12:47 PM Stefan Claas > wrote: > And for the fun factor I could put also an .ots file from my pub key into > the hu directory,thus making Mallory a bit angry ... :-D Unfortunaly I am no skilled Golang programmer, otherwise I would write a WKD key fetch utility, which works like sequoia-pgp, e.g fechting the binary key blob and displaying the results to stdout and additionally fetching the younamit.ots file and the policy file, while storing those in the current workin directory and where the policy file would contain the fingerprint of my key. Thus an OpenPGP users could use the direct method, like sequoia-pgp does, had my pub key and the policy file and .oth file which he can use with time stamping services. And it would not break WKD specs. Regards Stefan From spam.trap.mailing.lists at gmail.com Tue Jan 12 14:24:44 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 12 Jan 2021 14:24:44 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> <3e20eab8-a4d0-7b5d-e441-716825c1ca7e@andrewg.com> <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> Message-ID: On Tue, Jan 12, 2021 at 2:22 PM Stefan Claas wrote: > > On Tue, Jan 12, 2021 at 1:04 PM Stefan Claas > wrote: > > > > On Tue, Jan 12, 2021 at 12:47 PM Stefan Claas > > wrote: > > > And for the fun factor I could put also an .ots file from my pub key into > > the hu directory,thus making Mallory a bit angry ... :-D > > Unfortunaly I am no skilled Golang programmer, otherwise I would write > a WKD key fetch utility, which works like sequoia-pgp, e.g fechting the > binary key blob and displaying the results to stdout and additionally > fetching the younamit.ots file and the policy file, while storing those > in the current workin directory and where the policy file would contain > the fingerprint of my key. > > Thus an OpenPGP users could use the direct method, like sequoia-pgp > does, had my pub key and the policy file and .oth file which he can use with > time stamping services. > > And it would not break WKD specs. Edit: the policy file would be timestamped, because it can be pasted as ASCII file into timestamping web services and would then fulfill a job, whic I have not yet seen otherwise. Regards Stefan From kloecker at kde.org Tue Jan 12 17:31:21 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 12 Jan 2021 17:31:21 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> Message-ID: <2603351.A2BdGa5DQ2@breq> On Dienstag, 12. Januar 2021 12:47:59 CET Stefan Claas via Gnupg-users wrote: > On Tue, Jan 12, 2021 at 12:43 PM Andrew Gallagher wrote: > > Yes, WKD is great. But as Andr? has explained, there is an overhead cost > > (to everyone) for trying the direct method first, so inverting this to > > work around the side effects of an experiment that's tied to one > > particular vendor's service is a *huge* ask. > > Well, I am not sure about the details for a server or a user when it comes > to overhead and if you mean with one particular vendow GitHub, well > that may be the beginning, for such request. But like I mentioned if people > would wish to manage key distribution themselves, without using third > parties, like Hagrid or hokeypuck or even running such software and > servers I strongly believe that WKD could be an excellent choice, if > this would be fixed. Why do you think anything needs to be changed in gpg? The problem isn't the implementation of WKD in gpg. The problem is that GitHub serves sub-sub- subdomains like openpgpkey.sac001.github.io with an invalid TLS certificate. It's not only gpg that complains. === $ curl https://openpgpkey.sac001.github.io curl: (60) SSL: no alternative certificate subject name matches target host name 'openpgpkey.sac001.github.io' More details here: https://curl.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. === It's easy for people to manage key distribution themselves with WKD. All they have to do is setup WKD with or without openpgpkey subdomain with valid (!!!) TLS certificates. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From spam.trap.mailing.lists at gmail.com Tue Jan 12 18:05:49 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 12 Jan 2021 18:05:49 +0100 Subject: WKD for GitHub pages In-Reply-To: <2603351.A2BdGa5DQ2@breq> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> Message-ID: On Tue, Jan 12, 2021 at 5:36 PM Ingo Kl?cker wrote: > > On Dienstag, 12. Januar 2021 12:47:59 CET Stefan Claas via Gnupg-users wrote: > > On Tue, Jan 12, 2021 at 12:43 PM Andrew Gallagher > wrote: > > > Yes, WKD is great. But as Andr? has explained, there is an overhead cost > > > (to everyone) for trying the direct method first, so inverting this to > > > work around the side effects of an experiment that's tied to one > > > particular vendor's service is a *huge* ask. > > > > Well, I am not sure about the details for a server or a user when it comes > > to overhead and if you mean with one particular vendow GitHub, well > > that may be the beginning, for such request. But like I mentioned if people > > would wish to manage key distribution themselves, without using third > > parties, like Hagrid or hokeypuck or even running such software and > > servers I strongly believe that WKD could be an excellent choice, if > > this would be fixed. > > Why do you think anything needs to be changed in gpg? The problem isn't the > implementation of WKD in gpg. The problem is that GitHub serves sub-sub- > subdomains like openpgpkey.sac001.github.io with an invalid TLS certificate. > > It's not only gpg that complains. > > === > $ curl https://openpgpkey.sac001.github.io > curl: (60) SSL: no alternative certificate subject name matches target host > name 'openpgpkey.sac001.github.io' > More details here: https://curl.se/docs/sslcerts.html > > curl failed to verify the legitimacy of the server and therefore could not > establish a secure connection to it. To learn more about this situation and > how to fix it, please visit the web page mentioned above. > === > > It's easy for people to manage key distribution themselves with WKD. All they > have to do is setup WKD with or without openpgpkey subdomain with valid (!!!) > TLS certificates. Hello Ingo, please ... openpgpkey is *not* a part of a real (sub)domain, which a user of any domain service has to define in a record. Please accept also that a modern OpenPGP software like sequoia-pgp can handle this *adequately* with the direct method first! Additionally I have received from GitHub a very nice reply, which I and I guess all will accept here! Quote: "... however I don't believe GitHub is in a position to try and persuade a software author to change or fix their software." So the last thing besides here discussing the issue with the community is to file a bug report at: https://dev.gnupg.org/ At least the global OpenPGP community is now aware of my proposal and I repeat here once again: GitHub (which I am not affiliated with in any form) has a *proper* SSL cert and github.io pages are properly working subdomain sites, wiich GnuPG's and gpg4win's WKD implementation can not handle, while modern OpenPGP implementations like sequoia-pgp can handle this. BTW. I am also not affiliated in any form with sequoia or the pep foundation etc. Best regards Stefan From andre at colomb.de Tue Jan 12 20:13:42 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Tue, 12 Jan 2021 20:13:42 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> Message-ID: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> Hi Stefan, maybe I'm not the only one here who doesn't fully follow what your "proposal" actually is. For me, it sounds like you are misunderstanding some things and therefore think you are making a superior proposal where it is actually based on wrong assumptions. On 12/01/2021 18.05, Stefan Claas via Gnupg-users wrote: > please ... openpgpkey is *not* a part of a real (sub)domain, which a > user of any domain service has to define in a record. I do not understand this statement at all. Could you please elaborate? > Please accept also that a modern OpenPGP software like sequoia-pgp > can handle this *adequately* with the direct method first! It seems adequate for *you*, but as I explained it would put a burden on both the client and the involved webservers to handle it that way. In case the advanced method is available, and the direct method is not, testing for the direct method first is not a cheap operation. It has also been pointed out repeatedly in this thread that Sequoia apparently does not properly check the TLS certificate, which you have proven with your example setup. That could be called "modern" or "insecure". It has nothing to do with the ordering of the two methods. > Additionally I have received from GitHub a very nice reply, which I and > I guess all will accept here! > > Quote: "... however I don't believe GitHub is in a position to try and persuade > a software author to change or fix their software." I agree they shouldn't try that. Your question to them probably hinted at something being the problem which is not in their control. While actually the real problem is something else which they could control on their side (see below). > At least the global OpenPGP community is now aware of my proposal > and I repeat here once again: GitHub (which I am not affiliated with in > any form) has a *proper* SSL cert and github.io pages are properly > working subdomain sites, wiich GnuPG's and gpg4win's WKD implementation This is plain wrong, as Ingo has pointed out. But let me explain to you why I think so. The certificate is issued for *.github.io. So it is valid for anything like example.github.io, openpgpkey.github.io, whatever.github.io. But it is NOT VALID for any deeper level of subdomain, like foo.bar.github.io or openpgpkey.example.github.io. That's just how TLS certificate validity is defined. However, GitHub apparently still presents that certificate when making an HTTPS connection to the deeper subdomains, e.g. openpgpkey.example.github.io. For this connection, the certificate is definitely NOT VALID, as curl or gnupg do point out. Sequoia seems to apply different rules for the hostname check, so it seems to "just work" for you. In fact, it should only accept a certificate for openpgpkey.example.github.io or *.example.github.io. So there are two "bugs" involved here. 1. GitHub presenting an invalid certificate for the sub-subdomain and 2. Sequoia not noticing that. Neither of these are bugs in GnuPG. If you can accept these facts, then it makes sense to further discuss what could be changed where to make your desired setup work. Maybe that discussion will lead to a concise change proposal. One more question: You're talking about OpenPGP key discovery setups for families and small groups, IIUC. And that should involve WKD and GitHub. But how should these people actually get working e-mail addresses @example.github.io? WKD very specifically ties the key discovery to the control over the involved domain. It moves part of the trust relationship to the domain administrator. So who is actually in control over those e-mail addresses? I hope this mail will not upset you. Just trying to clarify what you might have misunderstood that leads to people not understanding or agreeing with your proposal. I don't mind to be proven wrong if it was in fact my misunderstanding. Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Tue Jan 12 20:40:24 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 12 Jan 2021 20:40:24 +0100 Subject: WKD for GitHub pages In-Reply-To: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> Message-ID: On Tue, Jan 12, 2021 at 8:17 PM Andr? Colomb wrote: > > Hi Stefan, > So there are two "bugs" involved here. 1. GitHub presenting an invalid > certificate for the sub-subdomain and 2. Sequoia not noticing that. > Neither of these are bugs in GnuPG. If you can accept these facts, then > it makes sense to further discuss what could be changed where to make > your desired setup work. Maybe that discussion will lead to a concise > change proposal. Hi Andre, currently I can only accept the fact that these two "bugs" are currently not resolved in GnuPG and gpg4win, if you allow me to formulate it this way. I desperately hope that this thread will lead to a fruitful outcome, for GnuPG and gpg4win users, while I personally could care less, because I just checked yesterday the latest sq version and I am happy that it works. > One more question: You're talking about OpenPGP key discovery setups for > families and small groups, IIUC. And that should involve WKD and > GitHub. But how should these people actually get working e-mail > addresses @example.github.io? WKD very specifically ties the key > discovery to the control over the involved domain. It moves part of the > trust relationship to the domain administrator. So who is actually in > control over those e-mail addresses? Good question Andre! In case of github.io there is apprently no email address, which is IMHO a good thing if people like to set-up a github.io page and do not want to reveal their real email address, to third parties, which is IMHO their good right, in case they like to use this github.io pub key as multi-purpose key, let's say for multiple email accounts, from other services, file transfer, NFC postcards, you name it. Let's say as an example for gnupg.org. If am not mistaken dev.gnupg.org has a different cert as gnupg.org. Let's assume also that gnupg.org would come up with the idea of running keys.gnupg.org. I strongly believe that a (purchased) SSL cert for gnupg.org, covering wildcard subdomains, like GitHub's cert is neither wrong nor does it cause any security implications, when the direct method is used. Speaking of overhead, I must admit (again) I do not understand what this is or what this can cause for a server maintainer or a GnuPG or gpg4win user, when I for example can fetch my pub key with sequoia real quick, because in binary form these are only a couple of bytes and I strongly believe that a simple directory structure, holding some files, on a web server has no issues either. > I hope this mail will not upset you. Just trying to clarify what you > might have misunderstood that leads to people not understanding or > agreeing with your proposal. I don't mind to be proven wrong if it was > in fact my misunderstanding. Of course not and I appreciate if this issue can be discussed further! Best regards Stefan From andrewg at andrewg.com Tue Jan 12 21:39:47 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 12 Jan 2021 20:39:47 +0000 Subject: WKD for GitHub pages In-Reply-To: References: Message-ID: <10DAA976-E394-438A-B1D2-5C43570B1B37@andrewg.com> > On 12 Jan 2021, at 19:44, Stefan Claas via Gnupg-users wrote: > > Hi Andre, currently I can only accept the fact that these two "bugs" are > currently not resolved in GnuPG and gpg4win, if you allow me to > formulate it this way. You should not formulate it this way. If the bugs are not in gnupg, they cannot be resolved in gnupg. A From spam.trap.mailing.lists at gmail.com Tue Jan 12 21:43:36 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 12 Jan 2021 21:43:36 +0100 Subject: WKD for GitHub pages In-Reply-To: <10DAA976-E394-438A-B1D2-5C43570B1B37@andrewg.com> References: <10DAA976-E394-438A-B1D2-5C43570B1B37@andrewg.com> Message-ID: On Tue, Jan 12, 2021 at 9:43 PM Andrew Gallagher wrote: > > > > On 12 Jan 2021, at 19:44, Stefan Claas via Gnupg-users wrote: > > > > Hi Andre, currently I can only accept the fact that these two "bugs" are > > currently not resolved in GnuPG and gpg4win, if you allow me to > > formulate it this way. > > You should not formulate it this way. If the bugs are not in gnupg, they cannot be resolved in gnupg. Ok, than I should formulate it as feature request, for GnuPG and gpg4win. Regards Stefan From daniele at grinta.net Tue Jan 12 21:28:54 2021 From: daniele at grinta.net (Daniele Nicolodi) Date: Tue, 12 Jan 2021 21:28:54 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> Message-ID: <13fff7bc-1ba8-2229-88fc-e286bb5fe735@grinta.net> On 12/01/2021 20:40, Stefan Claas via Gnupg-users wrote: > On Tue, Jan 12, 2021 at 8:17 PM Andr? Colomb wrote: >> >> Hi Stefan, > >> So there are two "bugs" involved here. 1. GitHub presenting an invalid >> certificate for the sub-subdomain and 2. Sequoia not noticing that. >> Neither of these are bugs in GnuPG. If you can accept these facts, then >> it makes sense to further discuss what could be changed where to make >> your desired setup work. Maybe that discussion will lead to a concise >> change proposal. > > Hi Andre, currently I can only accept the fact that these two "bugs" are > currently not resolved in GnuPG and gpg4win, if you allow me to > formulate it this way. How can GPG solve bugs that are not in the GPG code or infrastructure? I think Andr? did a great job explaining what the issues are. How do you think they can be addressed by GPG? Cheers, Dan From spam.trap.mailing.lists at gmail.com Tue Jan 12 22:17:13 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 12 Jan 2021 22:17:13 +0100 Subject: WKD for GitHub pages In-Reply-To: <13fff7bc-1ba8-2229-88fc-e286bb5fe735@grinta.net> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <13fff7bc-1ba8-2229-88fc-e286bb5fe735@grinta.net> Message-ID: On Tue, Jan 12, 2021 at 10:09 PM Daniele Nicolodi wrote: > > On 12/01/2021 20:40, Stefan Claas via Gnupg-users wrote: > > On Tue, Jan 12, 2021 at 8:17 PM Andr? Colomb wrote: > >> > >> Hi Stefan, > > > >> So there are two "bugs" involved here. 1. GitHub presenting an invalid > >> certificate for the sub-subdomain and 2. Sequoia not noticing that. > >> Neither of these are bugs in GnuPG. If you can accept these facts, then > >> it makes sense to further discuss what could be changed where to make > >> your desired setup work. Maybe that discussion will lead to a concise > >> change proposal. > > > > Hi Andre, currently I can only accept the fact that these two "bugs" are > > currently not resolved in GnuPG and gpg4win, if you allow me to > > formulate it this way. > > How can GPG solve bugs that are not in the GPG code or infrastructure? I > think Andr? did a great job explaining what the issues are. How do you > think they can be addressed by GPG? If you followed the whole thread you may agree that GnuPG and gpg4win, due to the way of how WKD is implemented does not allow wildcard (sub)domains, when fetching a pub key from, for example, github.io pages, because it gives a cert error for a *valid* SSL cert, while other OpenPGP software, like sequoia-pgp, can handle this. I suggest that you or any other persons ask this question Werner, the author of GnuPG and IIRC the wkd-draft author or you ask the sequoia team how they implemented WKD, because sq.exe does it's job. Regards Stefan From daniele at grinta.net Tue Jan 12 21:24:59 2021 From: daniele at grinta.net (Daniele Nicolodi) Date: Tue, 12 Jan 2021 21:24:59 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> Message-ID: On 12/01/2021 20:40, Stefan Claas via Gnupg-users wrote: > On Tue, Jan 12, 2021 at 8:17 PM Andr? Colomb wrote: >> One more question: You're talking about OpenPGP key discovery setups for >> families and small groups, IIUC. And that should involve WKD and >> GitHub. But how should these people actually get working e-mail >> addresses @example.github.io? WKD very specifically ties the key >> discovery to the control over the involved domain. It moves part of the >> trust relationship to the domain administrator. So who is actually in >> control over those e-mail addresses? > > Good question Andre! In case of github.io there is apprently no > email address, which is IMHO a good thing if people like to > set-up a github.io page and do not want to reveal their real > email address, to third parties, which is IMHO their good right, > in case they like to use this github.io pub key as multi-purpose > key, let's say for multiple email accounts, from other services, > file transfer, NFC postcards, you name it. The point of WKD is using the trust of the CA machinery (and the assumption that the email infrastructure and web servers serving a specific domain are run by the same organization) to securely retrieve OpenPGP keys associated to an email address. There keys can then be used to communicate with the older of the email address. The party in the communication are identified by email addresses. In your scheme there are no email addresses. How is retrieving an OpenPGP key from a random .github.io subdomain from obtaining it in any other untrusted way? What is the line of trust in the scheme you are proposing? Cheers, Dan From andre at colomb.de Tue Jan 12 22:54:47 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Tue, 12 Jan 2021 22:54:47 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> Message-ID: <51089d90-b8e8-d5f6-b273-8d20ce84abfb@colomb.de> On 12/01/2021 20.40, Stefan Claas wrote: >> So there are two "bugs" involved here. 1. GitHub presenting an invalid >> certificate for the sub-subdomain and 2. Sequoia not noticing that. >> Neither of these are bugs in GnuPG. If you can accept these facts, then >> it makes sense to further discuss what could be changed where to make >> your desired setup work. Maybe that discussion will lead to a concise >> change proposal. > > Hi Andre, currently I can only accept the fact that these two "bugs" are > currently not resolved in GnuPG and gpg4win, if you allow me to > formulate it this way. I desperately hope that this thread will lead to a I (and others) understand the word "bug" as in "software not working according to its specification". The specification is the WKD Internet Draft as well as some RFCs about TLS certificate rules. Bugs in Sequoia or GitHub's DNS configuration can therefore not be resolved in a different software, namely GnuPG. Not sure what you mean by "resolve" otherwise. Ignoring security rules would be a workaround, and a terrible one as well. Regarding the "misconfiguration" of GitHub's DNS and HTTPS, I noticed Werner has actually added a corresponding paragraph to the WKD draft in May 2019 (version 08): Sites which do not use the advanced method but employ wildcard DNS for their sub-domains MUST make sure that the "openpgpkey" sub-domain is not subject to the wildcarding. This can be done by inserting an empty TXT RR for this sub-domain. Of course that only applies for someone striving for WKD conformance, which the github.io domain has absolutely no business with. Therefore they don't take this extra measure to suppress a failed attempt with the WKD advanced method. > Good question Andre! In case of github.io there is apprently no > email address, which is IMHO a good thing if people like to > set-up a github.io page and do not want to reveal their real > email address, to third parties, which is IMHO their good right, > in case they like to use this github.io pub key as multi-purpose > key, let's say for multiple email accounts, from other services, > file transfer, NFC postcards, you name it. Okay, so you're using a protocol (WKD) that was purpose-designed with e-mail in mind, but your user IDs don't work as e-mail addresses. Despite looking exactly alike. That in itself might confuse people (like me) using those keys. However WKD itself is not strictly tied to e-mail, in contrast to WKS (the related Web Key Service protocol). > Let's say as an example for gnupg.org. If am not mistaken > dev.gnupg.org has a different cert as gnupg.org. Let's assume > also that gnupg.org would come up with the idea of running > keys.gnupg.org. I strongly believe that a (purchased) SSL > cert for gnupg.org, covering wildcard subdomains, like GitHub's > cert is neither wrong nor does it cause any security implications, > when the direct method is used. You need to distinguish at which level the wildcard is found. A TLS certificate for *.gnupg.org would be perfectly fine, and even if dev.gnupg.org uses its own even though it would be covered by the wildcard. A fictional openpgpkey.gnupg.org server could present the wildcard cert, just as GitHub does it. But for an openpgpkey.dev.gnupg.org server, that would be invalid. Again, a certificate for *.dev.gnupg.org could be used there. There's two sides to the validity: DNS and TLS. Going back to the GitHub example for continuity. The DNS server resolves example.github.io to some IP address. It also resolves any sub-subdomain like openpgpkey.example.github.io to a (probably the same) IP address. The web server at that address presents a TLS certificate which is issued for *.github.io. It would need to present a different certificate for *.example.github.io in order to make a valid TLS authenticated connection. I don't think there is something like a *.*.github.io entry they could include in their certificate that would cover all sub- and sub-sub-domains at once. So the HTTPS connection to openpgpkey.example.github.io "works" on the DNS level, but has NO VALID TLS set up, which is the "bug" / error on their side. > Speaking of overhead, I must admit (again) I do not understand > what this is or what this can cause for a server maintainer or > a GnuPG or gpg4win user, when I for example can fetch my > pub key with sequoia real quick, because in binary form these > are only a couple of bytes and I strongly believe that a simple > directory structure, holding some files, on a web server has no > issues either. I'll try to explain what happens during a WKD lookup attempt in your preferred order, in hopefully simple terms (not 100 % technically correct). 1. The client queries DNS for the github.io domain, gets back an NS record (a name server for the github.io zone). 2. Client asks the returned DNS server about example.github.io, gets back an IP address for the (web) server. 3. Client contacts the web server on port 443, initiating a TLS handshake. Gets back a TLS certificate issued for *.github.io. 4. Client checks that the contacted DNS name is actually covered by that certificate. (OK for example.github.io, not for deeper levels) 5. Client sends an HTTP request over the established TLS connection, asking for the well-known URL's path component. The server answers "404 Not found" or similar. 6. Client decides that the simple method failed and goes back to step 2, this time trying the openpgpkey.example.github.io DNS name. Step 5 will succeed this time, returning the OpenPGP certificate and public key. Now you need to know that the "handshake" part consists of several back-and-forth data transfers, which is why surfing over satellite links is awful and stuff like QUIC / HTTP/2 is being developed to try and reduce these round trips. There are also many points where things can go wrong, e.g. the web server simply not answering on port 443 because it is really only an e-mail server and WKD is handled somewhere else (where we get in the second round). That involves the connection needing to time out first. So repeating steps 2 to 5 is what I mean with "overhead", which may very well cause user-noticeable delays. In contrast to that, *first* querying the sub-sub-domain openpgpkey.example.github.io would ideally return NXDOMAIN and we can switch immediately to trying the direct method. Less time and energy wasted. I say ideally, because on github.io specifically, that doesn't happen. Which is fine in itself. But the WKD spec lets us interpret that as "cool, the openpgpkey subdomain resolved, so let's use advanced method!" If it now fails at a later step (TLS certificate validity in this case), sane implementations rightfully report a misconfiguration and abort, because it may just as well be an MITM attacker fooling with the TLS certificate. What could be done in the WKD spec and / or GnuPG is to fall back to the simple method not only when the openpgpkey subdomain is unresolvable, but also if any other error happens during the advanced method. I don't see any obvious *security* implications in that. But providers like GitHub would then go through two complete HTTPS connections before the client notices "WKD just isn't set up properly there". The current WKD draft tries to avoid that duplicated server load by aborting early based on the DNS response. What Sequoia could do is fix their TLS host name check (step 4 above) to only match one level with a wildcard, slightly increasing security. But that is their call and I'm not knowledgeable enough on official TLS validity rules to point a finger. Just GnuPG and curl choking on your example indicates that it might be the Right Thing to do. What GitHub could do (easily) is follow the WKD recommendation and specifically block any "openpgpkey" sub-subdomain from resolving. Just in case someone is crazy enough (no offense Stefan :-) to try abusing their free web page service for WKD. Remember it is *their* domain even if they grant you free usage of a subdomain. And WKD specifically delegates some trust to the *domain owner*, so they have every right to not care about OpenPGP at all and let WKD requests fail ungracefully. Even the right to serve an invalid wildcard certificate for sub-subdomains (which is still bad though). Sorry for the long read, but I hope it clarifies the situation. Regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Tue Jan 12 23:16:25 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 12 Jan 2021 23:16:25 +0100 Subject: WKD for GitHub pages In-Reply-To: <51089d90-b8e8-d5f6-b273-8d20ce84abfb@colomb.de> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <51089d90-b8e8-d5f6-b273-8d20ce84abfb@colomb.de> Message-ID: On Tue, Jan 12, 2021 at 10:58 PM Andr? Colomb wrote: [...] Andre, please appoligze that I snipped your reply and that I only give a short reply, your explanations of server/client IO was welcome. In my OP I only asked for help from the community to set-up WKD for GnuPG or gpg4win usage and I gave also in this thread a couple of thoughts why WKD could be a very useful addition to Hagrid and later hockerpuck. I think I do undertsand the American Way Of Life quite a bit, meaning that U.S. citizens are more open to privacy related things with security software then maybe us old Sauerkrauts, so to speak. Therefore I doubt that an IMHO very cool billion dollar company like GitHub, according to the reply I got from them, would see WKD usage as harm for their service, when used by many people. I could be wrong of course (in the future) Even if there would be no github.io pages available I hope that I showed here something interesting for the GnuPG community. Best regards Stefan From remco at webconquest.com Tue Jan 12 22:36:13 2021 From: remco at webconquest.com (Remco =?utf-8?Q?R=C4=B3nders?=) Date: Tue, 12 Jan 2021 16:36:13 -0500 Subject: WKD for GitHub pages In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <13fff7bc-1ba8-2229-88fc-e286bb5fe735@grinta.net> Message-ID: On Tue, Jan 12, 2021 at 10:17:13PM +0100, Stefan wrote in : >> How can GPG solve bugs that are not in the GPG code or infrastructure? I >> think Andr? did a great job explaining what the issues are. How do you >> think they can be addressed by GPG? > >If you followed the whole thread you may agree that GnuPG and gpg4win, >due to the way of how WKD is implemented does not allow wildcard (sub)domains, >when fetching a pub key from, for example, github.io pages, because it gives >a cert error for a *valid* SSL cert, while other OpenPGP software, >like sequoia-pgp, >can handle this. > >I suggest that you or any other persons ask this question Werner, the author >of GnuPG and IIRC the wkd-draft author or you ask the sequoia >team how they implemented WKD, because sq.exe does it's job. Firefox gives an error on the URL https://openpgpkey.sac001.github.io/ : Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for openpgpkey.sac001.github.io. The certificate is only valid for the following names: www.github.com, *.github.com, github.com, *.github.io, github.io, *.githubusercontent.com, githubusercontent.com I don't see the valid SSL certificate you keep on insisting is there. From spam.trap.mailing.lists at gmail.com Tue Jan 12 23:30:17 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 12 Jan 2021 23:30:17 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> Message-ID: On Tue, Jan 12, 2021 at 11:02 PM Daniele Nicolodi wrote: > The point of WKD is using the trust of the CA machinery (and the > assumption that the email infrastructure and web servers serving a > specific domain are run by the same organization) to securely retrieve > OpenPGP keys associated to an email address. There keys can then be used > to communicate with the older of the email address. > > The party in the communication are identified by email addresses. > > In your scheme there are no email addresses. How is retrieving an > OpenPGP key from a random .github.io subdomain from obtaining it in any > other untrusted way? What is the line of trust in the scheme you are > proposing? Please let me clarify one thing (and I do not want to play or act like a teacher, uknown to you or others) Before PGP was invented by Mr. Zimmermann, public key cryptography does not needed a Web of Trust, nor a public key which has to bear a name or an email address! I for example use besides OpenPGP software also public key crypto software based on Professor Bernstein's NaCl library, with friends in the United States, Canada and Germany. This public key is a 256bit key with not a single content of MetaData and communicating with my friends is authenticated. Public Key Cryptography does not mean, even If I place my publicty available key on a site, that the whole world needs to know with whom I communicate and from which channels. It is IMHO a misunderstanding people make, new to public key cryptography, while only knowing popular OpenPGP software. sequoia-pgp, in that respect, honors this old principle and allows for exampla also users to create a key pair which does not need a UID ant therefore can act, same as NaClbox the classic way of public key cryptography. The reason why I like also the option for, let's say github.io pages is that, like I have shown in the whole thread that a very well known site like GitHub, with it's millions of software developes allows one to host, via WKD, a mutli-purpose usage public-key without revealing to much details. Regards Stefan From spam.trap.mailing.lists at gmail.com Tue Jan 12 23:33:34 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 12 Jan 2021 23:33:34 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <13fff7bc-1ba8-2229-88fc-e286bb5fe735@grinta.net> Message-ID: On Tue, Jan 12, 2021 at 11:32 PM Remco R?nders wrote: > > On Tue, Jan 12, 2021 at 10:17:13PM +0100, Stefan wrote in > : > >> How can GPG solve bugs that are not in the GPG code or infrastructure? I > >> think Andr? did a great job explaining what the issues are. How do you > >> think they can be addressed by GPG? > > > >If you followed the whole thread you may agree that GnuPG and gpg4win, > >due to the way of how WKD is implemented does not allow wildcard (sub)domains, > >when fetching a pub key from, for example, github.io pages, because it gives > >a cert error for a *valid* SSL cert, while other OpenPGP software, > >like sequoia-pgp, > >can handle this. > > > >I suggest that you or any other persons ask this question Werner, the author > >of GnuPG and IIRC the wkd-draft author or you ask the sequoia > >team how they implemented WKD, because sq.exe does it's job. > > Firefox gives an error on the URL https://openpgpkey.sac001.github.io/ : > > Websites prove their identity via certificates. Firefox does not trust this site > because it uses a certificate that is not valid for openpgpkey.sac001.github.io. > The certificate is only valid for the following names: www.github.com, > *.github.com, github.com, *.github.io, github.io, *.githubusercontent.com, > githubusercontent.com > > I don't see the valid SSL certificate you keep on insisting is there. Hi, I suggest that you visit my https://sac001.github.io page and see what it is all about. (BTW. I am also not affilated in any form with Brave ...) Regards Stefan From andre at colomb.de Tue Jan 12 23:43:16 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Tue, 12 Jan 2021 23:43:16 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <51089d90-b8e8-d5f6-b273-8d20ce84abfb@colomb.de> Message-ID: <31fcefb7-f6c7-46e9-e749-2066c551ea83@colomb.de> Hi Stefan, On 12/01/2021 23.16, Stefan Claas wrote: > Andre, please appoligze that I snipped your reply and that I only > give a short reply, your explanations of server/client IO was > welcome. I'm happy if it helps keeping this discussion constructive and not turning into a flame war :-) > I think I do undertsand the American Way Of Life quite a bit, > meaning that U.S. citizens are more open to privacy related > things with security software then maybe us old Sauerkrauts, > so to speak. Therefore I doubt that an IMHO very cool billion > dollar company like GitHub, according to the reply I got > from them, would see WKD usage as harm for their service, > when used by many people. I could be wrong of course (in > the future) (Me too Sauerkraut...) But you're missing the point. GitHub has no business whatsoever with e-mail. WKD is all about e-mail and you are probably among the first to use it for something unrelated to e-mail. So they don't give a Koffer about some e-mail-related protocol except for maybe implementing it (hopefully sometime) for their own employees / @github.com e-mail account users. > Even if there would be no github.io pages available I hope > that I showed here something interesting for the GnuPG > community. Interesting yes, to the community, yes. But not to the billion dollar company whose offer has nothing to do with e-mail. Not interesting in the sense of "we will invest time and money and risk breaking other users' setups by changing something in our infrastructure" because of some creative WKD use case. By the way, there might be other free web hosting providers you could use to serve a couple of bytes via HTTPS. It's very likely that they do not have the same issues with wildcard domains and invalid TLS certificates as github.io. Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Tue Jan 12 23:47:16 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 12 Jan 2021 23:47:16 +0100 Subject: WKD for GitHub pages In-Reply-To: <31fcefb7-f6c7-46e9-e749-2066c551ea83@colomb.de> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <51089d90-b8e8-d5f6-b273-8d20ce84abfb@colomb.de> <31fcefb7-f6c7-46e9-e749-2066c551ea83@colomb.de> Message-ID: On Tue, Jan 12, 2021 at 11:46 PM Andr? Colomb wrote: > > Hi Stefan, > > On 12/01/2021 23.16, Stefan Claas wrote: > > Andre, please appoligze that I snipped your reply and that I only > > give a short reply, your explanations of server/client IO was > > welcome. > > I'm happy if it helps keeping this discussion constructive and not > turning into a flame war :-) > > > I think I do undertsand the American Way Of Life quite a bit, > > meaning that U.S. citizens are more open to privacy related > > things with security software then maybe us old Sauerkrauts, > > so to speak. Therefore I doubt that an IMHO very cool billion > > dollar company like GitHub, according to the reply I got > > from them, would see WKD usage as harm for their service, > > when used by many people. I could be wrong of course (in > > the future) > > (Me too Sauerkraut...) But you're missing the point. GitHub has no > business whatsoever with e-mail. WKD is all about e-mail and you are > probably among the first to use it for something unrelated to e-mail. > So they don't give a Koffer about some e-mail-related protocol except > for maybe implementing it (hopefully sometime) for their own employees / > @github.com e-mail account users. It does not need to have an email business. > > Even if there would be no github.io pages available I hope > > that I showed here something interesting for the GnuPG > > community. > > Interesting yes, to the community, yes. But not to the billion dollar > company whose offer has nothing to do with e-mail. Not interesting in > the sense of "we will invest time and money and risk breaking other > users' setups by changing something in our infrastructure" because of > some creative WKD use case. > > By the way, there might be other free web hosting providers you could > use to serve a couple of bytes via HTTPS. It's very likely that they do > not have the same issues with wildcard domains and invalid TLS > certificates as github.io. Mmmh ... github.io or GitHub does *not* have issues with wildcard domains ... Regards Stefan From andre at colomb.de Tue Jan 12 23:51:47 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Tue, 12 Jan 2021 23:51:47 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <13fff7bc-1ba8-2229-88fc-e286bb5fe735@grinta.net> Message-ID: On 12/01/2021 23.33, Stefan Claas via Gnupg-users wrote: > On Tue, Jan 12, 2021 at 11:32 PM Remco R?nders wrote: >> I don't see the valid SSL certificate you keep on insisting is there. I totally agree with that. It's valid for the sac001 subdomain, but INVALID for anything below that, which GitHub still happily (and wrongfully) uses it for when asked though. > Hi, I suggest that you visit my https://sac001.github.io page and see what > it is all about. (BTW. I am also not affilated in any form with Brave ...) Sorry, that didn't enlighten me at all. So what is it all about? What does it have to do with timestamping? On a side note: Your sac001 account carries your full name, same as used on this mailing list. You are probably the only one using WKD in this context on github.io. So whatever new account you create, people could very soon find out who is behind that scheme :-) So, only anonymous in theory. Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From andre at colomb.de Tue Jan 12 23:57:54 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Tue, 12 Jan 2021 23:57:54 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <51089d90-b8e8-d5f6-b273-8d20ce84abfb@colomb.de> <31fcefb7-f6c7-46e9-e749-2066c551ea83@colomb.de> Message-ID: <7008969d-ee62-e899-aef1-477a0dd78c49@colomb.de> On 12/01/2021 23.47, Stefan Claas wrote: > Mmmh ... github.io or GitHub does *not* have issues with wildcard > domains ... Here we are back at you denying facts, or maybe just generalizing too much. As several others have put it already: When "browsing" to openpgpkey.sac001.github.io with whatever reasonable HTTPS client, you are directed to an IP address. The web server at that IP address presents a certificate for (among others) *.github.io. This certificate is *invalid* for the originally entered domain name. No matter how many times you deny it. For sac001.github.io, the certificate is *valid*. Nobody ever questioned that. But it doesn't mean the above is untrue. Stay safe. Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Wed Jan 13 00:40:48 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 13 Jan 2021 00:40:48 +0100 Subject: WKD for GitHub pages In-Reply-To: <7008969d-ee62-e899-aef1-477a0dd78c49@colomb.de> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <51089d90-b8e8-d5f6-b273-8d20ce84abfb@colomb.de> <31fcefb7-f6c7-46e9-e749-2066c551ea83@colomb.de> <7008969d-ee62-e899-aef1-477a0dd78c49@colomb.de> Message-ID: On Wed, Jan 13, 2021 at 12:00 AM Andr? Colomb wrote: > > On 12/01/2021 23.47, Stefan Claas wrote: > > Mmmh ... github.io or GitHub does *not* have issues with wildcard > > domains ... > > Here we are back at you denying facts, or maybe just generalizing too > much. As several others have put it already: > > When "browsing" to openpgpkey.sac001.github.io with whatever reasonable > HTTPS client, you are directed to an IP address. The web server at that > IP address presents a certificate for (among others) *.github.io. This > certificate is *invalid* for the originally entered domain name. No > matter how many times you deny it. > > For sac001.github.io, the certificate is *valid*. Nobody ever > questioned that. But it doesn't mean the above is untrue. > > Stay safe. > Andr? Why in the name of (whoever) does one need to browse a URL, with an openpgp part, If my browser does not allow me (AFAIK) to see it's content in that openpgp folder, or why do I/we need that for fetching securely a pub.key, if the direct method works (with sequoia-pgp) and Wiktor's WKD checker gives a green light for direct and IIRC you initally said direct for fetching is fine? Ok, I must say good night know, because I must get up early today. Stay safe too! Regards Stefan From daniele at grinta.net Wed Jan 13 09:24:17 2021 From: daniele at grinta.net (Daniele Nicolodi) Date: Wed, 13 Jan 2021 09:24:17 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <13fff7bc-1ba8-2229-88fc-e286bb5fe735@grinta.net> Message-ID: On 12/01/2021 22:17, Stefan Claas wrote: > On Tue, Jan 12, 2021 at 10:09 PM Daniele Nicolodi wrote: >> >> On 12/01/2021 20:40, Stefan Claas via Gnupg-users wrote: >>> On Tue, Jan 12, 2021 at 8:17 PM Andr? Colomb wrote: >>>> >>>> Hi Stefan, >>> >>>> So there are two "bugs" involved here. 1. GitHub presenting an invalid >>>> certificate for the sub-subdomain and 2. Sequoia not noticing that. >>>> Neither of these are bugs in GnuPG. If you can accept these facts, then >>>> it makes sense to further discuss what could be changed where to make >>>> your desired setup work. Maybe that discussion will lead to a concise >>>> change proposal. >>> >>> Hi Andre, currently I can only accept the fact that these two "bugs" are >>> currently not resolved in GnuPG and gpg4win, if you allow me to >>> formulate it this way. >> >> How can GPG solve bugs that are not in the GPG code or infrastructure? I >> think Andr? did a great job explaining what the issues are. How do you >> think they can be addressed by GPG? > > If you followed the whole thread you may agree that GnuPG and gpg4win, > due to the way of how WKD is implemented does not allow wildcard (sub)domains, > when fetching a pub key from, for example, github.io pages, because it gives > a cert error for a *valid* SSL cert, while other OpenPGP software, > like sequoia-pgp, > can handle this. It has been explained (several times now) that this is not the cases: the certificates are invalid for sub-subdomains. Why are you insisting that they are? Cheers, Dan From daniele at grinta.net Wed Jan 13 09:42:54 2021 From: daniele at grinta.net (Daniele Nicolodi) Date: Wed, 13 Jan 2021 09:42:54 +0100 Subject: WKD for GitHub pages In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> Message-ID: <983b76bf-bef8-19cd-0a7f-b42502243ae8@grinta.net> On 12/01/2021 23:30, Stefan Claas wrote: > The reason why I like also the option for, let's say github.io pages > is that, like I have shown in the whole thread that a very well known > site like GitHub, with it's millions of software developes allows one > to host, via WKD, a mutli-purpose usage public-key without revealing > to much details. I still don't understand why you insist on WKD when it seems to do not support your use case, nor to offer any advantage over a simpler wget -O- https://sac001.github.io/foobar.asc | gpg --import given that the relation between the identifiers "stefan at sac001.github.io" or "https://sac001.github.io/foobar.asc" and the key you are retrieving is the same, ie none. Cheers, Dan From neal at walfield.org Wed Jan 13 10:12:13 2021 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 13 Jan 2021 10:12:13 +0100 Subject: WKD & Sequoia In-Reply-To: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> Message-ID: <874kjlb3pu.wl-neal@walfield.org> Hi Andre, On Tue, 12 Jan 2021 20:13:42 +0100, Andr? Colomb wrote: > It has also been pointed out repeatedly in this thread that Sequoia > apparently does not properly check the TLS certificate, which you have > proven with your example setup. That could be called "modern" or > "insecure". It has nothing to do with the ordering of the two methods. I'd like to clarify what Sequoia is doing (wrong). As per the I-D, sq first tries the advanced method. If that fails for any reason, it falls back to the direct method. You can see the three relevant lines of code here: https://gitlab.com/sequoia-pgp/sequoia/-/blob/c80d2ab0/net/src/wkd.rs#L288 If I remove the "or_else", which falls back to the direct method, then sq shows the following error when fetching stefan at sac001.github.io: $ sq wkd get stefan at sac001.github.io Error: error trying to connect: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: (Hostname mismatch) Caused by: 0: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: (Hostname mismatch) 1: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: So, the hostname mismatch is correctly identified, and it correctly returns an error. Where sq's behavior diverges from gpg's is that sq then tries the direct method, but gpg does not. The latest WKD I-D says: 3.1. Key Discovery There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. Only if the required sub-domain does not exist, they SHOULD fall back to the direct method. https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-11 (FWIW, this was added to revision 7, which was published in Nov. 2018.) The I-D says "Only if the required sub-domain does not exist, they SHOULD fall back to the direct method." The text doesn't say: "If there is an error, they SHOULD fallback to the direct method unless the required sub-domain does not exist, in which case they MUST NOT fall back to the direct method." So, strictly speaking, I don't think Sequoia is violating the specification. But, I don't want to be overly pedantic. Even if the spec were to prohibit falling back to the direct method when the subdomain exists, what exactly would this prohibition gain us? We thought about this question, but we couldn't figure out a satisfactory answer. The worst attack we could come up with is: an attacker could force a WKD client to use an illegitimate WKD via the direct method instead of a legitimate WKD via the advanced method by: - Taking over foo.com's https, AND - Preventing a WKD client from correctly using the advanced method. But the attacker is NOT able to: - Take over openpgpkey.foo.com's https, OR - Prevent the WKD client from resolving openpgpkey.foo.com. So sure, that's possible, but it seems like WKD shouldn't foo.com's biggest worry in that case. (If we overlooked possible attacks, I'd be happy to hear about them.) On the other hand, implementing this prohibition means that a DNS server can prevent its clients from using WKD by forcing all openpgpkey subdomains to resolve to 127.1. That's hard to notice, because everything else still appears to work. Practically speaking, we helped an organziation deploy WKD, and they had a similar problem to what Stefan is observing: the admins setup the direct method, but it didn't work, because their DNS automatically resolved all unknown subdomains to serve a 404. Unfortunately, they had outsourced management of their DNS and couldn't (or didn't know how) to disable this behavior. IIRC, in the end, they spun up an https server for openpgpkeys.domain. :) Neal From andre at colomb.de Wed Jan 13 11:21:29 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Wed, 13 Jan 2021 11:21:29 +0100 Subject: WKD & Sequoia In-Reply-To: <874kjlb3pu.wl-neal@walfield.org> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> Message-ID: Hi Neal, thanks for chiming in with details about your implementation. It's now clear that the wrong certificate in fact triggers an alarm, which is good. Only the fall-back behavior differs from GnuPG. Since Stefan set up the direct method as well, that leads to his setup actually working with Sequoia. On 13/01/2021 10.12, Neal H. Walfield wrote: > So, the hostname mismatch is correctly identified, and it correctly > returns an error. > > Where sq's behavior diverges from gpg's is that sq then tries the > direct method, but gpg does not. I agree that this is the culprit why the two implementations differ. > The I-D says "Only if the required sub-domain does not exist, they > SHOULD fall back to the direct method." The text doesn't say: "If > there is an error, they SHOULD fallback to the direct method unless > the required sub-domain does not exist, in which case they MUST NOT > fall back to the direct method." So, strictly speaking, I don't think > Sequoia is violating the specification. The way I read it, "SHOULD fall back" means that it can opt not to fall back at all. The sentence begins with "Only if ... does not exist", so the whole SHOULD statement just doesn't apply if the subdomain does exist. Proper behavior when the subdomain exists, but some other error occurs, is undefined in the spec. There is certainly room for improvement / clarification here. > But, I don't want to be overly pedantic. Even if the spec were to > prohibit falling back to the direct method when the subdomain exists, > what exactly would this prohibition gain us? The whole point in my opinion is to give the domain admin control over the WKD resolution process. By blocking the openpgpkey subdomain from resolving, they can avoid needless HTTPS request handling, as I explained in detail before: https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064622.html > (If we overlooked possible attacks, I'd be happy to hear about them.) I don't see any big *security* implications either, but I'm really no expert on that topic. There seems to be good reasons for why the I-D specifies it exactly as it does, namely to give a way to control which server automated WKD requests go to and keeping the load as small as possible. > On the other hand, implementing this prohibition means that a DNS > server can prevent its clients from using WKD by forcing all > openpgpkey subdomains to resolve to 127.1. That's hard to notice, > because everything else still appears to work. One can't really prohibit anyone from *trying* to request a resource over some HTTPS URL, especially not in a protocol specification. But the current WKD draft tries to specify at which point a well-behaved WKD client makes the decision on the "correct" method. > Practically speaking, we helped an organziation deploy WKD, and they > had a similar problem to what Stefan is observing: the admins setup > the direct method, but it didn't work, because their DNS automatically > resolved all unknown subdomains to serve a 404. Unfortunately, they > had outsourced management of their DNS and couldn't (or didn't know > how) to disable this behavior. IIRC, in the end, they spun up an > https server for openpgpkeys.domain. So the core problem, as with Stefan's case, is the lack of control over the domain's DNS settings. Which the WKD mechanism relies upon to delegate trust to the domain operators. I think that is a legitimate concern regarding the current WKD Internet Draft. At least a clarification and maybe some adjustments to the advised fall-back behavior would be in order. Let's see what Werner has to say about it and if there are yet unclear reasons for the currently specified way. Kind regards Andr? -- Greetings... From: Andr? Colomb From spam.trap.mailing.lists at gmail.com Wed Jan 13 17:07:44 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 13 Jan 2021 16:07:44 +0000 Subject: WKD & Sequoia In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> Message-ID: On Wed, Jan 13, 2021 at 10:22 AM Andr? Colomb wrote: > So the core problem, as with Stefan's case, is the lack of control over > the domain's DNS settings. Which the WKD mechanism relies upon to > delegate trust to the domain operators. Hi Andre, I wouldn't formulate it this way. I already mentioned that I am able to set up for my 300baud.de domain a couple of droplets and use as suggested a valid wildcard subdomain cert, like I explained with the bund.de example and I am pretty sure that GnuPG and gpg4win will then fail, same as with GitHub. Regarding Neal's attack example, I also posted here an idea to make it for Mallory harder, to exchange (a) key(s) from a host, serving a WKD directory, which also does not break the specs, by simply adding to the policy file the fingerpint(s) and putting verifiable .ots file(s), in for example, the hu folder. Best regards Stefan From andre at colomb.de Wed Jan 13 17:32:11 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Wed, 13 Jan 2021 17:32:11 +0100 Subject: WKD & Sequoia In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> Message-ID: <8f925793-3fa5-4a36-e1c2-fe340bb74f8a@colomb.de> Hi Stefan, On 13/01/2021 17.07, Stefan Claas wrote: > On Wed, Jan 13, 2021 at 10:22 AM Andr? Colomb wrote: > >> So the core problem, as with Stefan's case, is the lack of control over >> the domain's DNS settings. Which the WKD mechanism relies upon to >> delegate trust to the domain operators. > > Hi Andre, I wouldn't formulate it this way. I already mentioned that I am able > to set up for my 300baud.de domain a couple of droplets and use as suggested > a valid wildcard subdomain cert, like I explained with the bund.de example and > I am pretty sure that GnuPG and gpg4win will then fail, same as with GitHub. Sorry, I have no clue what is configured, what works and what should work regarding WKD on your 300baud.de setup. Can we please stick to one real example, not something made up about bund.de? What are droplets? For which domain did you generate a wildcard certificate? What are the DNS settings on that domain? I could take a look at what responses are returned from the real domain, but need some information at least which OpenPGP user ID should be fetchable over WKD from that domain. If you're even interested in learning about how to set up WKD properly. Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Wed Jan 13 17:56:01 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 13 Jan 2021 16:56:01 +0000 Subject: WKD & Sequoia In-Reply-To: <8f925793-3fa5-4a36-e1c2-fe340bb74f8a@colomb.de> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <8f925793-3fa5-4a36-e1c2-fe340bb74f8a@colomb.de> Message-ID: On Wed, Jan 13, 2021 at 4:36 PM Andr? Colomb wrote: > > Hi Stefan, > > On 13/01/2021 17.07, Stefan Claas wrote: > > On Wed, Jan 13, 2021 at 10:22 AM Andr? Colomb wrote: > > > >> So the core problem, as with Stefan's case, is the lack of control over > >> the domain's DNS settings. Which the WKD mechanism relies upon to > >> delegate trust to the domain operators. > > > > Hi Andre, I wouldn't formulate it this way. I already mentioned that I am able > > to set up for my 300baud.de domain a couple of droplets and use as suggested > > a valid wildcard subdomain cert, like I explained with the bund.de example and > > I am pretty sure that GnuPG and gpg4win will then fail, same as with GitHub. > > Sorry, I have no clue what is configured, what works and what should > work regarding WKD on your 300baud.de setup. Can we please stick to one > real example, not something made up about bund.de? > > What are droplets? For which domain did you generate a wildcard > certificate? What are the DNS settings on that domain? I could take a > look at what responses are returned from the real domain, but need some > information at least which OpenPGP user ID should be fetchable over WKD > from that domain. If you're even interested in learning about how to > set up WKD properly. Digital Ocean calls their VPS servers droplets and If I would set them up as a test rig, I would use three, like '300baud.de', 'foo.300baud.de' and 'bar.300baud.de'. In 300baud.de I would set up the WKD directory and the SSL cert, with an entry for wildcard subdomains which would cover then hosts foo and bar. In the WKD directory I would put then a couple of keys with proper sample email addresses from all three hosts. With this set-up, without noodling around with records settings at my domain service (for ease of use and managing WKD) I stronly assume that this set-up follows the direct method and works with sequoia-pgp properly and should fail currently with GnuPG and gpg4win,same as it fails with GitHub. IIRC the (old) WKD specs did not mention nor did they said that it was required to noodle around witth domain settings, regarding the openpgpkey folder when setting up records for hosts with a domain service provider. Regards Stefan From spam.trap.mailing.lists at gmail.com Wed Jan 13 19:31:23 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 13 Jan 2021 18:31:23 +0000 Subject: WKD for GitHub pages In-Reply-To: <983b76bf-bef8-19cd-0a7f-b42502243ae8@grinta.net> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <983b76bf-bef8-19cd-0a7f-b42502243ae8@grinta.net> Message-ID: On Wed, Jan 13, 2021 at 8:42 AM Daniele Nicolodi wrote: > > On 12/01/2021 23:30, Stefan Claas wrote: > > The reason why I like also the option for, let's say github.io pages > > is that, like I have shown in the whole thread that a very well known > > site like GitHub, with it's millions of software developes allows one > > to host, via WKD, a mutli-purpose usage public-key without revealing > > to much details. > > I still don't understand why you insist on WKD when it seems to do not > support your use case, nor to offer any advantage over a simpler > > wget -O- https://sac001.github.io/foobar.asc | gpg --import > > given that the relation between the identifiers > "stefan at sac001.github.io" or "https://sac001.github.io/foobar.asc" and > the key you are retrieving is the same, ie none. Hi Dan, Good question, WKD is a valid option to retrieve pub keys with OpenPGP apps people use and rely on. I could for example also use curl to retrieve keys from Hagrid or SKS. ;-) Regards Stefan From andre at colomb.de Wed Jan 13 20:25:49 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Wed, 13 Jan 2021 20:25:49 +0100 Subject: WKD & Sequoia In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <8f925793-3fa5-4a36-e1c2-fe340bb74f8a@colomb.de> Message-ID: On 13/01/2021 17.56, Stefan Claas wrote: >> What are droplets? For which domain did you generate a wildcard >> certificate? What are the DNS settings on that domain? I could take a >> look at what responses are returned from the real domain, but need some >> information at least which OpenPGP user ID should be fetchable over WKD >> from that domain. If you're even interested in learning about how to >> set up WKD properly. > > Digital Ocean calls their VPS servers droplets and If I would set them up > as a test rig, I would use three, like '300baud.de', 'foo.300baud.de' > and 'bar.300baud.de'. In 300baud.de I would set up the WKD directory and > the SSL cert, with an entry for wildcard subdomains which would cover then > hosts foo and bar. In the WKD directory I would put then a couple of keys with > proper sample email addresses from all three hosts. That's a lot of "ifs". Right now, 300baud.de has neither A nor AAAA nor CNAME record, so there is no server IP address to contact. Obviously there is also no wildcard record either, as e.g. www.300baud.de does not resolve. It's not clear to me which (sub)domain you would want to use in a fictional OpenPGP key's user ID? > With this set-up, without noodling around with records settings at my domain > service (for ease of use and managing WKD) I stronly assume that this > set-up follows the direct method and works with sequoia-pgp properly and > should fail currently with GnuPG and gpg4win,same as it fails with GitHub. It's actually pretty easy. If the openpgpkey... subdomain resolves (explicit entry or DNS wildcard), then the advanced method is used. Otherwise the simple method. That's the only difference, and it does not depend on whatever your certificate contains. Depending on the chosen method, you need to make sure that there is a web server answering with a *valid* TLS certificate and with the proper expected directory structure. There is no reason at all to "strongly assume" any malfunction or bug in GnuPG and I assure you that it's possible to make either method work. The only difference for Sequoia is that it ignores your expressed intent to use the advanced method if something is misconfigured, and falls back to the simple method. GnuPG does not do that, because it correctly follows the specification word by word. > IIRC the (old) WKD specs did not mention nor did they said that it was required > to noodle around witth domain settings, regarding the openpgpkey folder when > setting up records for hosts with a domain service provider. WKD is still an Internet *Draft*, so it's expected to find corner cases like yours that are not yet 100 % unambiguous. That's what the drafting process and public discussion is intended for. Different interpretations should not be possible, and you found a case where Sequoia and GnuPG really do differ. But it still does *not* say one needs to "noodle around with domain settings". It points you to the right spice to add just in case your domain settings are already a noodle soup. Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Wed Jan 13 20:40:59 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 13 Jan 2021 19:40:59 +0000 Subject: WKD & Sequoia In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <8f925793-3fa5-4a36-e1c2-fe340bb74f8a@colomb.de> Message-ID: On Wed, Jan 13, 2021 at 7:26 PM Andr? Colomb wrote: > > On 13/01/2021 17.56, Stefan Claas wrote: > >> What are droplets? For which domain did you generate a wildcard > >> certificate? What are the DNS settings on that domain? I could take a > >> look at what responses are returned from the real domain, but need some > >> information at least which OpenPGP user ID should be fetchable over WKD > >> from that domain. If you're even interested in learning about how to > >> set up WKD properly. > > > > Digital Ocean calls their VPS servers droplets and If I would set them up > > as a test rig, I would use three, like '300baud.de', 'foo.300baud.de' > > and 'bar.300baud.de'. In 300baud.de I would set up the WKD directory and > > the SSL cert, with an entry for wildcard subdomains which would cover then > > hosts foo and bar. In the WKD directory I would put then a couple of keys with > > proper sample email addresses from all three hosts. > > That's a lot of "ifs". Right now, 300baud.de has neither A nor AAAA nor > CNAME record, so there is no server IP address to contact. Obviously > there is also no wildcard record either, as e.g. www.300baud.de does not > resolve. It's not clear to me which (sub)domain you would want to use > in a fictional OpenPGP key's user ID? There is currently no server running under my 300baud.de domain. I had to shut them down due to recent changes in DO's TOS. > > > With this set-up, without noodling around with records settings at my domain > > service (for ease of use and managing WKD) I stronly assume that this > > set-up follows the direct method and works with sequoia-pgp properly and > > should fail currently with GnuPG and gpg4win,same as it fails with GitHub. > > It's actually pretty easy. If the openpgpkey... subdomain resolves > (explicit entry or DNS wildcard), then the advanced method is used. > Otherwise the simple method. That's the only difference, and it does > not depend on whatever your certificate contains. > > Depending on the chosen method, you need to make sure that there is a > web server answering with a *valid* TLS certificate and with the proper > expected directory structure. There is no reason at all to "strongly > assume" any malfunction or bug in GnuPG and I assure you that it's > possible to make either method work. Mmmh, probably we can discuss this *valid* until we get blue in the face ... > > The only difference for Sequoia is that it ignores your expressed intent > to use the advanced method if something is misconfigured, and falls back > to the simple method. GnuPG does not do that, because it correctly > follows the specification word by word. Which would make sense to me and thankfully sequoia-pgp does this. > > IIRC the (old) WKD specs did not mention nor did they said that it was required > > to noodle around witth domain settings, regarding the openpgpkey folder when > > setting up records for hosts with a domain service provider. > > WKD is still an Internet *Draft*, so it's expected to find corner cases > like yours that are not yet 100 % unambiguous. That's what the drafting > process and public discussion is intended for. Different > interpretations should not be possible, and you found a case where > Sequoia and GnuPG really do differ. But it still does *not* say one > needs to "noodle around with domain settings". It points you to the > right spice to add just in case your domain settings are already a > noodle soup. Draft, yes I know and I desperately hope with this whole thread that Werner and most important OpenPGP users and organizations around the globe think about this, because it could have IMHO a *major* impact for OpenPGP key distribution, when it comes to easy set-up and maintaining themselve a WKD service while not relying on third parties, like Hagrid or later the hockeypuck Network, for whatever reasons people may have. sequoia did the right step and I hope for people relying on GnuPG that it is possible for them in the future too. Best regards Stefan From juergen at bruckner.email Wed Jan 13 21:23:32 2021 From: juergen at bruckner.email (Juergen Bruckner) Date: Wed, 13 Jan 2021 21:23:32 +0100 Subject: WKD & Sequoia In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <8f925793-3fa5-4a36-e1c2-fe340bb74f8a@colomb.de> Message-ID: Hello Stefan! [...] > sequoia did the right step and I hope for people relying on GnuPG that > it is possible for them in the future too. So did Sequoia do that? You consider not to follow policies "the right step"? Sorry, but you dont have a clue about security! The only right way is to follow policies word by word. So far you only presented us assumptions here, with a non working setup, and also a setup which never was intended for such a case. m2c Juergen -- /?\ No | \ / HTML | Juergen Bruckner X in | juergen at bruckner.email / \ Mail | -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From spam.trap.mailing.lists at gmail.com Wed Jan 13 21:44:07 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 13 Jan 2021 21:44:07 +0100 Subject: WKD & Sequoia In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <8f925793-3fa5-4a36-e1c2-fe340bb74f8a@colomb.de> Message-ID: On Wed, Jan 13, 2021 at 9:24 PM Juergen Bruckner via Gnupg-users wrote: > > Hello Stefan! > > > [...] > > sequoia did the right step and I hope for people relying on GnuPG that > > it is possible for them in the future too. > > So did Sequoia do that? > You consider not to follow policies "the right step"? > Sorry, but you dont have a clue about security! > > The only right way is to follow policies word by word. > > So far you only presented us assumptions here, with a non working setup, > and also a setup which never was intended for such a case. Hi Juergen, looks like you are a bit upset, like probably others as well. That is good and I hope people understand what this whole thread is about! Regarding security, can you give us a valid example what security implications you see? I trust the sequoia team, for example, strongly assuming, that they know how to implement fetching a binary blob without any problems. BTW. If I remember correctly you once (or I did that?) presented a link from Austrian Goverment authorities using OpenPGP keys on their web pages. I am not aware how their network is set-up and it is not my business, but would you not agree that it would be very nice to have a wildcard subdomain solution, for all their inhouse offices and employees email addresses, while managing themselves key distribution? BTW. For GitHub users ... :-) ( a nice addition too, when it comes to OpenPGP keys) https://keyoxide.org/guides/github Regards Stefan From gnupg at eckner.net Wed Jan 13 21:55:51 2021 From: gnupg at eckner.net (Erich Eckner) Date: Wed, 13 Jan 2021 21:55:51 +0100 (CET) Subject: WKD & Sequoia In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <8f925793-3fa5-4a36-e1c2-fe340bb74f8a@colomb.de> Message-ID: <2317dc57-9526-3d17-4ea7-565358b86548@eckner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, 13 Jan 2021, Juergen Bruckner via Gnupg-users wrote: > Hello Stefan! Hi all, > > > [...] >> sequoia did the right step and I hope for people relying on GnuPG that >> it is possible for them in the future too. > > So did Sequoia do that? > You consider not to follow policies "the right step"? > Sorry, but you dont have a clue about security! > > The only right way is to follow policies word by word. That is certainly correct. But: WKD is "just" a draft, so it's open to suggestions for change. "Ignore invalid certificates of the advanced URL" is one suggestion. In my view, this whole, lengthy thread boils down to the question, whether we want that or we don't want that. Let me share my two cents: I *feel*, like invalid certificates of advanced WKD URLs should not be ignored, because this indicates, something is not as it should be (e.g. it is "unclean"). The fact, that this might slow down WKD deployment, because it makes the dns setup *slightly* harder, stands against this feeling. btw: I just recently changed (motivated by this thread) from the direct to the advanced method of WKD deployment, eliminating the need for a reverse proxy on archlinux32.org - and the need for a "no-wildcard" TXT record on openpgpkey.archlinux32.org. ... why on earth did I set it up with the direct method in the first place? ;-) regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl//XlgACgkQCu7JB1Xa e1rm+Q/+ImdVv9mimg7aRC5aceS/iYqqZwUhWdvVZEs6s/9bVJf1Ur1MyhoySU2U BhDZknlwJY9UUw54x1Pk2wASABlzpcpr2XmTLmgmpBr3ti3nMkhK/fDLT537EOlz H8ngzdUA/Hj3suGlhfMgGoUyh2PDsF9N3y3mPVKs0ym7qWaPwSc6NPi05pKzetYk Y4qPIezFD8vX3dWUJTShVgppdusWtekKmPJ8oFAb+J+Ccwc+G/oaTysfH2X5azF9 YOnWb5Sed61fqynPjTFcJ5uTwCnxl9e96plCaw2kricBGoH+/siskO0KYZ0aWGrB 5b4vKDJd+gmu8Iwb3vKSKUsFpK5ek9M9IThGKA8etNYjYDkLzWTmXjZ3+HjvaF/+ zf+koPNWZIPmd6g2HMGyM5k7nftfg3Qze8NDDvR1JN68+0kKxdMl5Hf0OAZ0Babj luRqFcLw8rLZWd93DsiTevYMFa3vTnao2S0fHgoBpgCeTpeW/euDJWKH/0N8Bnjk zarOhDXSDJQZEi76zIgicE7eWY7VgYJcf3xolAmuA90Qf7UOdor5Ub4KWLgrMgQd NTwsP7tqrXougtcmIoe7MXTdiacO7bSKxPso7z3e53FeDH+pvO9j8q8T99zWSvFR JXVxAZ8dTO3INA7GwLAY2pa5IY8WTeJCSh0fj0P+QArezFd1NeA= =tA3p -----END PGP SIGNATURE----- From spam.trap.mailing.lists at gmail.com Wed Jan 13 22:16:02 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 13 Jan 2021 22:16:02 +0100 Subject: WKD & Sequoia In-Reply-To: <2317dc57-9526-3d17-4ea7-565358b86548@eckner.net> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <8f925793-3fa5-4a36-e1c2-fe340bb74f8a@colomb.de> <2317dc57-9526-3d17-4ea7-565358b86548@eckner.net> Message-ID: On Wed, Jan 13, 2021 at 10:00 PM Erich Eckner via Gnupg-users wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Wed, 13 Jan 2021, Juergen Bruckner via Gnupg-users wrote: > > > Hello Stefan! > > Hi all, > > > > > > > [...] > >> sequoia did the right step and I hope for people relying on GnuPG that > >> it is possible for them in the future too. > > > > So did Sequoia do that? > > You consider not to follow policies "the right step"? > > Sorry, but you dont have a clue about security! > > > > The only right way is to follow policies word by word. > > That is certainly correct. But: WKD is "just" a draft, so it's open to > suggestions for change. "Ignore invalid certificates of the advanced URL" > is one suggestion. Correct a suggestion and Neal for example discussed this with his team in the past and they gave users, like me, the ability for a working solution, without IMHO breaking the specs. > In my view, this whole, lengthy thread boils down to the question, whether > we want that or we don't want that. Well, I see this a bit different. If it comes to discussions or votes on this ML here or the IETF ML, than this is only a minority IMHO and it can also been down voted etc. As you said this is a draft It should formulated this way IMHO that it allows the greatest flexibility in a protokoll, to fulfill all use cases, when it comes to WKD. I also understand that WKD is Werner's baby but when a draft or an RFC is present than it should be allowed to have a healthy discussion. Regards Stefan From andre at colomb.de Wed Jan 13 23:41:52 2021 From: andre at colomb.de (=?ISO-8859-1?Q?Andr=E9_Colomb?=) Date: Wed, 13 Jan 2021 23:41:52 +0100 Subject: WKD & Sequoia In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <8f925793-3fa5-4a36-e1c2-fe340bb74f8a@colomb.de> Message-ID: Am 13. Januar 2021 21:44:07 MEZ schrieb Stefan Claas via Gnupg-users : >Hi Juergen, > >looks like you are a bit upset, like probably others as well. I hope others don't mind me speaking in their names. Stefan, we are upset by you making false accusations about which software does something right or wrong. Both softwares are reacting differently to an error which lies in your TLS certificate usage (as several people have proven multiple times). You're not even to blame for that root cause, because it is not under your control. Don't only look at the end result, but please try to understand that the cause lies deeper than just the spec or the clients you tried. >I am not aware how their network is set-up and it is not my business, >but would you not agree that it would be very nice to have a wildcard >subdomain solution, for all their inhouse offices and employees email >addresses, while managing themselves key distribution? It's a little unclear what *exactly* you mean with "a wildcard subdomain solution". WKD can work perfectly with wildcards involved, both on the DNS and TLS levels. But such things can be misconfigured and the spec even explicitly mentions one possible pitfall including a solution. Reactions to that kind of misconfiguration should also be standardized in the spec. That's all there is to criticize, IMHO. Kind regards Andr? -- Greetings... From: Andr? Colomb From spam.trap.mailing.lists at gmail.com Thu Jan 14 00:06:12 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 14 Jan 2021 00:06:12 +0100 Subject: WKD & Sequoia In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <8f925793-3fa5-4a36-e1c2-fe340bb74f8a@colomb.de> Message-ID: On Wed, Jan 13, 2021 at 11:45 PM Andr? Colomb wrote: > > Am 13. Januar 2021 21:44:07 MEZ schrieb Stefan Claas via Gnupg-users : > >Hi Juergen, > > > >looks like you are a bit upset, like probably others as well. > > I hope others don't mind me speaking in their names. Stefan, we are upset by you making false accusations about which software does something right or wrong. Both softwares are reacting differently to an error which lies in your TLS certificate usage (as several people have proven multiple times). You're not even to blame for that root cause, because it is not under your control. Don't only look at the end result, but please try to understand that the cause lies deeper than just the spec or the clients you tried. I am fully ok with that. All my replies here where not intended to "accuse" someone! In my OP I kindly asked if a kind soul can help me and IIRC it was mentioned that the direct method is fine and I figured out that GnuPG seems not to try the direct method while sequoia-pgp tries the direct method. It had been *really* nice if Werner had chimed in, like Neal, and had explained by himself why this is a definetly a no-go to try the direct-method first, or in case why when the advanced method failed it does not try the direct method and what security implications this has. Maybe, I don't know, readers here on the ML are asking themselves now why do we have two methods, e.g. what is their purpose and what informations can one gain from an IMHO very nice WKD checker, Wiktor has created. If the draft will be changed in the future to only allow the advanced-method and the direct-method will be dropped, ok, I have to accept this, for GitHub usage and whatever sites have a similar set-up and that's it. Then maybe a question, from readers may come up, why it was dropped, when it was implemented in the first place, regardless of GitHub etc. > >I am not aware how their network is set-up and it is not my business, > >but would you not agree that it would be very nice to have a wildcard > >subdomain solution, for all their inhouse offices and employees email > >addresses, while managing themselves key distribution? > > It's a little unclear what *exactly* you mean with "a wildcard subdomain solution". WKD can work perfectly with wildcards involved, both on the DNS and TLS levels. But such things can be misconfigured and the spec even explicitly mentions one possible pitfall including a solution. I think I have explained, at least for an expert like you, my set-up for 300baud.de, I would use. As soon as time permits I will do this, even if this cost me money I can spend for other things. But I gives me then a better overview and I can correct myself while thinking my set-up would be equally to GitHub's set-up. In case I get stucked I would like to ask you for advise. Please note: I will not use the advanced method, I like to see if this will work with sequoia-pgp and GnuPG. Regards Stefan From angel at pgp.16bits.net Thu Jan 14 01:47:12 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Thu, 14 Jan 2021 01:47:12 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <874kjlb3pu.wl-neal@walfield.org> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> Message-ID: <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> On 2021-01-13 at 10:12 +0100, Neal H. Walfield wrote: > I'd like to clarify what Sequoia is doing (wrong). > (...) Hello Neal Thanks for chiming in and explaining the steps taken by sequoia. I'll try to re-focus this subthread back on the initial topic of your email. > The I-D says "Only if the required sub-domain does not exist, they > SHOULD fall back to the direct method." The text doesn't say: "If > there is an error, they SHOULD fallback to the direct method unless > the required sub-domain does not exist, in which case they MUST NOT > fall back to the direct method." So, strictly speaking, I don't > think Sequoia is violating the specification. I understand this to mean it as "only use the direct method if the required sub-domain does not exist", with the SHOULD meaning that the direct method is not required (not sure why, I would have probably used a MUST). As such, I do think sequoia is non-conformant, although I'm more interested in determining the proper behaviour of a WKD client. > We thought about this question, but we couldn't figure out a > satisfactory answer. The worst attack we could come up with is: > (...) > So sure, that's possible, but it seems like WKD shouldn't foo.com's > biggest worry in that case. I can make up some scenarios where foo.com is hosted on EvilCDN and openpgpkey.foo.com in a safe server. But I agree that's not too likely. I think it would be good that sq stopped after processing openpgpkey.foo.com, mainly to follow the principle of least surprise. If the key can only be placed in one place, then it MUST be good (or bad, but it will be consistent). If the admins wanted to use the advanced method, but misconfigured it, while testing only with sequoia (but having a good direct method), they would be misled to think WKD is properly implemented, while it is not. The team managing foo.com may be completely different (e.g. marketing) than those handling pgp keys (e.g. email sysadmins). By keeping the openpgpkey subdomain for themselves, the admins can give complete control of the apex website to marketing (known to fill their credentials on phishing pages from time to time) without letting them any access to publish pgp keys. Hard to debug errors: "when fetching your key via wkd, I do receive your key from your server, but it expired in 2018!" can have people scratching their head for a long time (the last key is there, there is no 2018 key stored here?) until figuring that the server certificate of openpgpkey.foo.com expired (and they had an old key on the main website). A direct error "Certificate of openpgpkey.foo.com expired 2 days ago" would have been much clearer. > On the other hand, implementing this prohibition means that a DNS > server can prevent its clients from using WKD by forcing all > openpgpkey subdomains to resolve to 127.1. That's hard to notice, > because everything else still appears to work. I think it's the other way round. If sequoia falls back to the direct method and returns "No WKD key published for jdoe at foo.com", it will get unnoticed. A hard error of "Couldn't connect to openpgpkey.foo.com (127.0.0.1)" or "The certificate of openpgpkey.foo.com (1.2.3.4) is not trusted" would make it noticeable. Probably the most important part of the rule: "all implementations of WKD should behave in the same way". I don't mind if it was gnupg that was changed to behave like sequoia, but given identical conditions, ideally all clients (and the draft reading) should produce the same result (find key X, an error, etc.). > we helped an organization deploy WKD, and they had a similar problem? It was misconfigured. Spawning a https server for openpgpkeys (as they did) is a way to solve it. They could as well have made a openpgpkeys record pointing to the same server as the apex domain, and use a certificate with both names. Or even install the keys on the server providing the 404. It seems the wrong to make it an issue for the client to figure out where the keys may be. There is a long story of browsers helpfully "fixing" the encoding or Content-type of files, which caused a lot of harm in the long term to avoid security issues derived from browser sniffing changing to insecure defaults, when people really meant what they said. It seems difficult the same could happen here, but the idea that the server should be properly set up, rather than the client fixing the errors for the user is the same. I would recommend to remove the or_else case and fail with an error if the advanced method is (supposedly) set up but fails. At least, I think there should be a diagnostic e.g. "WKD advanced method configured but broken. Connection to openpgpkey.foo.com (1.2.3.4) failed: Bad certificate. Trying direct method" although I would prefer a hard error. (Of course, if the user explicitly requested the client/library to only use the direct method, ignore certificate errors, etc. it'd be fine to do so) Best regards PS: If I'm reading your code correctly, it would not only fall back to the apex domain in case of a certificate error, but also if the key is not found (404), which could result in removing a key (by deleting the container file) having the unintended effect of finding a result through the direct method. PPS: Another benefit would be that we could have avoided this long thread. :-) From spam.trap.mailing.lists at gmail.com Thu Jan 14 08:01:08 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 14 Jan 2021 08:01:08 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> Message-ID: On Thu, Jan 14, 2021 at 1:50 AM ?ngel wrote: > PPS: Another benefit would be that we could have avoided this long > thread. :-) The greatest benefit would have been if the author of WKD, namly Werner Koch, had been so kind to explain to us why WKD needs two methods and what security implications it has when an application falls back to a valid direct-method, instead of people defending him or his implementation. :-) Best regards Stefan From andre at colomb.de Thu Jan 14 09:02:14 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Thu, 14 Jan 2021 09:02:14 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> Message-ID: Hi ?ngel, thanks for your contribution with a clear focus. On 14/01/2021 01.47, ?ngel wrote: > Probably the most important part of the rule: "all implementations of > WKD should behave in the same way". I don't mind if it was gnupg that > was changed to behave like sequoia, but given identical conditions, > ideally all clients (and the draft reading) should produce the same > result (find key X, an error, etc.). I agree with that. And the next draft version SHOULD be very clear about this to avoid future discussions :-) > I would recommend to remove the or_else case and fail with an error if > the advanced method is (supposedly) set up but fails. At least, I think > there should be a diagnostic e.g. "WKD advanced method configured but > broken. Connection to openpgpkey.foo.com (1.2.3.4) failed: Bad > certificate. Trying direct method" although I would prefer a hard > error. Definitely, the decision which method to try should be very simple, as the WKD draft intended. Only one decision point instead of many paths leading back to a change of method. > (Of course, if the user explicitly requested the client/library to only > use the direct method, ignore certificate errors, etc. it'd be fine to > do so) That's an excellent suggestion, giving Sequoia an option to force trying one method or the other. I don't know if adding as many command line switches as gpg has is your cup of tea, but e.g. an environment variable could be used to really make it a "debugging" type of option. The great benefit is that Sequoia can then act as a WKD checker, which should always examine the intended, but possibly misconfigured, method or even both. > PPS: Another benefit would be that we could have avoided this long > thread. :-) I couldn't resist trying to help Stefan understand where the error lies, so apologies for my share of the message flood :-) Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From andre at colomb.de Thu Jan 14 09:08:57 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Thu, 14 Jan 2021 09:08:57 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> Message-ID: Hi Stefan, On 14/01/2021 08.01, Stefan Claas via Gnupg-users wrote: > The greatest benefit would have been if the author of WKD, namly Werner Koch, > had been so kind to explain to us why WKD needs two methods and what > security implications it has when an application falls back to a valid > direct-method, > instead of people defending him or his implementation. :-) I think Werner would have participated in the discussion already if other people's explanations had been incorrect. It's an open standard, and your focus on one person who happens to be the registered author doesn't help. If you insist on Werner's personal opinion, then you should maybe contact him directly instead of the GnuPG-Users list. Knowing well that he has no obligation to reply to anyone. Hopefully my (and others') attempts to explain / defend the WKD specification were still useful to you. Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From andre at colomb.de Thu Jan 14 09:35:42 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Thu, 14 Jan 2021 09:35:42 +0100 Subject: WKD & Sequoia In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <8f925793-3fa5-4a36-e1c2-fe340bb74f8a@colomb.de> Message-ID: On 14/01/2021 00.06, Stefan Claas wrote: > Maybe, I don't know, readers here on the ML are asking themselves now why do we > have two methods, e.g. what is their purpose and what informations can > one gain from > an IMHO very nice WKD checker, Wiktor has created. Quoting from your own mail: "As you said this is a draft It should formulated this way IMHO that it allows the greatest flexibility in a protokoll, to fulfill all use cases, when it comes to WKD." https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064645.html Nobody wants to remove any method, as that would reduce flexibility. The "advanced method" is not more complicated to set up, it's just a matter of preference really. > I think I have explained, at least for an expert like you, my set-up > for 300baud.de, I would use. I repeat, it's not clear to me yet. But let's stop here and discuss that when you have the basics up and running. > As soon as time permits I will do this, even if this cost me > money I can spend for other things. But I gives me then a better > overview and I can correct myself while thinking my > set-up would be equally to GitHub's set-up. In case I get stucked I > would like to ask you > for advise. Please note: I will not use the advanced method, I like to > see if this will work > with sequoia-pgp and GnuPG. You don't need to spend money just to prove anything to the ML subscribers. But when you do try, I offer to help with any problems coming up. You should not rule out the advanced method yet. Depending on your setup, it might actually be the easier route if wildcard domains are involved. Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ayoubhm at gmail.com Thu Jan 14 06:14:26 2021 From: ayoubhm at gmail.com (Ayoub Misherghi) Date: Wed, 13 Jan 2021 21:14:26 -0800 Subject: How can I add encrypted comments. Message-ID: <9ee44bc1-db77-3906-759c-31d1a91af1ea@gmail.com> An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Jan 14 14:43:06 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Jan 2021 14:43:06 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> (=?utf-8?Q?=22=C3=81ngel=22's?= message of "Thu, 14 Jan 2021 01:47:12 +0100") References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> Message-ID: <87pn27hbx1.fsf@wheatstone.g10code.de> On Thu, 14 Jan 2021 01:47, ?ngel said: > I understand this to mean it as "only use the direct method if the > required sub-domain does not exist", with the SHOULD meaning that the > direct method is not required (not sure why, I would have probably used Right. The subdomain is actually a workaround for SRV RR. We can't use the latter in browser based implementation and thus need to resort to this hack. SHOULD was used to allow the direct method in existing use cases. In case this has not yet been mention: If wildcards are used in the DNS a dummy TXT RR should be used to except the openpgpkey subdomain from wildcarding. 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 spam.trap.mailing.lists at gmail.com Thu Jan 14 16:20:18 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 14 Jan 2021 16:20:18 +0100 Subject: WKD & Sequoia In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <8f925793-3fa5-4a36-e1c2-fe340bb74f8a@colomb.de> Message-ID: On Thu, Jan 14, 2021 at 9:35 AM Andr? Colomb wrote: > > On 14/01/2021 00.06, Stefan Claas wrote: > > Maybe, I don't know, readers here on the ML are asking themselves now why do we > > have two methods, e.g. what is their purpose and what informations can > > one gain from > > an IMHO very nice WKD checker, Wiktor has created. > > Quoting from your own mail: > "As you said this is a draft It should formulated this way IMHO that it > allows the greatest flexibility in a protokoll, to fulfill all use > cases, when it comes to WKD." > > https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064645.html > > Nobody wants to remove any method, as that would reduce flexibility. > The "advanced method" is not more complicated to set up, it's just a > matter of preference really. Yes, but as you IIRC said to me that direct-method usage is fine and Wiktor's WKD checker gave also a green light for the direct-method for my GitHub set-up, you see that it is still not working with GnuPG. > > I think I have explained, at least for an expert like you, my set-up > > for 300baud.de, I would use. > > I repeat, it's not clear to me yet. But let's stop here and discuss > that when you have the basics up and running. > > > As soon as time permits I will do this, even if this cost me > > money I can spend for other things. But I gives me then a better > > overview and I can correct myself while thinking my > > set-up would be equally to GitHub's set-up. In case I get stucked I > > would like to ask you > > for advise. Please note: I will not use the advanced method, I like to > > see if this will work > > with sequoia-pgp and GnuPG. > > You don't need to spend money just to prove anything to the ML > subscribers. But when you do try, I offer to help with any problems > coming up. You should not rule out the advanced method yet. Depending > on your setup, it might actually be the easier route if wildcard domains > are involved. Thanks for the kind offer, like I said I will not use the advanced-method, because it has a purpose, which I like to test and see and then if everything works as expected I will also tell why not an advanced-method. Best regards Stefan From spam.trap.mailing.lists at gmail.com Thu Jan 14 16:33:00 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 14 Jan 2021 16:33:00 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> Message-ID: On Thu, Jan 14, 2021 at 9:42 AM Andr? Colomb wrote: > > Hi Stefan, > > On 14/01/2021 08.01, Stefan Claas via Gnupg-users wrote: > > The greatest benefit would have been if the author of WKD, namly Werner Koch, > > had been so kind to explain to us why WKD needs two methods and what > > security implications it has when an application falls back to a valid > > direct-method, > > instead of people defending him or his implementation. :-) > > I think Werner would have participated in the discussion already if > other people's explanations had been incorrect. It's an open standard, > and your focus on one person who happens to be the registered author > doesn't help. If you insist on Werner's personal opinion, then you > should maybe contact him directly instead of the GnuPG-Users list. > Knowing well that he has no obligation to reply to anyone. And that is the reason why I did not contacted him and maybe you and everybody else remember that I asked in my initial post for help from the community. > > Hopefully my (and others') attempts to explain / defend the WKD > specification were still useful to you. it does not matter if it was useful for me, but at least it shows how the GnuPG ecosystem works, so that the interested reader can form an own opinion. My intitial post was a help request and I also explained why it IMHO would be good to have such a solution, which would not hurt the GnuPG ecosystem in any form and would be IMHO an enrichment for GnuPG usage. I can only say *big thanks* to the sequoia team that sq.exe can handle this. Best regards Stefan From spam.trap.mailing.lists at gmail.com Thu Jan 14 20:16:47 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 14 Jan 2021 20:16:47 +0100 Subject: How can I add encrypted comments. In-Reply-To: <9ee44bc1-db77-3906-759c-31d1a91af1ea@gmail.com> References: <9ee44bc1-db77-3906-759c-31d1a91af1ea@gmail.com> Message-ID: On Thu, Jan 14, 2021 at 10:46 AM Ayoub Misherghi via Gnupg-users wrote: > > > I am encrypting and signing documents with myself as the receiver. Nobody else will want to look inside them. Is it possible to add encrypted comments or other information to a separated signature file; and later retrieve this additional information? I want to be able to decrypt the signature file alone and retrieve all the information I put inside it. You can add Comments: to a detached signature, yes, but beware that these encrypted content must be seperated for each comment line. I have not tested this yet, but you could with a shell script use some format or lenght preserving encryption software, like Google's Adiantum with a base64 encoder and then would have the smallest possible symmetrically encrypted output for a message as Comment: line. You can do this also manually of course as much as you wish because it does not invalidate the signature. Hope this helps a bit. Regards Stefan From spam.trap.mailing.lists at gmail.com Thu Jan 14 20:52:53 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 14 Jan 2021 20:52:53 +0100 Subject: How can I add encrypted comments. In-Reply-To: References: <9ee44bc1-db77-3906-759c-31d1a91af1ea@gmail.com> Message-ID: On Thu, Jan 14, 2021 at 8:16 PM Stefan Claas wrote: > > On Thu, Jan 14, 2021 at 10:46 AM Ayoub Misherghi via Gnupg-users > wrote: > > > > > > I am encrypting and signing documents with myself as the receiver. Nobody else will want to look inside them. Is it possible to add encrypted comments or other information to a separated signature file; and later retrieve this additional information? I want to be able to decrypt the signature file alone and retrieve all the information I put inside it. > > You can add Comments: to a detached signature, yes, but beware that these > encrypted content must be seperated for each comment line. > > I have not tested this yet, but you could with a shell script use some format > or lenght preserving encryption software, like Google's Adiantum with a base64 > encoder and then would have the smallest possible symmetrically encrypted > output for a message as Comment: line. You can do this also manually > of course as much as you wish because it does not invalidate the signature. > > Hope this helps a bit. Here is a quick manually inline sig. First message with GnuPG symmetric content in Comment lines and second same message with Google's Adiantum+base64 You see the difference, what I mean with format preserving. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello World! :-) Regards Stefan -----BEGIN PGP SIGNATURE----- Comment: -----BEGIN PGP MESSAGE----- Comment: Comment: jA0EBwMCMx3mMIiLwjPH0mgBh3We4k31HkKJ7W8c9oju++X96uaNVB5mMEDJhhr6 Comment: Ao5wibzeivfsfFL9Si2cCc/X9kUG2maKHSwb+51nwtcFSRNT2h99SQlbMPzRkoku Comment: EkyCpYpeq+d8gyMeJ+uNgEvtAwHF35RYVQ== Comment: =Vain Comment: -----END PGP MESSAGE----- iHUEARYIAB0WIQR61Pk5PUF7u6Rs+mem3tVibXmEGgUCYACeDgAKCRCm3tVibXmE Gpk6AP98iXZb8gd0NDvOllByTHkrcQvQluXd/db1c5u+skm90gEAj5c991XdP5s5 clB9wwK9G8XoCDJnhfMLWljuvjCM8Ac= =XJXL -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello World! :-) Regards Stefan -----BEGIN PGP SIGNATURE----- Comment: vHgPAUzXglLiVFelwf0jjUzXCNIqSrinvNhjF+JRkd8K iHUEARYIAB0WIQR61Pk5PUF7u6Rs+mem3tVibXmEGgUCYACeDgAKCRCm3tVibXmE Gpk6AP98iXZb8gd0NDvOllByTHkrcQvQluXd/db1c5u+skm90gEAj5c991XdP5s5 clB9wwK9G8XoCDJnhfMLWljuvjCM8Ac= =XJXL -----END PGP SIGNATURE----- Regards Stefan From vedaal at nym.hush.com Thu Jan 14 19:37:37 2021 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Thu, 14 Jan 2021 13:37:37 -0500 Subject: How can I add encrypted comments. In-Reply-To: <9ee44bc1-db77-3906-759c-31d1a91af1ea@gmail.com> Message-ID: <20210114183738.1436F805142@smtp.hushmail.com> On 1/14/2021 at 4:47 AM, "Ayoub Misherghi via Gnupg-users" wrote: body p { margin-bottom:0; margin-top:0; } I am encrypting and signing documents with myself as the receiver. Nobody else will want to look inside them. Is it possible to add encrypted comments or other information to a separated signature file; and later retrieve this additional information? I want to be able to decrypt the signature file alone and retrieve all the information I put inside it. ===== Not exactly, but functionally, yes, it can be done. [1] Armor the signature file ( gpg --armor filename.sig ) this outputs to filename.sig.asc [2[ Armor your encrypted comments, and copy them to the end of the filename.sig.asc, (leave one blank line between the pgp footer of the signature file, and the pgp header of the encrypted file) [3] Save the whole thing as filename.sig.asc [4] gpg filename.sig,asc will automatically verify the sig if the original signed file 'filename' is present, and also decrypt the added comments vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam.trap.mailing.lists at gmail.com Thu Jan 14 22:09:11 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 14 Jan 2021 22:09:11 +0100 Subject: How can I add encrypted comments. In-Reply-To: <25894571-e984-a36d-a415-13cfe8b707f9@gmail.com> References: <9ee44bc1-db77-3906-759c-31d1a91af1ea@gmail.com> <25894571-e984-a36d-a415-13cfe8b707f9@gmail.com> Message-ID: On Thu, Jan 14, 2021 at 9:30 PM Ayoub Misherghi wrote: > Yes I see, thanks. You went at length to help me. Can you please point me to a reference that > > discusses the standard format of the signature file? I might do something silly. Here is the offical OpenPGP RFC: https://tools.ietf.org/html/rfc4880 And have fun doing something 'silly' ! ;-) Regards Stefan From ayoubhm at gmail.com Thu Jan 14 21:02:37 2021 From: ayoubhm at gmail.com (Ayoub Misherghi) Date: Thu, 14 Jan 2021 12:02:37 -0800 Subject: How can I add encrypted comments. In-Reply-To: <20210114183738.1436F805142@smtp.hushmail.com> References: <20210114183738.1436F805142@smtp.hushmail.com> Message-ID: <91bd8055-c92d-29b4-0ed0-439ab13d7847@gmail.com> An HTML attachment was scrubbed... URL: From ayoubhm at gmail.com Thu Jan 14 21:30:37 2021 From: ayoubhm at gmail.com (Ayoub Misherghi) Date: Thu, 14 Jan 2021 12:30:37 -0800 Subject: How can I add encrypted comments. In-Reply-To: References: <9ee44bc1-db77-3906-759c-31d1a91af1ea@gmail.com> Message-ID: <25894571-e984-a36d-a415-13cfe8b707f9@gmail.com> An HTML attachment was scrubbed... URL: From vedaal at nym.hush.com Thu Jan 14 22:48:31 2021 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Thu, 14 Jan 2021 16:48:31 -0500 Subject: How can I add encrypted comments Message-ID: <20210114214831.CAFD5805146@smtp.hushmail.com> vedaal at nym.hush.com vedaal at nym.hush.comwrote on Thu Jan 14 19:37:37 CET 2021: >but functionally, yes, it can be done.----- my mistake. Can't really be done this way :-((===== >[1] Armor the signature file ( gpg --armor filename.sig ) -----should be enarmor instead of armor :-( this outputs to filename.sig.asc [2[ Armor your encrypted comments, and copy them to the end of thefilename.sig.asc, (leave one blank line between the pgp footer of the signature file,and the pgp header of the encrypted file) [3] Save the whole thing as filename.sig.asc [4] gpg filename.sig,asc will automatically verify the sig if theoriginal signed file 'filename' is present, and also decrypt the addedcomments-----It doesn't.It gives weird error messages.sorry ;-( vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam.trap.mailing.lists at gmail.com Thu Jan 14 23:18:47 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 14 Jan 2021 23:18:47 +0100 Subject: How can I add encrypted comments. In-Reply-To: <91bd8055-c92d-29b4-0ed0-439ab13d7847@gmail.com> References: <20210114183738.1436F805142@smtp.hushmail.com> <91bd8055-c92d-29b4-0ed0-439ab13d7847@gmail.com> Message-ID: On Thu, Jan 14, 2021 at 11:15 PM Ayoub Misherghi via Gnupg-users wrote: > > > On 1/14/2021 10:37 AM, vedaal at nym.hush.com wrote: > > On 1/14/2021 at 4:47 AM, "Ayoub Misherghi via Gnupg-users" wrote: > > > I am encrypting and signing documents with myself as the receiver. Nobody else will want to look inside them. Is it possible to add encrypted comments or other information to a separated signature file; and later retrieve this additional information? I want to be able to decrypt the signature file alone and retrieve all the information I put inside it. > > > ===== > > Not exactly, > > but functionally, yes, it can be done. > > > [1] Armor the signature file ( gpg --armor filename.sig ) this outputs to filename.sig.asc > > > [2[ Armor your encrypted comments, and copy them to the end of the filename.sig.asc, > > (leave one blank line between the pgp footer of the signature file, and the pgp header of the encrypted file) > > > [3] Save the whole thing as filename.sig.asc > > > [4] gpg filename.sig,asc will automatically verify the sig if the original signed file 'filename' is present, and also decrypt the added comments > > > vedaal > > ===== > > I have the concern that if this is not part of GPG, future versions of GPG may not allow it; leaving me in the lurch. > > > I have these questions: > > [Q1] Does this mean "filename.sig.asc" will still be decrypted if "filename" is not present? > > [Q2] Is there a reason why the functionality is missing from GPG? > > [Q3] The references I find on the internet are directed at users of GPG and not > > developers of applications of GPG, can you please direct me to references that > > show me things like the format of the signature file, armor and not? > > > Thanks, > > Ayoub Sorry for chiming in, the link I gave you is normally meant for implementors of OpenPGP software. In case this is not so easy to understand you may try a visually approach, while creating some standard files/sigs and then examine the armored bytes with this tool: https://github.com/ConradIrwin/gpg-decoder Best regards Stefan From gnupg at raf.org Fri Jan 15 01:56:04 2021 From: gnupg at raf.org (raf) Date: Fri, 15 Jan 2021 11:56:04 +1100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> Message-ID: <20210115005604.nlhu3nnvzjdalzxw@raf.org> On Thu, Jan 14, 2021 at 04:33:00PM +0100, Stefan Claas via Gnupg-users wrote: > [...] My initial post was a help request and I also explained > why it IMHO would be good to have such a solution, which > would not hurt the GnuPG ecosystem in any form and would be > IMHO an enrichment for GnuPG usage. > > Best regards > Stefan [Note: First 3 paragraphs are mostly me being stupid - please bear with me] It sounded to me like you would like gnupg to have a bug added to it, whereby it accepts invalid certificates for sub-sub-domains, when the certificate is only valid for sub-domains. To me, that doesn't sound like it "would not hurt the GnuPG ecosystem in any form". To me, that sounds like a security bug, in the sense that it could lead users to think that a certificate is valid, when it isn't. If the ability to not validate certificates exists or gets added to gnupg, it wouldn't be turned on by default, so I'm not sure that it would even help your use case. The only people who could fetch your keys would be the ones who had disabled certificate validation. But of course, you're not asking for that. You're just asking for something to work. There must be other ways. Accepting invalid certificates might just have been my first thought at how to deal with this. But that would enable the advanced method to work (in situations where it shouldn't). If I remember correctly (possibly not), you wanted the direct method to work, and github.io's mis-configuration of certificates caused the advanced method to be attempted and fail, before the direct method could even be attempted. It's been suggested that, when the certificate for openpgpkey.*.github.io is found to be invalid, WKD clients could failover to the direct method (like sequoia does). Then at least the direct method would work with github.io sub-domains. That sounded good (to a non-expert like me). But perhaps it's a bit inefficient. But at least it's automatic. Another possible solution might be for WKD clients to have a list of domains to skip when doing the advanced method. If it had "openpgpkey.*.github.io" by default, then it would know not to try to resolve openpgpkey.*.github.io at all. Any domain that hands out invalid certificates for sub-sub-domains could be in the skip list. The currently documented solution to this expects the administrators of such (mis-configured) domains to add DNS records to prevent this, but when you can't rely on that happening, allowing the client/user to exclude them could be another option. And it wouldn't require accepting invalid certificates. And it would eliminate the attempt to use those domains so it would be more efficient. But it does require additional configuration that the above method doesn't require. A built-in default skip list would help with that. You still couldn't use the advanced method with github.io (until they start issuing a wildcard certificate for each sub-domain), but that's probably OK. I just had a look at https://wiki.gnupg.org/WKD and it doesn't refer to "advanced" or "direct" methods. It seems to consider the "direct" method as the main method, and the "advanced" method as a "Stopgap method" which is "Not recommended - but a temporary workaround". So having an additional mechanism to disable the "advanced" method sounds reasonable. Or maybe the wiki page needs to be updated(?). I'm really not an expert, and the above might not make any sense. I'm just thinking aloud. cheers, raf From andre at colomb.de Fri Jan 15 07:56:26 2021 From: andre at colomb.de (=?ISO-8859-1?Q?Andr=E9_Colomb?=) Date: Fri, 15 Jan 2021 07:56:26 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <20210115005604.nlhu3nnvzjdalzxw@raf.org> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> Message-ID: <042345F0-7CA0-4D6B-BBB6-CE36B88EB66C@colomb.de> Am 15. Januar 2021 01:56:04 MEZ schrieb raf via Gnupg-users : >But of course, you're not asking for that. You're just >asking for something to work. There must be other ways. >Accepting invalid certificates might just have been my >first thought at how to deal with this. But that would >enable the advanced method to work (in situations where >it shouldn't). If I remember correctly (possibly not), >you wanted the direct method to work, and github.io's >mis-configuration of certificates caused the advanced >method to be attempted and fail, before the direct >method could even be attempted. I'll try to complete your summary. The DNS wildcard entry for *.example.github.io leads to the advanced method being tried. We can't change that entry, and therefore with the current protocol draft, it makes no sense forcefully wanting to use the direct method. It's easy to set up the advanced method there. But GitHub uses an invalid TLS certificate for openpgpkey.example.github.io. That's what needs fixing and it is also out of our control. So basically Stefan's request is to change the protocol to work around a misconfiguration because both DNS and the TLS certificate are controlled by a company that offers the service totally unrelated to WKD. Such a workaround could hurt the ecosystem because it may hide a misconfiguration in setups where the operator does have control over these things and just needs to notice. >OK. I just had a look at https://wiki.gnupg.org/WKD and >it doesn't refer to "advanced" or "direct" methods. It >seems to consider the "direct" method as the main >method, and the "advanced" method as a "Stopgap method" >which is "Not recommended - but a temporary >workaround". So having an additional mechanism to >disable the "advanced" method sounds reasonable. Or >maybe the wiki page needs to be updated(?). Sorry, you just misread that part. The stopgap solution is to use a server operated by openpgp.org instead of your own web server. For that to work, you must set up the advanced method for WKD on your domain's DNS. That method is perfectly fine and in some scenarios even easier to use. Kind regards Andr? Hi raf, thanks for your perspective on the matter. -- Greetings... From: Andr? Colomb From spam.trap.mailing.lists at gmail.com Fri Jan 15 07:56:16 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Fri, 15 Jan 2021 07:56:16 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <20210115005604.nlhu3nnvzjdalzxw@raf.org> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> Message-ID: On Fri, Jan 15, 2021 at 2:04 AM raf via Gnupg-users wrote: [...] > I'm really not an expert, and the above might not make > any sense. I'm just thinking aloud. Me neither ... :-) For me, the questions I had is still unresolved when it comes to properly explaing what security implication it gives, when for example sequoia-pgp can handle this and why the draft explicity says it MUST use the advanced-method first. Don't you think when GitHub, a major player, would have an invalid SSL cert, that maybe one of the millions programmers there would not have contacted GitHub, like I did, and say hey GithHub you serve the global community and visitors an invalid SSL certificate? I must admit that I also do not understand what you mean with sus-sub domains. My GitHub page is sac001.github.io and not foo.bar.github.io or whatever. If Werner had told me/us, hey look, according to my draft the advanced method MUST been used because of this and that security implication and it is not allowed in this case to fall back if an (for WKD) invalid cert is present, because of this/that security issue, I guess then I had a better understanding and then I guess also the sequoia team would never had done it so that it works with sequoia-pgp. Regards Stefan From m.gaerman at hush.ai Thu Jan 14 22:45:45 2021 From: m.gaerman at hush.ai (m.gaerman at hush.ai) Date: Thu, 14 Jan 2021 16:45:45 -0500 Subject: How can I add encrypted comments Message-ID: <20210114214545.7B495805146@smtp.hushmail.com> vedaal at nym.hush.com vedaal at nym.hush.comwrote on Thu Jan 14 19:37:37 CET 2021: >but functionally, yes, it can be done.----- my mistake. Can't really be done this way :-((===== >[1] Armor the signature file ( gpg --armor filename.sig ) -----should be enarmor instead of armor :-( this outputs to filename.sig.asc [2[ Armor your encrypted comments, and copy them to the end of thefilename.sig.asc, (leave one blank line between the pgp footer of the signature file,and the pgp header of the encrypted file) [3] Save the whole thing as filename.sig.asc [4] gpg filename.sig,asc will automatically verify the sig if theoriginal signed file 'filename' is present, and also decrypt the addedcomments-----It doesn't.It gives weird error messages. sorry ;-( vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From angel at pgp.16bits.net Fri Jan 15 19:37:55 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 15 Jan 2021 19:37:55 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> Message-ID: On 2021-01-15 at 07:56 +0100, Stefan Claas via Gnupg-users wrote: > Don't you think when GitHub, a major player, would have an invalid > SSL cert, that maybe one of the millions programmers there would not > have contacted GitHub, like I did, and say hey GithHub you serve > the global community and visitors an invalid SSL certificate? I must > admit that I also do not understand what you mean with sus-sub > domains. My GitHub page is sac001.github.io and not foo.bar.github.io > or whatever. By sub-sub-domains we are all talking about pages such as https://openpgpkey.sac001.github.io or https://helloworld.sac001.github.io Go there, click those links. You will see that -*after forcing your browser to ignore the invalid certificate*- there is a web page there returning a message of "Site not found", "404 There isn't a GitHub Pages site here". *I* don't know why they have such domains resolving. It may have been simpler to configure the dns server that way, or perhaps they just missed it. The funny think is, I don't think there's a way to create a page in helloworld.sac001.github.io or openpgpkey.sac001.github.io, so these sites are mostly useless (if not directly problematic such as in WKD case), and I guess that's why noone really bothered about the invalid certificate for them (which isn't easy to solve, either). I don't know what process you used to contact GitHub support, but the question to ask would be precisely this: > Why is there something on https://openpgpkey.sac001.github.io ? How > can I modify it? If there is not, could you make it not to resolve? The reasons why it is picked has been, I think, explained already many times in this thread. Best regards From spam.trap.mailing.lists at gmail.com Fri Jan 15 20:34:21 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Fri, 15 Jan 2021 20:34:21 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> Message-ID: On Fri, Jan 15, 2021 at 7:39 PM ?ngel wrote: > > On 2021-01-15 at 07:56 +0100, Stefan Claas via Gnupg-users wrote: > > Don't you think when GitHub, a major player, would have an invalid > > SSL cert, that maybe one of the millions programmers there would not > > have contacted GitHub, like I did, and say hey GithHub you serve > > the global community and visitors an invalid SSL certificate? I must > > admit that I also do not understand what you mean with sus-sub > > domains. My GitHub page is sac001.github.io and not foo.bar.github.io > > or whatever. > > By sub-sub-domains we are all talking about pages such as > https://openpgpkey.sac001.github.io or https://helloworld.sac001.github.io > > Go there, click those links. You will see that -*after forcing your browser > to ignore the invalid certificate*- there is a web page there returning > a message of "Site not found", "404 There isn't a GitHub Pages site > here". > > *I* don't know why they have such domains resolving. It may have been > simpler to configure the dns server that way, or perhaps they just > missed it. The funny think is, I don't think there's a way to create a > page in helloworld.sac001.github.io or openpgpkey.sac001.github.io, so > these sites are mostly useless (if not directly problematic such as in > WKD case), and I guess that's why noone really bothered about the > invalid certificate for them (which isn't easy to solve, either). > > I don't know what process you used to contact GitHub support, but the > question to ask would be precisely this: > > Why is there something on https://openpgpkey.sac001.github.io ? How > > can I modify it? If there is not, could you make it not to resolve? > > > > The reasons why it is picked has been, I think, explained already many > times in this thread. In this whole thread here there have been made a lot arguments from all involved people, which is of course good! Non technically spoken (let us forget for a moment DNS, SSL, wildcards etc.) If you or someone else set's up a web server, for a big organisation or for yourself, you simple put in the .well-known folder some content which would look most likely then like this: http://domain.tld/.well-known/etc... or maybe https://sub.domain.tld/.well-known/etc... If someone writes now a program which needs to access content in the well-known folder, why does a software author needs to implement two methods to access the well-known folder? This part for example I do not understand, because if one method is not good or secure enough I would simply drop one method an implement only the more secure and more reliable one, or not? The situation we now have is that we have two popular OpenPGP apps which handle the access to the well-known openpgp directory differently, which nobody can deny. Let's assume the following GitHub and Werner would have a meeting and they would find no consensus. I for example can say I don't care about a draft and happily promote sequoia-pgp usage over GnuPG usage, in case OpenPGP users would like to use GitHub and WKD for a multi-purpose OpenPGP too. That would Werner and a couple of other probably pi*#-off very much but I do not have done something wrong and people are allowed to do the same. So in the end I personally think that It can't be wrong if Werner would discuss this and would act accordingly in a way that we all have a clear overview of his WKD project. I for example have found a WKD Golang library which, when noodling a bit around, I can customize to my hearts content for other crypto apps and then can present a WKD solution, based on the direct method for other non-OpenPGP software. Since this is all OpenSource and no commercial licensed software people have many options without following a draft ... My intention was only to promote WKD OpenPGP usage for github.io pages in case people like the idea. How did I contacted GitHub? I simply used their contact form filled in my request and received then a support ticket and at the end I was asked to fill out a customer survey, e.g quality etc. of the support I received. That is common with almost all U.S. based companies. Best regards Stefan From dkg at fifthhorseman.net Fri Jan 15 22:16:31 2021 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 15 Jan 2021 16:16:31 -0500 Subject: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages] In-Reply-To: References: <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> Message-ID: <87zh19j3yo.fsf@fifthhorseman.net> On Mon 2021-01-11 22:59:10 +0100, ?ngel wrote: > The "make a CNAME of your openpgpkeys subdomain to > wkd.keys.openpgp.org" couldn't work with https certificate validation, > thouth (or are they requesting a certificate on-the-fly?) In fact, i believe that keys.openpgp.org *is* requesting and retaining a certificate on-the-fly if it finds itself addressed by such a CNAME. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gnupg at raf.org Sat Jan 16 01:44:49 2021 From: gnupg at raf.org (raf) Date: Sat, 16 Jan 2021 11:44:49 +1100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> Message-ID: <20210116004449.ygwy62axauaynze6@raf.org> On Fri, Jan 15, 2021 at 07:56:16AM +0100, Stefan Claas wrote: > On Fri, Jan 15, 2021 at 2:04 AM raf via Gnupg-users > wrote: > > [...] > > > I'm really not an expert, and the above might not make > > any sense. I'm just thinking aloud. > > Me neither ... :-) For me, the questions I had is still unresolved > when it comes to properly explaing what security implication > it gives, when for example sequoia-pgp can handle this and > why the draft explicity says it MUST use the advanced-method > first. > > Don't you think when GitHub, a major player, would have an invalid > SSL cert, that maybe one of the millions programmers there would not > have contacted GitHub, like I did, and say hey GithHub you serve > the global community and visitors an invalid SSL certificate? I would. But that doesn't seem to have happened. I can only assume that github.io users aren't making much using sub-sub-domains of their sub-domains, or if they are, then they are not using TLS with those sub-sub-domains, so the invalid certificate isn't causing them any issues. Github could probably create valid wildcard certificates for sub-sub-domains (now that letsencrypt supports wildcard certificates), but it seems that they only have one certificate that covers their domains and sub-domains, but they then hand them out for sub-sub-domains as well. That is very odd behaviour on their part. They must know that that is an invalid use of their certificate. They are very clever people. > I must admit that I also do not understand what you > mean with sus-sub domains. It's sub-sub-domain, not sus-sub-domain. Sorry if I mistyped it. The "sub-domain" is the sub-domain of github.io, e.g.: sac001.github.io The "sub-sub-domain" is the sub-domain of a sub-domain, e.g.: openpgpkey.sac001.github.io Github's web server is handing out the same certificate for both your sub-domain and your sub-sub-domain, even though it is not valid for your sub-sub-domain. It is only valid for the following hostnames which includes your sub-domain (but not your sub-sub-domain): www.github.com *.github.com github.com *.github.io github.io *.githubusercontent.com githubusercontent.com You can see this for yourself in Firefox, by going to https://sac001.github.io/, clicking on the padlock, then clicking on the right "arrow" to the right of "Connection secure", then clicking on "More information". Github's web server should really just hand out this certificate for hostnames that are covered by it, but instead, they hand it out for sub-sub-domains that are not covered by it. The best solution would be for github, when handing out sub-domains, to register a letsencrypt wildcard certificate for that sub-domain's sub-sub-domains. In your sub-domain's case, such a certificate would cover: *.sac001.github.io. But there is no certificate that covers that sub-sub-domain. That's why browsers complain if you go to https://openpgpkey.sac001.github.io/. I think that letsencrypt didn't originally support wildcard certificates. That might have something to do with what github are doing. But they do support them now, so this could be fixed by github. But there might have to be a reasonable number of users asking for it, for that to happen. It would take some effort on github's part to fix this, and there's probably no money in it for them. > My GitHub page is sac001.github.io and not foo.bar.github.io > or whatever. Yes, but openpgpkey.sac001.github.io is a sub-sub-domain and it is instrumental in the advanced method. When a WKD client attempts to fetch a key for stefan at sac001.github.io, they try to resolve that sub-sub-domain, and the DNS resolution succeeds, and the webserver hands out a certificate for that domain which happens to be invalid. > If Werner had told me/us, hey look, according to my draft > the advanced method MUST been used because of this and that > security implication and it is not allowed in this case to fall back > if an (for WKD) invalid cert is present, because of this/that security > issue, I guess then I had a better understanding and then I guess > also the sequoia team would never had done it so that it works > with sequoia-pgp. I think that's exactly what this part of the draft is saying: 3.1. Key Discovery ... There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. Only if the required sub-domain does not exist, they SHOULD fall back to the direct method. It just doesn't include the background rationale for the algorithm in amongst the algorithm. That's probably discussed elsewhere. But I haven't read the draft. I'm just copying and pasting from an earlier message in this thread. Perhaps the rationale is in the draft or other related documents. I agree that, whenever instructing someone to do something, it's a great idea to explain why they need to do it, if only because it has been shown to dramatically increase acceptance of the instructions, but that has to be balanced against the readability of a document, and the needs of its intended audience. Writing is hard. It's very difficult for any single document to satisfy all the needs of all possible audiences. There have been 11 versions of the draft so far. I expect that if the rationale isn't in the draft itself, it has probably been discussed in IETF or GnuPG forums. > Regards > Stefan cheers, raf From gnupg at raf.org Sat Jan 16 01:59:21 2021 From: gnupg at raf.org (raf) Date: Sat, 16 Jan 2021 11:59:21 +1100 Subject: WKD proper behavior on fetch error In-Reply-To: <042345F0-7CA0-4D6B-BBB6-CE36B88EB66C@colomb.de> References: <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <042345F0-7CA0-4D6B-BBB6-CE36B88EB66C@colomb.de> Message-ID: <20210116005921.au523wgizerajeg2@raf.org> On Fri, Jan 15, 2021 at 07:56:26AM +0100, Andr? Colomb wrote: > Am 15. Januar 2021 01:56:04 MEZ schrieb raf via Gnupg-users : > >But of course, you're not asking for that. You're just > >asking for something to work. There must be other ways. > >Accepting invalid certificates might just have been my > >first thought at how to deal with this. But that would > >enable the advanced method to work (in situations where > >it shouldn't). If I remember correctly (possibly not), > >you wanted the direct method to work, and github.io's > >mis-configuration of certificates caused the advanced > >method to be attempted and fail, before the direct > >method could even be attempted. > > I'll try to complete your summary. The DNS wildcard entry for > *.example.github.io leads to the advanced method being tried. We can't > change that entry, and therefore with the current protocol draft, it > makes no sense forcefully wanting to use the direct method. > > It's easy to set up the advanced method there. But GitHub uses an > invalid TLS certificate for openpgpkey.example.github.io. That's what > needs fixing and it is also out of our control. > > So basically Stefan's request is to change the protocol to work around > a misconfiguration because both DNS and the TLS certificate are > controlled by a company that offers the service totally unrelated to > WKD. Such a workaround could hurt the ecosystem because it may hide a > misconfiguration in setups where the operator does have control over > these things and just needs to notice. That's why I thought maybe a skip list might be useful, rather than automatically failing over to the direct method in all cases where the advanced method is mis-configured in some way. The user-controlled skip list could be used in cases where the user knows that the server administrators aren't going to fix their system. I can totally understand a reluctance to add workarounds to other people's bugs into your own software. I've done that and wasn't happy about it. But I imagine that a skip list to avoid the advanced method for certain known-to-be-permanently-misconfigured domains is probably a minor instrusion into the code. But I'm just guessing. And for it to be of any use, github.io would have to be in the list by default, so that all users "benefit" from it without knowing in advance that they need it. Of course, if github.io ever do fix their TLS system, they would need to be removed from the skip list, which presumably wouldn't happen until they next upgrade gnupg. That would be a problem. Trying to be pragmatic in the face of other people's bugs can get tacky. Hmm, does github itself have a bug-tracking system? :-) > >OK. I just had a look at https://wiki.gnupg.org/WKD and > >it doesn't refer to "advanced" or "direct" methods. It > >seems to consider the "direct" method as the main > >method, and the "advanced" method as a "Stopgap method" > >which is "Not recommended - but a temporary > >workaround". So having an additional mechanism to > >disable the "advanced" method sounds reasonable. Or > >maybe the wiki page needs to be updated(?). > > Sorry, you just misread that part. The stopgap solution is to use a > server operated by openpgp.org instead of your own web server. For > that to work, you must set up the advanced method for WKD on your > domain's DNS. That method is perfectly fine and in some scenarios even > easier to use. Thanks for that. That makes more sense. I thought the advanced method sounded quite sensible. :-) > Kind regards > Andr? > > Hi raf, > > thanks for your perspective on the matter. > > -- > Greetings... > From: Andr? Colomb cheers, raf From spam.trap.mailing.lists at gmail.com Sat Jan 16 02:20:17 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 16 Jan 2021 02:20:17 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <20210116004449.ygwy62axauaynze6@raf.org> References: <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> Message-ID: On Sat, Jan 16, 2021 at 1:45 AM raf via Gnupg-users wrote: > But there is no certificate that covers that sub-sub-domain. > That's why browsers complain if you go to > https://openpgpkey.sac001.github.io/. A quick question, if you don't mind. Why do people here on this ML insist on a sub-sub domain, named openpgpkey? Have you ever maintained a web server? I am not using the html protokoll that much, but for me the openpgpkey part in, the for me fictious, URL, causes this error, because GnuPG or gpg4win is looking for this. I ask, because for me the proper URL would be: https://sac001.github.io/.well-kown/openpgpkey/etc.. And therefore I see absolutely no reason why GitHub or anybody else should change their valid SSL cert(s) or do elsewhere some mumbo jumbo, so to speak. And even if people had to set-up this extra steps for the advanced method than at least there is still some room for explaining while then using also the direct method, or not, because of the name 'advanced', which tells me it has higher priotity than direct. I must say good night now. Best regards Stefan From angel at pgp.16bits.net Sat Jan 16 02:25:14 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sat, 16 Jan 2021 02:25:14 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> Message-ID: On 2021-01-15 at 20:34 +0100, Stefan Claas via Gnupg-users wrote: > If you or someone else set's up a web server, for a big organisation > or for yourself, you simple put in the .well-known folder some > content which would look most likely then like this: > > http://domain.tld/.well-known/etc... or maybe > https://sub.domain.tld/.well-known/etc... Right. For instance, you would use either https://300baud.de/.well-known/... https://openpgpkey.300baud.de/.well-known/... > If someone writes now a program which needs to access content in the > well-known folder, why does a software author needs to implement two > methods to access the well-known folder? This part for example I do > not understand, because if one method is not good or secure enough I > would simply drop one method an implement only the more secure and > more reliable one, or not? Because the specification says that it can be in those two places. It could have stated only one, or a dozen. Or even, "start following links from the main index and stop after you find the first pgp key". > The situation we now have is that we have two popular OpenPGP apps > which handle the access to the well-known openpgp directory > differently, which nobody can deny. They differ *slightly*. Only if the first location exists but fails. But yes, they differ, as agreed by everyone. > I for example can say I don't care about a draft and happily promote > sequoia-pgp usage over GnuPG usage, in case OpenPGP users would like > to use GitHub and WKD for a multi-purpose OpenPGP too. That would > Werner and a couple of other probably pi*#-off very much but I do not > have done something wrong and people are allowed to do the same. Of course, you could. Or you could simply say: the pgp key of @.com shall be at https://www..com/.pub That would be following a completely different "standard", but it would be perfectly fine, too. The beauty of standards is to get everyone following the same rules and not a https://xkcd.com/927/ situation though. A standard allows people to know where to place their keys in a place it will be looked for, and the clients to know where they should look for them and how to act. > My intention was only to promote WKD OpenPGP usage for github.io > pages in case people like the idea. This was a good idea, but github pages don't seem to support being used for WKD (due to the mentioned wildcard issues). Best regards From spam.trap.mailing.lists at gmail.com Sat Jan 16 02:32:41 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 16 Jan 2021 02:32:41 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> Message-ID: On Sat, Jan 16, 2021 at 2:25 AM ?ngel wrote: > > On 2021-01-15 at 20:34 +0100, Stefan Claas via Gnupg-users wrote: > > If you or someone else set's up a web server, for a big organisation > > or for yourself, you simple put in the .well-known folder some > > content which would look most likely then like this: > > > > http://domain.tld/.well-known/etc... or maybe > > https://sub.domain.tld/.well-known/etc... > > > Right. For instance, you would use either > https://300baud.de/.well-known/... > https://openpgpkey.300baud.de/.well-known/... > > > > If someone writes now a program which needs to access content in the > > well-known folder, why does a software author needs to implement two > > methods to access the well-known folder? This part for example I do > > not understand, because if one method is not good or secure enough I > > would simply drop one method an implement only the more secure and > > more reliable one, or not? > > Because the specification says that it can be in those two places. Do I understand you correctly that if one uses now a subdomain like https://keys.300baud.de/.well-known/etc ... this would work and if so why does it not work with: https://sac001.github.io/.well-known/etc... I ask because in my set-up which I would use I would do so and then add in the SSL cert a subdomain wildcard entry to cover host a and host b and like explained I would put keys from all in the WKD directory of host keys. Best regards and Good Night Stefan From look at my.amazin.horse Sat Jan 16 03:26:24 2021 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sat, 16 Jan 2021 03:26:24 +0100 Subject: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages] In-Reply-To: <87zh19j3yo.fsf@fifthhorseman.net> References: <87zh19j3yo.fsf@fifthhorseman.net> <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> Message-ID: <22PR5S8SNSM88.2M6AH22DB7ZVK@my.amazin.horse> Daniel Kahn Gillmor via Gnupg-users wrote: > On Mon 2021-01-11 22:59:10 +0100, ?ngel wrote: > > The "make a CNAME of your openpgpkeys subdomain to > > wkd.keys.openpgp.org" couldn't work with https certificate validation, > > thouth (or are they requesting a certificate on-the-fly?) > > In fact, i believe that keys.openpgp.org *is* requesting and retaining a > certificate on-the-fly if it finds itself addressed by such a CNAME. Yep. If that wasn't possible, we wouldn't do it. btw, if anyone is interested: keys.o.o serves wkd for 224 domains right now. - V From juergen at bruckner.email Sat Jan 16 10:31:03 2021 From: juergen at bruckner.email (Juergen Bruckner) Date: Sat, 16 Jan 2021 10:31:03 +0100 Subject: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages] In-Reply-To: <22PR5S8SNSM88.2M6AH22DB7ZVK@my.amazin.horse> References: <87zh19j3yo.fsf@fifthhorseman.net> <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> <22PR5S8SNSM88.2M6AH22DB7ZVK@my.amazin.horse> Message-ID: Hello Group! Am 16.01.21 um 03:26 schrieb Vincent Breitmoser via Gnupg-users: > > Daniel Kahn Gillmor via Gnupg-users wrote: >> On Mon 2021-01-11 22:59:10 +0100, ?ngel wrote: >>> The "make a CNAME of your openpgpkeys subdomain to >>> wkd.keys.openpgp.org" couldn't work with https certificate validation, >>> thouth (or are they requesting a certificate on-the-fly?) >> >> In fact, i believe that keys.openpgp.org *is* requesting and retaining a >> certificate on-the-fly if it finds itself addressed by such a CNAME. > > Yep. If that wasn't possible, we wouldn't do it. > > btw, if anyone is interested: keys.o.o serves wkd for 224 domains right now. > > - V Now I'm a bit confused :O I thought WKD can be used with your own webserver. So why do I have to make a CNAME recort pointing to "wkd.keys.openpgp.org"? Or did I understand anything wrong? BTW ... do any of you know a tutorial to set up WKD for 'Dummies'? best regards Juergen -- /?\ No | \ / HTML | Juergen Bruckner X in | juergen at bruckner.email / \ Mail | -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From ayoubhm at gmail.com Sat Jan 16 00:43:57 2021 From: ayoubhm at gmail.com (Ayoub Misherghi) Date: Fri, 15 Jan 2021 15:43:57 -0800 Subject: Why is there a conflict? Message-ID: <4595775a-95c3-19ee-91f5-7e5d5f44e5e2@gmail.com> An HTML attachment was scrubbed... URL: From spam.trap.mailing.lists at gmail.com Sat Jan 16 11:57:12 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 16 Jan 2021 11:57:12 +0100 Subject: Why is there a conflict? In-Reply-To: <4595775a-95c3-19ee-91f5-7e5d5f44e5e2@gmail.com> References: <4595775a-95c3-19ee-91f5-7e5d5f44e5e2@gmail.com> Message-ID: On Sat, Jan 16, 2021 at 11:34 AM Ayoub Misherghi via Gnupg-users wrote: > > > The intention is to sign and encrypt "data.file" producing a detached signature file. > > > a at b:c$ gpg -s -e -b -r Mike data.file > > gpg: conflicting commands > > > Why is there a conflict? I do not want to produce an attached signature. You use -s and -b, try 'gpg -a -b -e file' Regards Stefan From spam.trap.mailing.lists at gmail.com Sat Jan 16 12:18:02 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 16 Jan 2021 12:18:02 +0100 Subject: Why is there a conflict? In-Reply-To: References: <4595775a-95c3-19ee-91f5-7e5d5f44e5e2@gmail.com> Message-ID: On Sat, Jan 16, 2021 at 11:57 AM Stefan Claas wrote: > > On Sat, Jan 16, 2021 at 11:34 AM Ayoub Misherghi via Gnupg-users > wrote: > > > > > > The intention is to sign and encrypt "data.file" producing a detached signature file. > > > > > > a at b:c$ gpg -s -e -b -r Mike data.file > > > > gpg: conflicting commands > > > > > > Why is there a conflict? I do not want to produce an attached signature. > > You use -s and -b, try 'gpg -a -b -e file' You can shorten this like: 'gpg -aber Mike data.file' (cool German word 'aber' :-) Regards Stefan From spam.trap.mailing.lists at gmail.com Sat Jan 16 12:52:08 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 16 Jan 2021 12:52:08 +0100 Subject: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages] In-Reply-To: References: <87zh19j3yo.fsf@fifthhorseman.net> <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> <22PR5S8SNSM88.2M6AH22DB7ZVK@my.amazin.horse> Message-ID: On Sat, Jan 16, 2021 at 10:32 AM Juergen Bruckner via Gnupg-users wrote: > > Hello Group! > BTW ... do any of you know a tutorial to set up WKD for 'Dummies'? Hi Juergen, me as a Windows DAU (D?mmster Anzunehmnder User) used the direct-method: Create in your web server's root directory the following: a folder named 'openpgpkey' put in that folder another folder named: 'hu'. in the openpgpkey folder put a policy file, named 'policy' it can be empty. in the hu folder put the binary blob of your pub key(s) to create the proper pub key do the following: gpg --list-keys --with-wkd-hash it will show you your pub keys data with an additional hash in order to export your pub key do the following: gpg --export your_pubkey >hash_as_filename put that binary blob of your pub key in your hu folder so that the filename shows the hash, without the @email part. then use Wiktor's WKD checker to check your result. If everything went well you can try to fetch your pub key with gpg --locate-keys juergen at email.address Hope this helps and please report back your results. Best regards Stefan From spam.trap.mailing.lists at gmail.com Sat Jan 16 12:55:43 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 16 Jan 2021 12:55:43 +0100 Subject: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages] In-Reply-To: References: <87zh19j3yo.fsf@fifthhorseman.net> <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> <22PR5S8SNSM88.2M6AH22DB7ZVK@my.amazin.horse> Message-ID: On Sat, Jan 16, 2021 at 12:52 PM Stefan Claas wrote: > > On Sat, Jan 16, 2021 at 10:32 AM Juergen Bruckner via Gnupg-users > wrote: > > > > Hello Group! > > > BTW ... do any of you know a tutorial to set up WKD for 'Dummies'? > > Hi Juergen, > > me as a Windows DAU (D?mmster Anzunehmnder User) used the direct-method: [EDIT] > Create in your web server's root directory the following: > a directory '.well-known' and in that > a folder named 'openpgpkey' put in that folder another folder named: 'hu'. Regards Stefan From spam.trap.mailing.lists at gmail.com Sat Jan 16 13:07:20 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 16 Jan 2021 13:07:20 +0100 Subject: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages] In-Reply-To: References: <87zh19j3yo.fsf@fifthhorseman.net> <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> <22PR5S8SNSM88.2M6AH22DB7ZVK@my.amazin.horse> Message-ID: On Sat, Jan 16, 2021 at 12:55 PM Stefan Claas wrote: > > On Sat, Jan 16, 2021 at 12:52 PM Stefan Claas > wrote: > > > > On Sat, Jan 16, 2021 at 10:32 AM Juergen Bruckner via Gnupg-users > > wrote: > > > > > > Hello Group! > > > > > BTW ... do any of you know a tutorial to set up WKD for 'Dummies'? > > > > Hi Juergen, > > > > me as a Windows DAU (D?mmster Anzunehmnder User) used the direct-method: > > [EDIT] > > > Create in your web server's root directory the following: > > a directory '.well-known' and in that > > a folder named 'openpgpkey' put in that folder another folder named: 'hu'. [EDITT #2] With root directory I mean where you have stored your html content which shows up when someone is visiting your site. Regards Stefan From bereska at hotmail.com Sat Jan 16 11:53:17 2021 From: bereska at hotmail.com (Dmitry Gudkov) Date: Sat, 16 Jan 2021 10:53:17 +0000 Subject: Why is there a conflict? In-Reply-To: <4595775a-95c3-19ee-91f5-7e5d5f44e5e2@gmail.com> References: <4595775a-95c3-19ee-91f5-7e5d5f44e5e2@gmail.com> Message-ID: Just get rid of -s On Jan 16, 2021 12:35, Ayoub Misherghi via Gnupg-users wrote: The intention is to sign and encrypt "data.file" producing a detached signature file. a at b:c$ gpg -s -e -b -r Mike data.file gpg: conflicting commands Why is there a conflict? I do not want to produce an attached signature. Ayoub -------------- next part -------------- An HTML attachment was scrubbed... URL: From look at my.amazin.horse Sat Jan 16 14:19:39 2021 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sat, 16 Jan 2021 14:19:39 +0100 Subject: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages] In-Reply-To: References: <87zh19j3yo.fsf@fifthhorseman.net> <1779013.kBCGB1XJgi@breq> <04be13a9c174dc05af31aaa3bfb4949c8547d4ad.camel@16bits.net> <10c8e9ecb989f4c3cf5a33aba251ca48a8d07e1d.camel@16bits.net> <22PR5S8SNSM88.2M6AH22DB7ZVK@my.amazin.horse> Message-ID: <33U4WKQHJMKRJ.1YZYBJ23DGI0G@my.amazin.horse> > Now I'm a bit confused :O > I thought WKD can be used with your own webserver. So why do I have to > make a CNAME recort pointing to "wkd.keys.openpgp.org"? > > Or did I understand anything wrong? Sorry, that was confusing without context. Yes, WKD is bound to the domain of the email address, and as such it will typically be hosted together with the email server itself, or at least by the same entity. Using the advanced WKD method, it's possible to "outsource" hosting using a CNAME, and keys.o.o will do the rest: https://keys.openpgp.org/about/usage#wkd-as-a-service But this is only a shortcut for convenience. WKD works best when it is run decentralized by the email hosters themselves. - V From angel at pgp.16bits.net Sat Jan 16 23:06:27 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sat, 16 Jan 2021 23:06:27 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> Message-ID: <90edf3fa68ee9d1ac39e6691c375ddb45f8efa96.camel@16bits.net> On 2021-01-16 at 02:32 +0100, Stefan Claas via Gnupg-users wrote: > Do I understand you correctly that if one uses now a subdomain > like https://keys.300baud.de/.well-known/etc ... this would work No. keys.300baud.de would work only for email at keys.300baud.de However, for email at 300baud.de, you can use openpgpkey.300baud.de > and if so why does it not work with: > https://sac001.github.io/.well-known/etc... Because there is a https://openpgpkey.300baud.de which higher priority (and a certificate error, etc, etc) > I ask because in my set-up which I would use I would do so > and then add in the SSL cert a subdomain wildcard entry > to cover host a and host b and like explained I would > put keys from all in the WKD directory of host keys. You don't need a wildcard entry. You could simply request a certificate with the right name that will be needed. From angel at pgp.16bits.net Sat Jan 16 23:22:29 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sat, 16 Jan 2021 23:22:29 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> Message-ID: On 2021-01-16 at 02:20 +0100, Stefan Claas wrote: > On Sat, Jan 16, 2021 at 1:45 AM raf wrote: > > > But there is no certificate that covers that sub-sub-domain. > > That's why browsers complain if you go to > > https://openpgpkey.sac001.github.io/. > > A quick question, if you don't mind. Why do people here on this ML > insist on a sub-sub domain, named openpgpkey? Have you > ever maintained a web server? I am not using the html protokoll > that much, but for me the openpgpkey part in, the for me fictious, > URL, causes this error, because GnuPG or gpg4win is looking for this. Because that's what the specification says. It's like you wanted to visit "google.com" and your browser said: "Ok, I will see if www.google.com exists and if so, show you https://www.google.com (not https://google.com), but if there is no www. subdomain I will try showing https://google.com directly"? sequoia also goes to the openpgpkey.domain.tld url first. The difference with gnupg is in their treatment of errors. ? NB: this is a fictitious example. While browsers do have some heuristics if the provided domain fails, like prepending a "www." or making a web search, I know of no browser doing that *before* . Using a www. for web addresses is just a convention. Although we could have ended in this situation if things had developed slightly different. From gnupg at raf.org Sun Jan 17 00:06:20 2021 From: gnupg at raf.org (raf) Date: Sun, 17 Jan 2021 10:06:20 +1100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> Message-ID: <20210116230620.vothqvj5frusxbpd@raf.org> On Sat, Jan 16, 2021 at 02:20:17AM +0100, Stefan Claas wrote: > On Sat, Jan 16, 2021 at 1:45 AM raf via Gnupg-users > wrote: > > > But there is no certificate that covers that sub-sub-domain. > > That's why browsers complain if you go to > > https://openpgpkey.sac001.github.io/. > > A quick question, if you don't mind. Why do people here on this ML > insist on a sub-sub domain, named openpgpkey? Because that's how WKD is defined to work. > Have you ever maintained a web server? Yes (but that's not really relevant). > I am not using the html protokoll that much, but for me the openpgpkey > part in, the for me fictious, URL, causes this error, because GnuPG or > gpg4win is looking for this. It's not fictitious. WKD client try to resolve it (i.e. look it up via the DNS protocol), and github's DNS servers successfully return several IP addresses for it. Therefore, as far as github, the owner of the domain, is concerned, it is real and therefore not fictitious. > I ask, because for me the proper URL would be: > > https://sac001.github.io/.well-kown/openpgpkey/etc.. What you refer to as "proper" is just the direct method. That's only half of the WKD protocol. There is also the advanced method. Both methods together comprise the WKD protocol. > And therefore I see absolutely no reason why GitHub or anybody > else should change their valid SSL cert(s) or do elsewhere some > mumbo jumbo, so to speak. If their SSL cert were valid for your sub-sub-domain, there would be no reason to change, but as has been pointed out many many times, their certificate is only valid for the domains that it is valid for. It is not valid for anything else, and the domain openpgpkey.sac001.github.com is one of the domains for which github's certificate is not valid. If this seems like mumbo jumbo to you, please accept that it really isn't. It's just that you aren't familiar enough with all of the protocols involved. And if that's the case, you can't with any confidence assert that github's certificate is valid (for anything other than the domains that are bound to the certificate). > And even if people had to set-up this extra steps for the advanced > method than at least there is still some room for explaining while > then using also the direct method, or not, because of the name > 'advanced', which tells me it has higher priotity than direct. It has been explained a few times already. But if the explanations aren't making sense, perhaps you need more background information in order to understand the explanations that have been given. Perhaps you could read up on DNS and TLS and WKD. I'd recommend the O'Reilly books on Bind and OpenSSL. There are probably free online resources but those books are good. But maybe I just like books for learning big new subjects. And also the WKD draft, of course. Sorry to suggest a pile of reading material, but I can't think of a better way to learn the relevant topics. > I must say good night now. > > Best regards > Stefan cheers, raf From spam.trap.mailing.lists at gmail.com Sun Jan 17 00:08:27 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 00:08:27 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <90edf3fa68ee9d1ac39e6691c375ddb45f8efa96.camel@16bits.net> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <90edf3fa68ee9d1ac39e6691c375ddb45f8efa96.camel@16bits.net> Message-ID: On Sat, Jan 16, 2021 at 11:07 PM ?ngel wrote: > You don't need a wildcard entry. You could simply request a certificate > with the right name that will be needed. Yes, for me as little nobody that is correct. But I guess we should not forget the real host masters dealing with a couple (of growing) more hosts under sub-domains and for ease of use with management of these. That is the reason IMHO why a giant like GitHub is using wildcard subdomains and like I said in my bund.de example etc. this would be IMHO a valid reason too if they figure out, hey WKD is pretty cool for an inhouse key distribution management. Best regards Stefan From spam.trap.mailing.lists at gmail.com Sun Jan 17 00:28:31 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 00:28:31 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <20210116230620.vothqvj5frusxbpd@raf.org> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> Message-ID: On Sun, Jan 17, 2021 at 12:09 AM raf via Gnupg-users wrote: > > On Sat, Jan 16, 2021 at 02:20:17AM +0100, Stefan Claas wrote: > > > On Sat, Jan 16, 2021 at 1:45 AM raf via Gnupg-users > > wrote: > > > > > But there is no certificate that covers that sub-sub-domain. > > > That's why browsers complain if you go to > > > https://openpgpkey.sac001.github.io/. > > > > A quick question, if you don't mind. Why do people here on this ML > > insist on a sub-sub domain, named openpgpkey? > > Because that's how WKD is defined to work. > > > Have you ever maintained a web server? > > Yes (but that's not really relevant). > > > I am not using the html protokoll that much, but for me the openpgpkey > > part in, the for me fictious, URL, causes this error, because GnuPG or > > gpg4win is looking for this. > > It's not fictitious. WKD client try to resolve it (i.e. > look it up via the DNS protocol), and github's DNS > servers successfully return several IP addresses for it. > Therefore, as far as github, the owner of the domain, is > concerned, it is real and therefore not fictitious. > > > I ask, because for me the proper URL would be: > > > > https://sac001.github.io/.well-kown/openpgpkey/etc.. > > What you refer to as "proper" is just the direct method. > That's only half of the WKD protocol. There is also the > advanced method. Both methods together comprise the WKD > protocol. And in the case of GnuPG and gpg4win it does not work like one would expect, if the direct method is part of the protocol, because it will not be triggered if an error occurs with the advanced method. > > > And therefore I see absolutely no reason why GitHub or anybody > > else should change their valid SSL cert(s) or do elsewhere some > > mumbo jumbo, so to speak. > > If their SSL cert were valid for your sub-sub-domain, > there would be no reason to change, but as has been > pointed out many many times, their certificate is only > valid for the domains that it is valid for. It is not > valid for anything else, and the domain > openpgpkey.sac001.github.com is one of the domains for > which github's certificate is not valid. And that is correct and as we all have seen GnuPG and gpg4win are not falling back to the valid direct method, while sequoia-pgp does and gives satisfactory results. That simple... :-) > > If this seems like mumbo jumbo to you, please accept > that it really isn't. It's just that you aren't > familiar enough with all of the protocols involved. And > if that's the case, you can't with any confidence > assert that github's certificate is valid (for anything > other than the domains that are bound to the > certificate). You know what I like in the whole discussion most ,that people always assume, when trying to convince me, that like you say, that I am not familiar enough with this and that and when I counter argument that I do not yet have received here a simple answer, for all laymens here reading, why can GnuPG or gpg4win not fallback or test the availabilty of the direct-method? I thing it is a quite simple question and nor Werner or anybody else can, so it seems, answer this. The only satisfactory and honest answer came only from Neal so far, explaining why it properly works with sequoia-pgp. > > And even if people had to set-up this extra steps for the advanced > > method than at least there is still some room for explaining while > > then using also the direct method, or not, because of the name > > 'advanced', which tells me it has higher priotity than direct. > > It has been explained a few times already. But if the > explanations aren't making sense, perhaps you need more > background information in order to understand the > explanations that have been given. Perhaps you could > read up on DNS and TLS and WKD. I'd recommend the > O'Reilly books on Bind and OpenSSL. There are probably > free online resources but those books are good. But > maybe I just like books for learning big new subjects. > And also the WKD draft, of course. Sorry to suggest a > pile of reading material, but I can't think of a better > way to learn the relevant topics. You can assume what ever you like and try to convince me, but sorry to say this, fact is sequoia-pgp works and GnuPG and gpg4win does not. My advise would be that Werner thinks of proper wildcard subdomain support, like my Github case and as already suggested (as I have seen now) to give WKD users are *clear* picture. P.S. I have no problems to discuss here with everybody this thread more, even if it is getting now a bit boring for me. I do accept however mistakes I publicity make or have made here, but at least the interested reader gets a good overview how things 'work' in the GnuPG ecosystem, if you understand what I mean ... Best regards Stefan From spam.trap.mailing.lists at gmail.com Sun Jan 17 00:33:05 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 00:33:05 +0100 Subject: Why is there a conflict? In-Reply-To: <7c614ce2-ff41-c7d8-d0a7-9875beea29c6@gmail.com> References: <4595775a-95c3-19ee-91f5-7e5d5f44e5e2@gmail.com> <7c614ce2-ff41-c7d8-d0a7-9875beea29c6@gmail.com> Message-ID: On Sun, Jan 17, 2021 at 12:10 AM Ayoub Misherghi wrote: > > > On 1/16/2021 3:18 AM, Stefan Claas wrote: > > On Sat, Jan 16, 2021 at 11:57 AM Stefan Claas > wrote: > > On Sat, Jan 16, 2021 at 11:34 AM Ayoub Misherghi via Gnupg-users > wrote: > > The intention is to sign and encrypt "data.file" producing a detached signature file. > > > a at b:c$ gpg -s -e -b -r Mike data.file > > gpg: conflicting commands > > > Why is there a conflict? I do not want to produce an attached signature. > > You use -s and -b, try 'gpg -a -b -e file' > > You can shorten this like: 'gpg -aber Mike data.file' (cool German > word 'aber' :-) > > Regards > Stefan > > gpg -aber data.file > > produced "data.file.asc" and no "data.file.sig" > > > Danke, Gern geschehen (you're welcome)! Try to omit the 'a' and see if you then get the .sig file. (I am a bit out of the loop regarding gpg) Regards Stefan From gnupg at raf.org Sun Jan 17 04:50:45 2021 From: gnupg at raf.org (raf) Date: Sun, 17 Jan 2021 14:50:45 +1100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> Message-ID: <20210117035045.ozi2waa54ktjj7yh@raf.org> On Sat, Jan 16, 2021 at 02:25:14AM +0100, ?ngel wrote: > On 2021-01-15 at 20:34 +0100, Stefan Claas via Gnupg-users wrote: > > My intention was only to promote WKD OpenPGP usage for github.io > > pages in case people like the idea. > > This was a good idea, but github pages don't seem to support being used > for WKD (due to the mentioned wildcard issues). Is it a good idea, though? I'm not sure that many people would want to change their email addresses so as to end in @something.github.io just so that they could then use WKD with github.io. How would that even work? For example, sac001.github.io doesn't have an MX record, so email can't be sent to any address with that as the domain. Github doesn't support adding MX records for sub-domains to their DNS servers. Even if they did, you'd still need to set up an email server wherever the MX record points to anyway. github.io is for setting up web pages, not email addresses or email accounts. I must be missing something, but I can't see how a github.io email address can be connected to an actual email server or email account, so I can't see how WKD could be used in connection with github.io email addresses. The problem isn't just github doing DNS wildcarding without the corresponding valid TLS wildcarding, combined with gnupg not failing over to the direct method when the advanced method fails. The problem is that WKD is a protocol for automatically and reliably mapping an email address to its corresponding public key, and github.io doesn't support email addresses or email accounts. While gnupg's behaviour could be changed (in one or two different ways) to workaround github.io's mis-configuration (assuming there are no adverse security or maintenance implications in doing so), would that actually solve this problem? I don't think it would. It wouldn't make github.io email addresses suddenly become possible. The only way I can see for this to work at all, is if all WKD clients were also changed so as to be able to use one fake "email address", solely for the purpose of obtaining a public key (that is stored on github.io), but then using that key to encrypt emails to a completely different real email address (that has nothing to do with github.io). That seems to contradict the rationale for WKD, which is to have a way of automatically finding the key that you know really belongs to whoever owns the email address that emails are being encrypted to. The above change doesn't sound any better than the pre-WKD situation of looking up a key from an arbitrary key server and hoping that it's the right one. Section 3 of the WKD draft outlines the rationale: https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-11 I know that sequoia does failover to the direct method when the advanced method fails, but their stated reason for doing that wasn't related to github.io. So it seems that there are use cases where failing over to the direct method can be helpful, but I don't see how it can help with github.io specifically. But that could be due to my ignorance of something important, or just a lack of imagination. :-) But a bit of googling seems to confirm my thinking. https://webmasters.stackexchange.com/questions/127564/how-to-setup-domain-email-for-a-site-that-uses-github-pages https://www.breck-mckye.com/blog/2020/05/Setting-up-a-static-site-and-personal-email-without-paying-for-hosting/ Both of these links seem to indicate that combining email and github.io requires a separate domain that you control, where github.io only provides the web hosting. It doesn't provide the email address. If you have a domain that you control, you can easily avoid the advanced method by not implementing it. But I think avoiding having to pay for things like a domain was part of the rationale for this WKD+github.io proposal. cheers, raf From spam.trap.mailing.lists at gmail.com Sun Jan 17 09:14:37 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 09:14:37 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <20210117035045.ozi2waa54ktjj7yh@raf.org> References: <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210117035045.ozi2waa54ktjj7yh@raf.org> Message-ID: On Sun, Jan 17, 2021 at 4:52 AM raf via Gnupg-users wrote: > > On Sat, Jan 16, 2021 at 02:25:14AM +0100, ?ngel wrote: > > > On 2021-01-15 at 20:34 +0100, Stefan Claas via Gnupg-users wrote: > > > My intention was only to promote WKD OpenPGP usage for github.io > > > pages in case people like the idea. > > > > This was a good idea, but github pages don't seem to support being used > > for WKD (due to the mentioned wildcard issues). > > Is it a good idea, though? I'm not sure that many > people would want to change their email addresses so as > to end in @something.github.io just so that they could > then use WKD with github.io. How would that even work? > But that could be due to my ignorance of something > important, or just a lack of imagination. :-) > But a bit of googling seems to confirm my thinking. I am not sure if you followed the whole thread but I used the term multi-purpose usage key, for users like to going this route. GitHub, for example, gives users the ability to host an own web page so that users do not need to sign up for paid services in order to create rich-content static web pages. If you would visit my GitHub account at: https://github.com/sac001/ you would see that if you had a GitHub account as well that you would see one of my email addresses where I can be reached. Regarding a multi-purpose key and WKD. I mentioned here already that a multi-purpose usage key can be used for other tasks as well, besides popular email. Remember only my old thread where I asked for some volunteers in the EU, which allows them in their country to more securely than email and also more decentralized than email to communicate. I also mentioned in another thread Bitmessage, which does not have an email address and works as p2p global Network like a modern and privacy friendly replacement for email. If you only see, let's say as an email user only, the usage of OpenPGP software for strict email usage only, then you may have a limited horizon, for public key cryptography, if you allow me to say this. WKD, as nobody can deny could be IMHO a fantastic way for decentralized key distribution, managed under the users own control, if it would be a bit more flexible in the implementation of GnuPG and gpg4win. That this may not be a cup of tea for MUA only users I can understand, but it does not hurt them in any way when they communicate the email way with their friends they always do. The more options OpenPGP users have the better. Last but not least if I had here proposed something that would endager OpenPGP users in a way that I can not see you can be sure that I would not have started this thread. Regards Stefan From gnupg at eckner.net Sun Jan 17 10:48:17 2021 From: gnupg at eckner.net (Erich Eckner) Date: Sun, 17 Jan 2021 10:48:17 +0100 (CET) Subject: WKD proper behavior on fetch error In-Reply-To: <87pn27hbx1.fsf@wheatstone.g10code.de> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87pn27hbx1.fsf@wheatstone.g10code.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, On Thu, 14 Jan 2021, Werner Koch via Gnupg-users wrote: > On Thu, 14 Jan 2021 01:47, ?ngel said: > >> I understand this to mean it as "only use the direct method if the >> required sub-domain does not exist", with the SHOULD meaning that the >> direct method is not required (not sure why, I would have probably used > > Right. The subdomain is actually a workaround for SRV RR. We can't > use the latter in browser based implementation and thus need to resort > to this hack. Forgive my ignorance, but can someone explain, what "browser based implementation" of WKD exists (or might exist) and/or why this is desirable? Shouldn't the WKD draft rather give the WKD implementation the responsibility to use a proper dns client library? I assume other protocols (which allow SRV records to redirect requests) do this (xmpp, irc, ...)? regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAEB+IACgkQCu7JB1Xa e1oQwg/9FXVLP3RCDVsSERDwF1LV/nDx9xRJZSWixyxG+v5huW/jxT1C4xdJ4M8P 6dB/4I1CQSNd4c9/MflG3wOjKR+lA1RmtiXYX2ocK2armjNf0nHoFNCqlDs87AdI kQUm9YBwPsNeSmzZb1DnbV0oU2y0Yv7EcxJygByR7G1WSPjnxyiwXtuu5e6Lpw96 06kyEf0+jyg7x7mn0F3FseQCyBwC9pYbm57Irm+KpCAoLVtPenWdq87R1Ypp4Ez4 nJyrzaC/h2MVXGHZcGb5fBqBYJAKgY9pIQOJ005NLiPW4K2o7mrPOT/DGNOvom8H +NjtoMKY+Iypp5OOd1juYk/p5yan65H9WWqaiLLhORd+1WENffpHwkClJqCr1Nj4 zxcyxUIuhe8EIWLqmPGW4h/40KmDzJJiFNTASV5ZlI6l2cZPeRLOLbre/yyBvRtB EiF5lMV2iytepRntblEmFT4CVPdGNYchY8Um5PklGWp59n3zCvJ0hJyhqPwBTKNL 4WFG/raUgdTkQJZlAi+NLGt3oFzycKPqBkaXn5ArYgmgTsUKNqUp8+5OxStbKyG2 9ZEFwzrkpuK1LtuW8xf9RIlqhfnS0IuGkgKE/ZPZl3hI+sT30Isv++4PyNeNFQ9C 64LWYkEEgPNUB70Gv+PFjKku9fv8YIROiFkXJqZ/Iq7a5ngd/48= =xq9S -----END PGP SIGNATURE----- From spam.trap.mailing.lists at gmail.com Sun Jan 17 11:18:28 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 11:18:28 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87pn27hbx1.fsf@wheatstone.g10code.de> Message-ID: On Sun, Jan 17, 2021 at 10:51 AM Erich Eckner via Gnupg-users wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi all, > > On Thu, 14 Jan 2021, Werner Koch via Gnupg-users wrote: > > > On Thu, 14 Jan 2021 01:47, ?ngel said: > > > >> I understand this to mean it as "only use the direct method if the > >> required sub-domain does not exist", with the SHOULD meaning that the > >> direct method is not required (not sure why, I would have probably used > > > > Right. The subdomain is actually a workaround for SRV RR. We can't > > use the latter in browser based implementation and thus need to resort > > to this hack. > > Forgive my ignorance, but can someone explain, what "browser based > implementation" of WKD exists (or might exist) and/or why this is > desirable? Well, Mailvelope, for example is a Browser based add-on with WKD support. Mailvelope can be used with services like Gmail, so that you don't need a MUA. There is also now a competing product for Mailvelope, from IIRC, the United States, which I have forgot. Desireable, well, flexibilty so to speak, if you read my previous reply to raf. BTW. WKD *Web* Key Directory for *Web* pages ... ;-) Regards Stefan From spam.trap.mailing.lists at gmail.com Sun Jan 17 11:37:35 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 11:37:35 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87pn27hbx1.fsf@wheatstone.g10code.de> Message-ID: On Sun, Jan 17, 2021 at 11:18 AM Stefan Claas wrote: > Well, Mailvelope, for example is a Browser based add-on with WKD support. > Mailvelope can be used with services like Gmail, so that you don't need a MUA. > > There is also now a competing product for Mailvelope, from IIRC, the > United States, > which I have forgot. > > Desireable, well, flexibilty so to speak, if you read my previous reply to raf. > > BTW. WKD *Web* Key Directory for *Web* pages ... ;-) I just did a quick test and downloaded Firefox and installed Mailvelope, created a test key pair with with a fictious email address and no Web Mail Provider configured and WKD with Mailvelope and GitHub works, same as sequoia-pgp. Quite superb and super easy to use. https://ibb.co/Zm21wzk P.S. Mailvelope is also supported by our BSI and audited. Regards Stefan From gnupg at eckner.net Sun Jan 17 12:30:05 2021 From: gnupg at eckner.net (Erich Eckner) Date: Sun, 17 Jan 2021 12:30:05 +0100 (CET) Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87pn27hbx1.fsf@wheatstone.g10code.de> Message-ID: <9dac67d4-78d3-9782-ca3e-443630b5a668@eckner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sun, 17 Jan 2021, Stefan Claas wrote: > On Sun, Jan 17, 2021 at 10:51 AM Erich Eckner via Gnupg-users > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Hi all, >> >> On Thu, 14 Jan 2021, Werner Koch via Gnupg-users wrote: >> >>> On Thu, 14 Jan 2021 01:47, ?ngel said: >>> >>>> I understand this to mean it as "only use the direct method if the >>>> required sub-domain does not exist", with the SHOULD meaning that the >>>> direct method is not required (not sure why, I would have probably used >>> >>> Right. The subdomain is actually a workaround for SRV RR. We can't >>> use the latter in browser based implementation and thus need to resort >>> to this hack. >> >> Forgive my ignorance, but can someone explain, what "browser based >> implementation" of WKD exists (or might exist) and/or why this is >> desirable? > > Well, Mailvelope, for example is a Browser based add-on with WKD support. > Mailvelope can be used with services like Gmail, so that you don't need a MUA. Ah, I see. That makes sense: integrate the keyring (and thus also a WKD client) into the webmailer. OTOH: How do web-chat clients request SRV records? Or do they simply not work with servers, who offer their connection information via SRV? regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAEH74ACgkQCu7JB1Xa e1qa4g/+IJxZDT0FpGVNCog2kXCmEJvouqxxnFrhVv62Xy3ycbOBQ8FAmOz1+3+9 NRPtonFVRBEQBk5Dd+tozIYIPC1pOLRCQPkuPr9CZ9Z+XcPWLyEtjV2FHESsWNHE w2yI3aWfa1jpLymXNVWVpi0fmXzFS4dSsz3EU4lGWuwLbbFrBa9eg/2WEo9n15Ec pdY2QBfAYEnzi8F9vnrkHlMDYb6uoaEbEkv4lDYIBUOocDYeLVLQaXyp4hZ154MU qUnabQD1w9ZRhFFXz9k661Nbf8lp8xfodrqEB3FSaHoES16tlN7j18/O2a933exA nRrdOzqGrRBJDa6UOp6HuxAZJ2bQtoDhSpOOihDC8ncAeox0Uw3dDb22FV7wDXNJ FVaIf/ISpCDO+5H09HaNxro0Qwa/En8X1h4H7XrtfETGwgkvyPaO/zqoILGgSQsb jCMSaDT1XUP++mtF+DR6RruizB29BkxiRMBo3cDrc4jE632MNq2sbFVWbpic3RZn 7L6OIsKWC1StmHWD1CLMgVULMBwTDveeCFEbsUpSvMCaCyyMGL2wAU4z+i2252JW +pz4JP0cFT1YMDeBOj1VysTrCTkUzQwa//a3JooO9PolsVvHYhuPTfPAu2UMn4u1 RbakTh/2ELZKxB6VcpkmbpNYLnA+M6+u1+HiDnNOQOq4sd65qmY= =oQdC -----END PGP SIGNATURE----- From spam.trap.mailing.lists at gmail.com Sun Jan 17 12:34:06 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 12:34:06 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <9dac67d4-78d3-9782-ca3e-443630b5a668@eckner.net> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87pn27hbx1.fsf@wheatstone.g10code.de> <9dac67d4-78d3-9782-ca3e-443630b5a668@eckner.net> Message-ID: On Sun, Jan 17, 2021 at 12:33 PM Erich Eckner via Gnupg-users wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Sun, 17 Jan 2021, Stefan Claas wrote: > > > On Sun, Jan 17, 2021 at 10:51 AM Erich Eckner via Gnupg-users > > wrote: > >> > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA256 > >> > >> Hi all, > >> > >> On Thu, 14 Jan 2021, Werner Koch via Gnupg-users wrote: > >> > >>> On Thu, 14 Jan 2021 01:47, ?ngel said: > >>> > >>>> I understand this to mean it as "only use the direct method if the > >>>> required sub-domain does not exist", with the SHOULD meaning that the > >>>> direct method is not required (not sure why, I would have probably used > >>> > >>> Right. The subdomain is actually a workaround for SRV RR. We can't > >>> use the latter in browser based implementation and thus need to resort > >>> to this hack. > >> > >> Forgive my ignorance, but can someone explain, what "browser based > >> implementation" of WKD exists (or might exist) and/or why this is > >> desirable? > > > > Well, Mailvelope, for example is a Browser based add-on with WKD support. > > Mailvelope can be used with services like Gmail, so that you don't need a MUA. > > Ah, I see. That makes sense: integrate the keyring (and thus also a WKD > client) into the webmailer. OTOH: How do web-chat clients request SRV > records? Or do they simply not work with servers, who offer their > connection information via SRV? Oh, sorry I do not use chat clients and I am not familiar how they do it. Regards Stefan From angel at pgp.16bits.net Sun Jan 17 14:47:19 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 17 Jan 2021 14:47:19 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87pn27hbx1.fsf@wheatstone.g10code.de> Message-ID: On 2021-01-17 at 10:48 +0100, Erich Eckner wrote: > Hi all, > > On Thu, 14 Jan 2021, Werner Koch via Gnupg-users wrote: > > > On Thu, 14 Jan 2021 01:47, ?ngel said: > > > >> I understand this to mean it as "only use the direct method if the > >> required sub-domain does not exist", with the SHOULD meaning that the > >> direct method is not required (not sure why, I would have probably used > > > > Right. The subdomain is actually a workaround for SRV RR. We can't > > use the latter in browser based implementation and thus need to resort > > to this hack. > > Forgive my ignorance, but can someone explain, what "browser based > implementation" of WKD exists (or might exist) and/or why this is > desirable? > > Shouldn't the WKD draft rather give the WKD implementation the > responsibility to use a proper dns client library? I assume other > protocols (which allow SRV records to redirect requests) do this > (xmpp, > irc, ...)? > > regards, Erich Hi Erich I think that would be an implementation such as https://encrypt.to/ or a wemail that wanted to only source openpgp.js, without needing to set up a server-side gateway to resolve SRV records. Best, ?ngel From angel at pgp.16bits.net Sun Jan 17 15:46:28 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 17 Jan 2021 15:46:28 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> Message-ID: <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> On 2021-01-17 at 00:28 +0100, Stefan Claas wrote: > On Sun, Jan 17, 2021 at 12:09 AM raf wrote: > > What you refer to as "proper" is just the direct method. > > That's only half of the WKD protocol. There is also the > > advanced method. Both methods together comprise the WKD > > protocol. > > And in the case of GnuPG and gpg4win it does not work > like one would expect, if the direct method is part of the > protocol, because it will not be triggered if an error occurs > with the advanced method. It is part of the protocol, under certain rules: > Only if the required sub-domain does not exist, they SHOULD > fall back to the direct method. (from section 3.1) The sub-domain exists, and thus gnupg does not fall back to the direct method. I guess most people (still) reading this thread to be somewhat familiar with their local driving regulation (however that is called). Let's suppose we were all building autonomous cars, intended to be driven? in San Serriffe, where the law stated: > When approaching a road intersection, the driver? must first > determine if there is a traffic light, in which case they are allowed > to cross it if it is Green. Else, they should verify if there is a > zebra crossing, and can go through if there is no pedestrian on it. The current discussion is analogous to having a car approaching an intersection where there is a red traffic light lit and a zebra crossing with no people. One brand of car sees the red light and stops. The other falls back to looking at the zebra crossing and goes through. > You know what I like in the whole discussion most ,that people > always assume, when trying to convince me, that like > you say, that I am not familiar enough with this and > that and when I counter argument that I do not yet have received > here a simple answer, for all laymens here reading, why > can GnuPG or gpg4win not fallback or test the availabilty > of the direct-method? I thing it is a quite simple question > and nor Werner or anybody else can, so it seems, answer > this. The only satisfactory and honest answer came only > from Neal so far, explaining why it properly works with > sequoia-pgp. GnuPG (gpg4win is just including GnuPG) see that the advanced method is available, so why should they fall back to the direct method? Of course, the code *could* be changed to do that, but there should be a reason. Similarly, some San Seriffe car owners could argue that if a pedestrian crosses the road not on a zebra crossing, the proper action by their car was to run over them. The car manufacturers may still prefer not to do that. ? Or may be just "observed while it drives itself" ? Usually human, but the car in this case > You can assume what ever you like and try to convince me, > but sorry to say this, fact is sequoia-pgp works and GnuPG > and gpg4win does not. That highly depends on what you consider to be "working". You have a certificate error on https://yourbank.de. Browser A simply shows an error to the user. Browser B automatically goes to http://yourbank.de, letting the user perform their banking there. Which browser "works"? > My advise would be that Werner thinks of proper wildcard > subdomain support, like my Github case and as already > suggested (as I have seen now) to give WKD users are > *clear* picture. There is no "wildcard subdomain support" issue for TLS certificates. Both GnuPG and sequoia agree that the certificate presented by github.io for the advanced method is invalid. If you mean for wildcard DNS subdomains, that was already taken into account months ago in the draft, it even hints at how domain owners can avoid this issue: > Sites which do not use the advanced method but employ wildcard DNS > for their sub-domains MUST make sure that the "openpgpkey" sub-domain > is not subject to the wildcarding. This can be done by inserting an > empty TXT RR for this sub-domain. Best regards From spam.trap.mailing.lists at gmail.com Sun Jan 17 16:28:37 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 16:28:37 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> Message-ID: On Sun, Jan 17, 2021 at 3:49 PM ?ngel wrote: [...] sorry, but simply said I discovered now that a second major and trusted contender, Mailvelope supported by BSI and audited, works also as sequoia-pgp does. Werner and his (shrinking in numbers) supporters should think now what do to, instead of defending something, that could be improved. Try to see it this way, It does not hurt, I promise! :-) I will try to find the US competitor for Mailvelope and test this as well. P.S. Juergen, had been nice if you had posted your results with the direct method. Best regards Stefan From spam.trap.mailing.lists at gmail.com Sun Jan 17 17:05:05 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 17:05:05 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> Message-ID: On Sun, Jan 17, 2021 at 4:28 PM Stefan Claas wrote: > > On Sun, Jan 17, 2021 at 3:49 PM ?ngel wrote: > > [...] > > sorry, but simply said I discovered now that a second major and trusted > contender, Mailvelope supported by BSI and audited, works also as > sequoia-pgp does. Werner and his (shrinking in numbers) supporters > should think now what do to, instead of defending something, that could > be improved. Try to see it this way, It does not hurt, I promise! :-) > > I will try to find the US competitor for Mailvelope and test this as well. Ok, found it. The name is flowcrypt, a browser add-on for Gmail and it works there too. So now we have sequoia-pgp, Mailvelope and flowcrypt. However flowcrypt sends immediately emails because the butten say there encrypt,sign and send. I just wrote their support to consider to optionally copy to the clipboard, so that users have the same option like Mailvelope and I also refered to this thread here. Regards Stefan From spam.trap.mailing.lists at gmail.com Sun Jan 17 18:27:58 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 18:27:58 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210117035045.ozi2waa54ktjj7yh@raf.org> Message-ID: On Sun, Jan 17, 2021 at 9:14 AM Stefan Claas wrote: > Regarding a multi-purpose key and WKD. I mentioned here already > that a multi-purpose usage key can be used for other tasks as well, > besides popular email. Remember only my old thread where I asked > for some volunteers in the EU, which allows them in their country > to more securely than email and also more decentralized than email > to communicate. I also mentioned in another thread Bitmessage, > which does not have an email address and works as p2p global > Network like a modern and privacy friendly replacement for email. For Alice and Bob and their friends. https://dead-drop.me/ Regards Stefan From kloecker at kde.org Sun Jan 17 18:41:44 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 17 Jan 2021 18:41:44 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <87pn27hbx1.fsf@wheatstone.g10code.de> Message-ID: <18521999.g9bypVEHfG@breq> On Sonntag, 17. Januar 2021 10:48:17 CET Erich Eckner via Gnupg-users wrote: > Hi all, > > On Thu, 14 Jan 2021, Werner Koch via Gnupg-users wrote: > > On Thu, 14 Jan 2021 01:47, ?ngel said: > >> I understand this to mean it as "only use the direct method if the > >> required sub-domain does not exist", with the SHOULD meaning that the > >> direct method is not required (not sure why, I would have probably used > > > > Right. The subdomain is actually a workaround for SRV RR. We can't > > use the latter in browser based implementation and thus need to resort > > to this hack. > > Forgive my ignorance, but can someone explain, what "browser based > implementation" of WKD exists (or might exist) and/or why this is > desirable? https://openpgpjs.org/ supports WKD. OpenPGP.js is used by many web applications (see link). This is desirable to allow webmailers (and other web applications that support OpenPGP) to lookup OpenPGP keys via WKD. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From gnupg at eckner.net Sun Jan 17 18:53:29 2021 From: gnupg at eckner.net (Erich Eckner) Date: Sun, 17 Jan 2021 18:53:29 +0100 (CET) Subject: WKD proper behavior on fetch error In-Reply-To: <18521999.g9bypVEHfG@breq> References: <87pn27hbx1.fsf@wheatstone.g10code.de> <18521999.g9bypVEHfG@breq> Message-ID: <3b3cd652-c431-b2fd-a278-8b162e2a38e5@eckner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sun, 17 Jan 2021, Ingo Kl?cker wrote: > On Sonntag, 17. Januar 2021 10:48:17 CET Erich Eckner via Gnupg-users wrote: >> Hi all, >> >> On Thu, 14 Jan 2021, Werner Koch via Gnupg-users wrote: >>> On Thu, 14 Jan 2021 01:47, ?ngel said: >>>> I understand this to mean it as "only use the direct method if the >>>> required sub-domain does not exist", with the SHOULD meaning that the >>>> direct method is not required (not sure why, I would have probably used >>> >>> Right. The subdomain is actually a workaround for SRV RR. We can't >>> use the latter in browser based implementation and thus need to resort >>> to this hack. >> >> Forgive my ignorance, but can someone explain, what "browser based >> implementation" of WKD exists (or might exist) and/or why this is >> desirable? > > https://openpgpjs.org/ supports WKD. OpenPGP.js is used by many web > applications (see link). This is desirable to allow webmailers (and other web > applications that support OpenPGP) to lookup OpenPGP keys via WKD. Ah, yes, I didn't see the possibility/need to have the keyring in the browser (or no keyring at all) and receive keys from within the browser. :-) Thanks for the pointers! And I assume, it's non-trivial or even impossible to start proper DNS queries (for a SRV record) from within JS? Because it seems to me, the root for this debate is in gnupg's "ab"use of a subdomain for something which should actually be a SRV record. (Plus the fact, that DNS wildcards and TLS wildcard certficates work differently.) > > Regards, > Ingo > regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAEeZoACgkQCu7JB1Xa e1prNhAAnSOXwNUZSQtpU1716Nccb1pywGpvNkKn/KWSA6kDhacKqtjs3KzOtXNW 0bppT7QaCNxAcJVKqKhbki5epNRRDdft/KM9Pw1I/c+n+TjOPS6340r7qlZXBV1c 0wlCuAPSGLvV6nl5oeGnDmQqn0uT7fT52Gt8iUQdRnrHI+u6Q/kR4SEQyDAili2A HnN58CXotrNeihAooOoQZxc8Qlfd1DRWyAQ60wgFQX/0HTIkAaAXlPljN5DBlbAd 1c1cEFMmHAxfz5CsWS77jl9G30ysxt3JKpGy0Xr6Pe2WfEipdUBQCwMO6lS82iXo RUFQm4ybDByXVBaqpJXCnFPZT+Mxe3gSS4BwpFwsDWMh5V7iIp1atExazsjQPc5U UC7KldS6NqMqFhFtDn17sNATx/lKqmeh2Lze8vQ4x/tqxzNiR6tXZ43S/DJEiPsR uo0K2h7DPFnEt34HvQeiq3bt/kPAKEwg6Lj80fWq9zA506j2elg1PlXfj/hSqEPh rw/9CVD414uuf4W7ncF/9ijOPhO1k4hJIdv32VTWOxso8oSHIdEH+sjZwINH8ABn Jb8eq05BVRQwsnCqSZShyaMJCVXYh9dDDe6TLebfhTS13aUzvbqqw9hhGNbSB9Xj DCL3M9uCX8rIpcorihGsBN0Oa0yXpVwdkf8Jv2AHWiSpidsF3nw= =Fwhi -----END PGP SIGNATURE----- From angel at pgp.16bits.net Sun Jan 17 19:27:05 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 17 Jan 2021 19:27:05 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> Message-ID: <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> On 2021-01-17 at 16:28 +0100, Stefan Claas wrote: > sorry, but simply said I discovered now that a second major and > trusted > contender, Mailvelope supported by BSI and audited, works also as > sequoia-pgp does. Werner and his (shrinking in numbers) supporters > should think now what do to, instead of defending something, that > could > be improved. Try to see it this way, It does not hurt, I promise! :-) > > I will try to find the US competitor for Mailvelope and test this as > well. Looking at mailvelope dns queries, it isn't even trying the advanced method, so no wonder it doesn't fail on a bad certificate there. Looking at flowcrypt code at https://github.com/FlowCrypt/flowcrypt-browser/blob/master/extension/js/common/api/key-server/wkd.ts they do support the advanced method but on any failure fetching the policy file, they will check the direct method (this may be slightly different to the condition in which way sequoia falls back). I feel there is a need for a proper wkd test suite (as well as a clarifying on the draft itself the things that are coming up). Best regards From spam.trap.mailing.lists at gmail.com Sun Jan 17 19:41:44 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 19:41:44 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> Message-ID: On Sun, Jan 17, 2021 at 7:30 PM ?ngel wrote: > > On 2021-01-17 at 16:28 +0100, Stefan Claas wrote: > > sorry, but simply said I discovered now that a second major and > > trusted > > contender, Mailvelope supported by BSI and audited, works also as > > sequoia-pgp does. Werner and his (shrinking in numbers) supporters > > should think now what do to, instead of defending something, that > > could > > be improved. Try to see it this way, It does not hurt, I promise! :-) > > > > I will try to find the US competitor for Mailvelope and test this as > > well. > > Looking at mailvelope dns queries, it isn't even trying the advanced > method, so no wonder it doesn't fail on a bad certificate there. Please try to accept that GitHub (and maybe in the future others as well) has *no* bad certificate! The only thing which could be considered "bad" or at least sub-optimal for a global ML, like this one, Is the support in form of the GnuPGP ecosystem devs. > > Looking at flowcrypt code at > https://github.com/FlowCrypt/flowcrypt-browser/blob/master/extension/js/common/api/key-server/wkd.ts > they do support the advanced method but on any failure fetching the > policy file, they will check the direct method (this may be slightly > different to the condition in which way sequoia falls back). > > I feel there is a need for a proper wkd test suite (as well as a > clarifying on the draft itself the things that are coming up). Yes, but please a test suite in form from independent third parties, if possible, or in case of GnuPG devs heavily discussed and supported by OpenPGP app devs. Regarding the draft, fully agree and if you check dev.gnupg.org, dkg was so kind already and suggested proper clarification for WKD users. Regards Stefan From ayoubhm at gmail.com Sat Jan 16 23:56:58 2021 From: ayoubhm at gmail.com (Ayoub Misherghi) Date: Sat, 16 Jan 2021 14:56:58 -0800 Subject: Why is there a conflict? In-Reply-To: References: <4595775a-95c3-19ee-91f5-7e5d5f44e5e2@gmail.com> Message-ID: <392120fe-6bba-fafc-58d0-876a634ed569@gmail.com> An HTML attachment was scrubbed... URL: From ayoubhm at gmail.com Sun Jan 17 00:10:05 2021 From: ayoubhm at gmail.com (Ayoub Misherghi) Date: Sat, 16 Jan 2021 15:10:05 -0800 Subject: Why is there a conflict? In-Reply-To: References: <4595775a-95c3-19ee-91f5-7e5d5f44e5e2@gmail.com> Message-ID: <7c614ce2-ff41-c7d8-d0a7-9875beea29c6@gmail.com> An HTML attachment was scrubbed... URL: From andre at colomb.de Sun Jan 17 21:17:53 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Sun, 17 Jan 2021 21:17:53 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> Message-ID: Hi Stefan, On 17/01/2021 19.41, Stefan Claas via Gnupg-users wrote: > Please try to accept that GitHub (and maybe in the future others as well) > has *no* bad certificate! The only thing which could be considered "bad" > or at least sub-optimal for a global ML, like this one, Is the support in > form of the GnuPGP ecosystem devs. GitHub's web server, *in your specific use case* is sending a certificate proving it is an apple when you're asking for it under the name "orange". That makes the certificate *invalid* for that connection request as it could not be distinguished from a man in the middle attack asking your browser to "Please try to accept that this apple is an orange". Don't you find it strange that you are the only one still insisting that it's valid when several very knowledgeable people have explained to you in many different ways why it's simply not true? And please tone down on the GnuPG criticism. It's your right to dislike the software or even Werner Koch personally. But this is not the right place for anti-publicity or constant personal stabs against people who have patiently spent a lot of time to help and educate you. Please try to keep the discussion productive. Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sun Jan 17 21:35:02 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 17 Jan 2021 15:35:02 -0500 Subject: Fundraising Message-ID: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> A little more than a month ago I said I'd match all donations made to GnuPG from December 10 to January 6. I'm happy to report y'all made me contribute 370 Euros, or about $450 USD. The money has been paid and is sitting in GnuPG's account. I hope this encouraged some of y'all to donate to GnuPG this year. And if you missed out, why not consider making a recurring monthly contribution of your own? It's a great way to tell the crew thank-you for all the work they do. Thanks, all the GnuPG contributors. I really appreciate it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 850 bytes Desc: This is a digitally signed message part URL: From juergen at bruckner.email Sun Jan 17 21:39:48 2021 From: juergen at bruckner.email (Juergen Bruckner) Date: Sun, 17 Jan 2021 21:39:48 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> Message-ID: I can only agree with Andre's words. And as far as Sequoia is concerned, Stefen's explanations only confirmed that this is software that I definitely don't want to use. Software that accepts an invalid digital certificate as correct, has no place in an environment where security and confidentiality are concerned. This is an a b s o l u t e NO-GO. GnuPG doesn't have to change anything here. The change MUST be made at Sequoia, preferably yesterday! regards Juergen Am 17.01.21 um 21:17 schrieb Andr? Colomb: > Hi Stefan, > > On 17/01/2021 19.41, Stefan Claas via Gnupg-users wrote: >> Please try to accept that GitHub (and maybe in the future others as well) >> has *no* bad certificate! The only thing which could be considered "bad" >> or at least sub-optimal for a global ML, like this one, Is the support in >> form of the GnuPGP ecosystem devs. > > GitHub's web server, *in your specific use case* is sending a > certificate proving it is an apple when you're asking for it under the > name "orange". That makes the certificate *invalid* for that connection > request as it could not be distinguished from a man in the middle attack > asking your browser to "Please try to accept that this apple is an orange". > > Don't you find it strange that you are the only one still insisting that > it's valid when several very knowledgeable people have explained to you > in many different ways why it's simply not true? > > And please tone down on the GnuPG criticism. It's your right to dislike > the software or even Werner Koch personally. But this is not the right > place for anti-publicity or constant personal stabs against people who > have patiently spent a lot of time to help and educate you. Please try > to keep the discussion productive. > > Kind regards > Andr? > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- /?\ No | \ / HTML | Juergen Bruckner X in | juergen at bruckner.email / \ Mail | -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From spam.trap.mailing.lists at gmail.com Sun Jan 17 21:38:42 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 21:38:42 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> Message-ID: On Sun, Jan 17, 2021 at 9:21 PM Andr? Colomb wrote: > > Hi Stefan, Hi Andre, > Don't you find it strange that you are the only one still insisting that > it's valid when several very knowledgeable people have explained to you > in many different ways why it's simply not true? Yes, very strange ... > And please tone down on the GnuPG criticism. It's your right to dislike > the software or even Werner Koch personally. But this is not the right > place for anti-publicity or constant personal stabs against people who > have patiently spent a lot of time to help and educate you. Please try > to keep the discussion productive. I think I am politely here, at least I have not received any emails telling me otherwise. We have different point of views and if the debate heats up a bit, well, we are old enough, I guess to handle this. And regarding productivity I think this whole thread is productive, at least It should allow devs to think about it, because all things I mentioned here have IMHO no disadvantage for OpenPGP users. Would you or anybody else agree on this? And please remember I started this thread for help and if people try to put me in another direction they should accept that I may not act as they wish, while always trying to be polite. Regards Stefan From dgouttegattat at incenp.org Sun Jan 17 21:45:07 2021 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 17 Jan 2021 20:45:07 +0000 Subject: WKD proper behavior on fetch error In-Reply-To: <3b3cd652-c431-b2fd-a278-8b162e2a38e5@eckner.net> References: <87pn27hbx1.fsf@wheatstone.g10code.de> <18521999.g9bypVEHfG@breq> <3b3cd652-c431-b2fd-a278-8b162e2a38e5@eckner.net> Message-ID: <20210117204507.72qldfhxyg3pe3ml@dynein.local.incenp.org> On Sun, Jan 17, 2021 at 06:53:29PM +0100, Erich Eckner via Gnupg-users wrote: >And I assume, it's non-trivial or even impossible to start proper DNS >queries (for a SRV record) from within JS? Apparently not, at least that what folks on the IETF openpgp mailing lists said when the issue had been debated [1]. That?s why the WKD protocol (which *used* to rely on SRV records to provide a level of indirection between the domain name and the WKD server, which was The Right Thing? do to) had to drop the SRV records in favor of a fixed subdomain, at the demand of Javascript developers. >Because it seems to me, the root for this debate is in gnupg's "ab"use >of a subdomain for something which should actually be a SRV record. Given that this ?abuse? was almost forced upon GnuPG developers by JS developers who basically said ?please change your protocol otherwise there?s no way I can implement it?, and that Werner was on the record reluctant to the change [2], I find it quite disheartening that the blame should be put at GnuPG?s feet. :( Oh well, all problems in the OpenPGP world are GnuPG?s fault anyway. It is known. - Damien [1] https://mailarchive.ietf.org/arch/msg/openpgp/f6V8W9wKY6dt2wAq4FBOWk8wtos/ [2] https://mailarchive.ietf.org/arch/msg/openpgp/SH1dzlERTgJsaCoKvxQGsnckq-w/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From spam.trap.mailing.lists at gmail.com Sun Jan 17 21:44:57 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 21:44:57 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> Message-ID: On Sun, Jan 17, 2021 at 9:40 PM Juergen Bruckner via Gnupg-users wrote: > > I can only agree with Andre's words. Perfectly fine for me if you take this route. > And as far as Sequoia is concerned, Stefen's explanations only confirmed > that this is software that I definitely don't want to use. You don't have to, because we live in a free world. > Software that accepts an invalid digital certificate as correct, has no > place in an environment where security and confidentiality are concerned. > This is an a b s o l u t e NO-GO. You talking nonsense while not knowing! > GnuPG doesn't have to change anything here. > The change MUST be made at Sequoia, preferably yesterday! Utterly nonsense, IMHO. sequoia-pgp, Mailvelope (supported by BSI and *audited*) and flowcrypt do all work with github.io pages! And you were not able to reply to me here if your WKD set-up for dummies worked for you. So much for that part... Regards Stefan From juergen at bruckner.email Sun Jan 17 22:13:23 2021 From: juergen at bruckner.email (Juergen Bruckner) Date: Sun, 17 Jan 2021 22:13:23 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> Message-ID: Well Stefan, Am 17.01.21 um 21:44 schrieb Stefan Claas: > On Sun, Jan 17, 2021 at 9:40 PM Juergen Bruckner via Gnupg-users > wrote: >> >> I can only agree with Andre's words. > > Perfectly fine for me if you take this route. > >> And as far as Sequoia is concerned, Stefen's explanations only confirmed >> that this is software that I definitely don't want to use. > > You don't have to, because we live in a free world. > Yes we live in a free world, and you shouldn't forget this! >> Software that accepts an invalid digital certificate as correct, has no >> place in an environment where security and confidentiality are concerned. >> This is an a b s o l u t e NO-GO. > > You talking nonsense while not knowing! > Thank you very much! I'll take that as compliment! >> GnuPG doesn't have to change anything here. >> The change MUST be made at Sequoia, preferably yesterday! > > Utterly nonsense, IMHO. sequoia-pgp, Mailvelope (supported by BSI > and *audited*) and flowcrypt do all work with github.io pages! And you > were not able to reply to me here if your WKD set-up for dummies worked > for you. So much for that part... If something, or a software ist supported by BSI and/or audited *does not* say it is free of bugs or failures. Your showcase with github.io also says nothing else than that Sequoia considers an invalid certificate to be correct. That this happens in audited software says just as much about the value of the audit. And it's not 'my' setup for dummies, it was a general question because most of the explanations are very specific and can pose major problems for a 'beginner'. I have been using WKD successfully in different versions for a long time. The only thing that was new for me in this context is the possibility of implementing WKD via the openpgp server using a CNAME entry. Best Juergen -- /?\ No | \ / HTML | Juergen Bruckner X in | juergen at bruckner.email / \ Mail | -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From spam.trap.mailing.lists at gmail.com Sun Jan 17 22:27:24 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 22:27:24 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> Message-ID: On Sun, Jan 17, 2021 at 10:16 PM Juergen Bruckner via Gnupg-users wrote: Hi Juergen. > Your showcase with github.io also says nothing else than that Sequoia > considers an invalid certificate to be correct. That this happens in > audited software says just as much about the value of the audit. Please try to accept that GitHub's SSL cert is *valid*, or do you think that a CA certifies and invalid cert? Regarding the other aruments you have made, don't you think if a fruitful solution from all involved devs are a good idea if it gives WKD users, the greatest flexibility? Peace and best regards Stefan From remco at webconquest.com Sun Jan 17 23:00:51 2021 From: remco at webconquest.com (Remco =?utf-8?Q?R=C4=B3nders?=) Date: Sun, 17 Jan 2021 17:00:51 -0500 Subject: WKD proper behavior on fetch error In-Reply-To: References: <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> Message-ID: On Sun, Jan 17, 2021 at 10:27:24PM +0100, Stefan wrote in : >On Sun, Jan 17, 2021 at 10:16 PM Juergen Bruckner via Gnupg-users > wrote: > >Hi Juergen. > >> Your showcase with github.io also says nothing else than that Sequoia >> considers an invalid certificate to be correct. That this happens in >> audited software says just as much about the value of the audit. > >Please try to accept that GitHub's SSL cert is *valid*, or do you think >that a CA certifies and invalid cert? It is not valid for the requested sub-sub-domain. Just as if you would hold my passport, the passport itself might be valid, but it is not valid for you to identify yourself with. That said, welcome to my kill file. From spam.trap.mailing.lists at gmail.com Sun Jan 17 23:10:01 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 17 Jan 2021 23:10:01 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> Message-ID: On Sun, Jan 17, 2021 at 11:02 PM Remco R?nders wrote: > > On Sun, Jan 17, 2021 at 10:27:24PM +0100, Stefan wrote in > : > >On Sun, Jan 17, 2021 at 10:16 PM Juergen Bruckner via Gnupg-users > > wrote: > > > >Hi Juergen. > > > >> Your showcase with github.io also says nothing else than that Sequoia > >> considers an invalid certificate to be correct. That this happens in > >> audited software says just as much about the value of the audit. > > > >Please try to accept that GitHub's SSL cert is *valid*, or do you think > >that a CA certifies and invalid cert? > > It is not valid for the requested sub-sub-domain. Just as if you would hold my > passport, the passport itself might be valid, but it is not valid for you to > identify yourself with. > > That said, welcome to my kill file. Interesting how you handle this thread (while I do not care to land in your kill file ...) Regards Stefan From bereska at hotmail.com Sun Jan 17 22:18:53 2021 From: bereska at hotmail.com (bereska at hotmail.com) Date: Sun, 17 Jan 2021 23:18:53 +0200 Subject: Why is there a conflict? In-Reply-To: <392120fe-6bba-fafc-58d0-876a634ed569@gmail.com> References: <4595775a-95c3-19ee-91f5-7e5d5f44e5e2@gmail.com> <392120fe-6bba-fafc-58d0-876a634ed569@gmail.com> Message-ID: "a at b:c$ gpg -e -b -r Mike data.file" produces the encrypted file data.file.sig with the detached signature of data.file I don't think there's a oneliner for what you're trying to achieve gpg -er Mike data.file gpg -b data.file.gpg 17.01.2021 00:56, Ayoub Misherghi via Gnupg-users ?????: > > a at b:c$ gpg -e -b -r Mike data.file > > > produced "data.file.sig" and no "data.file.gpg" > > > Thanks, > > > Ayoub > > > > On 1/16/2021 2:53 AM, Dmitry Gudkov wrote: >> Just get rid of -s >> >> On Jan 16, 2021 12:35, Ayoub Misherghi via Gnupg-users >> wrote: >> >> >> The intention is to sign and encrypt "data.file" producing a detached >> signature file. >> >> >> a at b:c$ gpg -s -e -b -r Mike data.file >> >> gpg: conflicting commands >> >> >> Why is there a conflict? I do not want to produce an attached signature. >> >> >> Ayoub >> > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at colomb.de Mon Jan 18 00:03:46 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Mon, 18 Jan 2021 00:03:46 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> Message-ID: <024e22ec-3a77-2786-261a-bea6b5aeebec@colomb.de> On 17/01/2021 21.39, Juergen Bruckner via Gnupg-users wrote: > And as far as Sequoia is concerned, Stefen's explanations only confirmed > that this is software that I definitely don't want to use. > Software that accepts an invalid digital certificate as correct, has no > place in an environment where security and confidentiality are concerned. > This is an? a b s o l u t e? NO-GO. To be fair, it's not quite that bad. Sequoia does recognize the invalid certificate as such, as Neal pointed out. It just doesn't scream out loud about it. Instead it goes on silently trying the direct method instead, for which everything is configured correctly in Stefan's setup. That is not following the current WKD draft correctly, as interpreted by the majority of those who spoke up IIRC. But so far no scenario was brought up where it poses an obvious security risk. More like hiding the problem from an admin trying to deliberately set up the advanced method and possibly ending up with some forgotten remains of the direct method having been used before. In my opinion, the WKD spec needs clear rules about cases when to switch to the direct method. And making it hinge solely on proper DNS configuration is perfectly fine. Having enough control over the domain is one more prerequisite (besides the CA stuff) which an impostor would need to get around. After all, the corresponding web server is trusted to deliver the correct OpenPGP public key for authenticated communication. @Stefan, are you aware that in your scheme involving sac001.github.io, whoever convinces GitHub to give them control over that subdomain, can silently replace those public keys and start a man-in-the-middle attack? You could not even rely on the TLS layer, because GitHub probably will not revoke their wildcard certificate just for you. Hijacking a GitHub Pages user name seems more likely than taking over a well secured domain hosting account. Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gnupg at raf.org Mon Jan 18 00:46:18 2021 From: gnupg at raf.org (raf) Date: Mon, 18 Jan 2021 10:46:18 +1100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210117035045.ozi2waa54ktjj7yh@raf.org> Message-ID: <20210117234618.ockvbzqvlg5qh7od@raf.org> On Sun, Jan 17, 2021 at 09:14:37AM +0100, Stefan Claas wrote: > Regarding a multi-purpose key and WKD. I mentioned here already > that a multi-purpose usage key can be used for other tasks as well, > besides popular email. I know that keys can be used for things other than email, but the point I was making is that WKD is only for email. It's entire reason for existing is to automatically and reliably find the key that corresponds to an email address. It has no other purpose. But I can see that what you really want is to be able to use WKD for other purposes. But I don't see how that would work well. I assume that all existing WKD clients are email clients. I think you are suggesting that other types of system that are not email-related start to adopt WKD for locating keys. That sounds reasonable. Perhaps they will. But I think that it would look strange to require a label for a key that looks like an email address but isn't, in order to obtain a key. I can't help thinking that just publishing the URL of the key would be much much simpler. Simpler still, and more automatable, would be to come up with your own proposal for placing keys in a website's .well-known directory and not have anything at all to do with labels that look like email addresses but aren't. I can't help thinking that if you use labels that look like addresses but aren't, people are likely to assume that it is an email address and will try to send emails to it, and be thwarted. It breaks the principle of least astonishment. But maybe that won't be a problem, depending on the nature of these other systems. cheers, raf From gnupg at raf.org Mon Jan 18 00:57:23 2021 From: gnupg at raf.org (raf) Date: Mon, 18 Jan 2021 10:57:23 +1100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> Message-ID: <20210117235723.wpr2vr2mrhz33sew@raf.org> On Sun, Jan 17, 2021 at 10:27:24PM +0100, Stefan Claas via Gnupg-users wrote: > On Sun, Jan 17, 2021 at 10:16 PM Juergen Bruckner via Gnupg-users > wrote: > > Please try to accept that GitHub's SSL cert is *valid*, or do you think > that a CA certifies and invalid cert? Please try to accept that github's certificate is only valid for the domains that the CA certified it as being valid for (which are listed in the certificate itself for all to see), and that it is not valid for any other domain (that the CA did not certify it as being valid for). I thought the passport example was very good. A slight tweak (for wildcard certificates) is to imagine a passport that identifies a person and their children, but not their grand children. I think such passports exist (or used to), but only for very young children. It's not a perfect analogy, but I hope it paints the picture well enough. cheers, raf From neal at walfield.org Mon Jan 18 08:39:24 2021 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 18 Jan 2021 08:39:24 +0100 Subject: WKD Checker In-Reply-To: <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> Message-ID: <87y2gq8zir.wl-neal@walfield.org> On Sun, 17 Jan 2021 19:27:05 +0100, ?ngel wrote: > I feel there is a need for a proper wkd test suite (as well as a > clarifying on the draft itself the things that are coming up). FWIW, there is Wiktor Kwapisiewicz's wkd checker: https://gitlab.com/wiktor-k/wkd-checker https://wkd.sequoia-pgp.org/ This is more for checking a WKD setup than checking a WKD client. I'm sure he'd be open to issues for things that he missed. :) Neal From neal at walfield.org Mon Jan 18 08:41:04 2021 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 18 Jan 2021 08:41:04 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> Message-ID: <87wnwa8zfz.wl-neal@walfield.org> Hi Stefan, On Sun, 17 Jan 2021 19:41:44 +0100, Stefan Claas via Gnupg-users wrote: > Please try to accept that GitHub (and maybe in the future others as well) > has *no* bad certificate! As others have tried to explain: the certificate that github uses for sub.sub.github.com is invalid for sub.sub.github.com; that certificate is only valid for sub.github.com and github.com. :) Neal From andre at colomb.de Mon Jan 18 08:49:30 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Mon, 18 Jan 2021 08:49:30 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <616a8a42544340b2aeb8c825b6aa92d3-stefan@ctemplar.com> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <024e22ec-3a77-2786-261a-bea6b5aeebec@colomb.de> <616a8a42544340b2aeb8c825b6aa92d3-stefan@ctemplar.com> Message-ID: <77d1b835-dab0-a034-85ed-bb0cf4cbbd3b@colomb.de> On 18/01/2021 00.43, Stefan Claas wrote: > But what you say I was thinking about as well. My proposal was to include > in the policy file fingerprint(s) of key(s) and generate an .ots file, from > opentimestamps.org, from the policy file and put that .ots file somewhere. > In the old days it was common, prior starting encrypted comms to compare > fingerprints over other channels. If you are coordinating the use of a separate channel to compare fingerprints, you can also just coordinate where the public keys are to be downloaded. As others have pointed out[1], it's even easier to set up than WKD (no rules to follow). And if you're not using the whole thing for e-mail, then you're probably not using an e-mail client with automatic WKD retrieval. So there is no benefit of using WKD over making up your own URL and telling that to your communication partners. [1]: https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064633.html > And regarding secure domains, would you consider VPS servers secure > too for WKD? I don't know about the servers, my point was about the domain control. Whoever can change the DNS records can just have them point to a different server with their own (malicious) content. GitHub Pages as a free web hosting service will certainly not give you the same security guarantees as a hosting provider where you pay money to administer a domain of your own. > BTW. I did not received yet your reply for my two other accounts, hence the > late reply. Sorry, I don't quite understand. Would you like a reply to be addressed directly in addition to the mailing list? Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- 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 Mon Jan 18 09:05:21 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Jan 2021 09:05:21 +0100 Subject: Why is there a conflict? In-Reply-To: <4595775a-95c3-19ee-91f5-7e5d5f44e5e2@gmail.com> (Ayoub Misherghi via Gnupg-users's message of "Fri, 15 Jan 2021 15:43:57 -0800") References: <4595775a-95c3-19ee-91f5-7e5d5f44e5e2@gmail.com> Message-ID: <87sg6yfz5q.fsf@wheatstone.g10code.de> On Fri, 15 Jan 2021 15:43, Ayoub Misherghi said: > a at b:c$ gpg -s -e -b -r Mike data.file > > gpg: conflicting commands You can use the combined method of signing (-s) and encryption (-e) with a detached signatures (-b). 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 neal at walfield.org Mon Jan 18 10:14:38 2021 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 18 Jan 2021 10:14:38 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> Message-ID: <87ture8v41.wl-neal@walfield.org> Hi Angel, On Thu, 14 Jan 2021 01:47:12 +0100, ?ngel wrote: > On 2021-01-13 at 10:12 +0100, Neal H. Walfield wrote: > As such, I do think sequoia is non-conformant, although I'm > more interested in determining the proper behaviour of a WKD client. > > ... > I think it would be good that sq stopped after processing > > openpgpkey.foo.com, mainly to follow the principle of least surprise. > > If the key can only be placed in one place, then it MUST be good (or > bad, but it will be consistent). I've given this issue some more thought. First, I don't think WKD is a strong authentication method. It is sufficient for doing key discovery for opportunistic encryption (i.e., it's a reasonable guess), but I wouldn't want someone to rely on it to protect them from an active adversary, or phishing attempts. If you consider WKD to be a strong authentication mechanism, then you are basically relying on X.509 plus a bit of brittleness (the certificates aren't signed, only the TLS session is). So, if that's your position, then just use S/MIME. One way to increase protection for certificates is to certify them in the usual OpenPGP manner. Of course, this begs the question: if you certify them before you get them via WKD, is WKD really helping with key discovery? Well, OpenPGP doesn't only have certifications, it also has trusted introducers, i.e., CAs. So, a certificate could be certified by someone else. Isn't that just X.509? Well no, X.509 de facto relies on a few hundred global CAs (Symantec, TurkTrust, etc.), but in OpenPGP everyone is by jure a CA. So, a domain administrator could just set up a CA for their own domain. (In fact, OpenPGP CA [1,2] makes this pretty easy.) This results in a federated system! Now, individuals "just" need to designate a few CAs. Yes, it is still work, but it is much less work. As admins are more technically sophisticated, there are other things that they can do to improve security. But, that's getting a bit off topic. [1] https://gitlab.com/openpgp-ca/openpgp-ca [2] https://openpgp-ca.gitlab.io/openpgp-ca/ Second, the attack that I'm most worried about with repect to WKD is a DoS. It is trivial for an attacker to block WKD. They just need to filter the DNS. In the privacy world, there are a lot of tools to do just that. For instance, pi hole [3] blocks ads at the DNS level. It could just as well be used to force the openpgpkeys subdomain to revolve to localhost. Comcast, a major US ISP, used to do this type of interception as a way to increase revenue: if a user typed in an invalid domain, instead of return NXDOMAIN, Comcast would resolve it and show the user some ads instead [4]. AIUI, they stopped doing this due to general outrage, but that is little solace. [3] https://docs.pi-hole.net/main/post-install [4] https://www.pcworld.com/article/169723/article.html This attack is likely to go unnoticed, firstly because most key discovery is done in the background, and probably shouldn't actively show errors messages to the user. But, more importantly, because nothing else uses the openpgpkeys subdomain, everything else will still appear to work! In short: I understand the motivation for the subdomain. I understand why one should first check there. But, I think we do our users a disservice by not falling back to the direct method in the case of DNS errors. :) Neal From juergen at bruckner.email Mon Jan 18 12:07:04 2021 From: juergen at bruckner.email (Juergen Bruckner) Date: Mon, 18 Jan 2021 12:07:04 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> Message-ID: <23eae403-62b8-71ff-d31d-f555c9c58f8a@bruckner.email> Hello again Stefan Am 17.01.21 um 22:27 schrieb Stefan Claas: > On Sun, Jan 17, 2021 at 10:16 PM Juergen Bruckner via Gnupg-users > wrote: > > Hi Juergen. > >> Your showcase with github.io also says nothing else than that Sequoia >> considers an invalid certificate to be correct. That this happens in >> audited software says just as much about the value of the audit. > > Please try to accept that GitHub's SSL cert is *valid*, or do you think > that a CA certifies and invalid cert? > [...] For you to take notes: The certificate used by github issued by the CA DigiCert Inc IS valid for: - www.github.com - github.com - * .github.com - github.io - * .github.io - githubusercontent.com - * .githubusercontent.com so that means the certificate MAY be valid for - abc.github.io but it MUST NOT be valid for - foo.abc.github.com This is stipulated in the guidelines of the CA / B forum to which all CAs worldwide have to adhere. DigiCert Inc. is no exception. So what some members have already said to you here applies. Sequoia accepts an *invalid* certificate for the host 'foo.abc.github.io' and that is "failure by design". That won't change if you claim the opposite a million times. Best Juergen -- /?\ No | \ / HTML | Juergen Bruckner X in | juergen at bruckner.email / \ Mail | -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From andrewg at andrewg.com Mon Jan 18 12:17:49 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 18 Jan 2021 11:17:49 +0000 Subject: WKD proper behavior on fetch error In-Reply-To: <23eae403-62b8-71ff-d31d-f555c9c58f8a@bruckner.email> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <23eae403-62b8-71ff-d31d-f555c9c58f8a@bruckner.email> Message-ID: <36e3ef99-8564-4747-df8d-40a3e37c2b2f@andrewg.com> On 18/01/2021 11:07, Juergen Bruckner via Gnupg-users wrote: > Sequoia accepts an *invalid* certificate for the host > 'foo.abc.github.io' and that is "failure by design". This is incorrect. Sequoia *does not* accept this invalid certificate. Sequoia and gnupg only differ in their fallback behaviour after the certificate has been correctly rejected. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From juergen at bruckner.email Mon Jan 18 12:25:22 2021 From: juergen at bruckner.email (Juergen Bruckner) Date: Mon, 18 Jan 2021 12:25:22 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <024e22ec-3a77-2786-261a-bea6b5aeebec@colomb.de> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <024e22ec-3a77-2786-261a-bea6b5aeebec@colomb.de> Message-ID: <14ded4f0-7eeb-9189-c9c6-66423d6d7c61@bruckner.email> Hello Andr?, Am 18.01.21 um 00:03 schrieb Andr? Colomb: > On 17/01/2021 21.39, Juergen Bruckner via Gnupg-users wrote: >> And as far as Sequoia is concerned, Stefen's explanations only confirmed >> that this is software that I definitely don't want to use. >> Software that accepts an invalid digital certificate as correct, has no >> place in an environment where security and confidentiality are concerned. >> This is an? a b s o l u t e? NO-GO. > > To be fair, it's not quite that bad. Sequoia does recognize the invalid > certificate as such, as Neal pointed out. It just doesn't scream out > loud about it. Instead it goes on silently trying the direct method > instead, for which everything is configured correctly in Stefan's setup. > > That is not following the current WKD draft correctly, as interpreted by > the majority of those who spoke up IIRC. But so far no scenario was > brought up where it poses an obvious security risk. More like hiding > the problem from an admin trying to deliberately set up the advanced > method and possibly ending up with some forgotten remains of the direct > method having been used before. > > In my opinion, the WKD spec needs clear rules about cases when to switch > to the direct method. And making it hinge solely on proper DNS > configuration is perfectly fine. Having enough control over the domain > is one more prerequisite (besides the CA stuff) which an impostor would > need to get around. After all, the corresponding web server is trusted > to deliver the correct OpenPGP public key for authenticated communication. > [...] Yes, I will be fair and say that Sequoia works okay so far. And yes, it is good to hear from Neal that Sequoia actually recognizes this as an invalid certificate. BUT, if a software claim to ensure secure communication, then this shown behavior is unacceptable to me, at least a reference to the invalid certificate should have to be shown. Otherwise, the discussion now mainly revolves around the fact that Stefan still claims the certificate is valid and Sequoia continues because of this. (At least that's my understanding of Stefan's statements). Best regards Juergen -- /?\ No | \ / HTML | Juergen Bruckner X in | juergen at bruckner.email / \ Mail | -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From juergen at bruckner.email Mon Jan 18 12:33:07 2021 From: juergen at bruckner.email (Juergen Bruckner) Date: Mon, 18 Jan 2021 12:33:07 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <36e3ef99-8564-4747-df8d-40a3e37c2b2f@andrewg.com> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <23eae403-62b8-71ff-d31d-f555c9c58f8a@bruckner.email> <36e3ef99-8564-4747-df8d-40a3e37c2b2f@andrewg.com> Message-ID: Hello Andrew, Am 18.01.21 um 12:17 schrieb Andrew Gallagher via Gnupg-users: > On 18/01/2021 11:07, Juergen Bruckner via Gnupg-users wrote: >> Sequoia accepts an *invalid* certificate for the host >> 'foo.abc.github.io' and that is "failure by design". > > This is incorrect. Sequoia *does not* accept this invalid certificate. > Sequoia and gnupg only differ in their fallback behaviour after the > certificate has been correctly rejected. > Yes I do understand that behavior, but that wasnt explained that way by Stefan. And I have understood it so far that Stefan claims Sequoia recognizes this certificate as valid and therefore continues to work. To my understanding, Stefen has not yet spoken of a "fallback". He actually went so far, to urge Werner in a more than rude way to add this (wrong) behavior into GnuPG. For me personally, this is still a major obstacle to using Sequoia productively or to recommend it to our customers. I still regard this behavior as a gross error that needs to be fixed. Best regards from Austria Juergen -- /?\ No | \ / HTML | Juergen Bruckner X in | juergen at bruckner.email / \ Mail | -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From andrewg at andrewg.com Mon Jan 18 13:17:16 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 18 Jan 2021 12:17:16 +0000 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <23eae403-62b8-71ff-d31d-f555c9c58f8a@bruckner.email> <36e3ef99-8564-4747-df8d-40a3e37c2b2f@andrewg.com> Message-ID: On 18/01/2021 11:33, Juergen Bruckner via Gnupg-users wrote: > Hello Andrew, > > Am 18.01.21 um 12:17 schrieb Andrew Gallagher via Gnupg-users: >> On 18/01/2021 11:07, Juergen Bruckner via Gnupg-users wrote: >>> Sequoia accepts an *invalid* certificate for the host >>> 'foo.abc.github.io' and that is "failure by design". >> >> This is incorrect. Sequoia *does not* accept this invalid >> certificate. Sequoia and gnupg only differ in their fallback >> behaviour after the certificate has been correctly rejected. >> > Yes I do understand that behavior, but that wasnt explained that way > by Stefan. > > And I have understood it so far that Stefan claims Sequoia recognizes > this certificate as valid and therefore continues to work. > > To my understanding, Stefen has not yet spoken of a "fallback". Stefan's understanding of the issue is incomplete; Neal's detailed explanation of 13th Jan above explains exactly what is going on, and it does not involve incorrectly accepting invalid certs. > He actually went so far, to urge Werner in a more than rude way to > add this (wrong) behavior into GnuPG. I agree that GnuPG is under no obligation to emulate Sequoia's behaviour here, although it would of course be preferable if a consensus could be arrived at. > For me personally, this is still a major obstacle to using Sequoia > productively or to recommend it to our customers. I still regard this > behavior as a gross error that needs to be fixed. I think this is unfair on Sequoia. They have deviated from a draft standard, but they have made a prima-facie case for doing so. Was this the correct decision? I don't know. Should this decision have been flagged more prominiently? Perhaps. But remember that WKD is a key discovery mechanism, not a validation mechanism. It is far from unreasonable to consider prioritising availability over correctness. Some things in security are absolutes, and some things are trade-offs. IMO this issue falls squarely in the "trade-off" category. Perhaps we could collectively take a breath before continuing. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From juergen at bruckner.email Mon Jan 18 13:37:42 2021 From: juergen at bruckner.email (Juergen Bruckner) Date: Mon, 18 Jan 2021 13:37:42 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <23eae403-62b8-71ff-d31d-f555c9c58f8a@bruckner.email> <36e3ef99-8564-4747-df8d-40a3e37c2b2f@andrewg.com> Message-ID: <5b224c1a-eb86-531c-ad78-eab869846c39@bruckner.email> Hello Andrew, Am 18.01.21 um 13:17 schrieb Andrew Gallagher via Gnupg-users: > On 18/01/2021 11:33, Juergen Bruckner via Gnupg-users wrote: >> Hello Andrew, >> >> Am 18.01.21 um 12:17 schrieb Andrew Gallagher via Gnupg-users: >>> On 18/01/2021 11:07, Juergen Bruckner via Gnupg-users wrote: >>>> Sequoia accepts an *invalid* certificate for the host >>>> 'foo.abc.github.io' and that is "failure by design". >>> >>> This is incorrect. Sequoia *does not* accept this invalid >>> certificate. Sequoia and gnupg only differ in their fallback >>> behaviour after the certificate has been correctly rejected. >>> >> Yes I do understand that behavior, but that wasnt explained that way >> by Stefan. >> >> And I have understood it so far that Stefan claims Sequoia recognizes >> ?this certificate as valid and therefore continues to work. >> >> To my understanding, Stefen has not yet spoken of a "fallback". > > Stefan's understanding of the issue is incomplete; Neal's detailed > explanation of 13th Jan above explains exactly what is going on, and it > does not involve incorrectly accepting invalid certs. > >> He actually went so far, to urge Werner in a more than rude way to >> add this (wrong) behavior into GnuPG. > > I agree that GnuPG is under no obligation to emulate Sequoia's behaviour > here, although it would of course be preferable if a consensus could be > arrived at. > >> For me personally, this is still a major obstacle to using Sequoia >> productively or to recommend it to our customers. I still regard this >> ?behavior as a gross error that needs to be fixed. > > I think this is unfair on Sequoia. They have deviated from a draft > standard, but they have made a prima-facie case for doing so. Was this > the correct decision? I don't know. Should this decision have been > flagged more prominiently? Perhaps. But remember that WKD is a key > discovery mechanism, not a validation mechanism. It is far from > unreasonable to consider prioritising availability over correctness. > > Some things in security are absolutes, and some things are trade-offs. > IMO this issue falls squarely in the "trade-off" category. Perhaps we > could collectively take a breath before continuing. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > I fully agree! nothing more to say! -- /?\ No | \ / HTML | Juergen Bruckner X in | juergen at bruckner.email / \ Mail | -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From andre at colomb.de Mon Jan 18 13:42:52 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Mon, 18 Jan 2021 13:42:52 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <87ture8v41.wl-neal@walfield.org> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> Message-ID: Hi Neal, On 18/01/2021 10.14, Neal H. Walfield wrote: > First, I don't think WKD is a strong authentication method. It is > sufficient for doing key discovery for opportunistic encryption (i.e., > it's a reasonable guess), but I wouldn't want someone to rely on it to > protect them from an active adversary, or phishing attempts. That's a very good point. In that regard, the spec should maybe present the two methods as equal alternatives to be tried in a standardized order until either one succeeds. Requiring to report configuration failures is really out of scope for a protocol at that level, and the end user can hardly do anything about it anyway. Nevertheless, a big fat warning in the log / console would be appropriate. > In short: I understand the motivation for the subdomain. I understand > why one should first check there. But, I think we do our users a > disservice by not falling back to the direct method in the case of > DNS errors. I suppose you mean other errors besides DNS? Whichever method was intended to be used, the (weak) trust anchor is always the returned DNS response, and therefore both methods would be equally screwed if a failure can be induced at that level. Pointing the DNS response for either example.com or openpgpkey.example.com to a malicious webserver is no different. Both would need to be done for e.g. the ACME (Let's Encrypt) verification server's perspective as well, which is harder than a local network attack. We need to remember that WKD is only a convenience mechanism for discovery, not any kind of authentication. Sending encrypted e-mail to a domain which was also used to retrieve the encryption public key adds no protection against MITM, but only transport obscurity. But that might still be better than no encryption at all, e.g. to set up an out-of-band key verification. Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lars.nooden at gmail.com Mon Jan 18 13:16:11 2021 From: lars.nooden at gmail.com (=?UTF-8?Q?Lars_Nood=c3=a9n?=) Date: Mon, 18 Jan 2021 14:16:11 +0200 Subject: Fundraising In-Reply-To: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> References: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> Message-ID: On 1/17/21 10:35 PM, Robert J. Hansen via Gnupg-users wrote: > ... And if you missed out, why not consider making a recurring > monthly contribution of your own? The text on the donation page could be tweaked to include the business address. That would save a few steps because the web form for Single Euro Payments Area credit transfers [1] ought to have the address [2] as the address is required when making payments to other countries within the Union. [1] https://www.gnupg.org/cgi-bin/procdonate.cgi [2] https://g10code.com/contact.html From wk at gnupg.org Mon Jan 18 14:46:44 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Jan 2021 14:46:44 +0100 Subject: Fundraising In-Reply-To: ("Lars =?utf-8?Q?Nood=C3=A9n?= via Gnupg-users"'s message of "Mon, 18 Jan 2021 14:16:11 +0200") References: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> Message-ID: <87wnwae4sb.fsf@wheatstone.g10code.de> On Mon, 18 Jan 2021 14:16, Lars Nood?n said: > Euro Payments Area credit transfers [1] ought to have the address [2] > as the address is required when making payments to other countries > within the Union. The idea of SEPA is that the account number is sufficient; even the BIC is not anymore needed nor are banks required to check name or any other data. Are you living the the SEPArea? 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 lars.nooden at gmail.com Mon Jan 18 15:29:40 2021 From: lars.nooden at gmail.com (=?UTF-8?Q?Lars_Nood=c3=a9n?=) Date: Mon, 18 Jan 2021 16:29:40 +0200 Subject: Fundraising In-Reply-To: <87wnwae4sb.fsf@wheatstone.g10code.de> References: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> <87wnwae4sb.fsf@wheatstone.g10code.de> Message-ID: On 1/18/21 3:46 PM, Werner Koch wrote: > On Mon, 18 Jan 2021 14:16, Lars Nood?n said: > >> Euro Payments Area credit transfers [1] ought to have the address [2] >> as the address is required when making payments to other countries >> within the Union. > > The idea of SEPA is that the account number is sufficient; even the BIC > is not anymore needed nor are banks required to check name or any other > data. Are you living the the SEPArea? Yes, but that did not stop the bank's payment web interface from requiring the name and address for payments to other countries. For that matter, their "new" web interface takes over 10 seconds for any given page to load due to dependencies, but that is a different topic for elsewhere. Anyway, thanks for GNUpg. /Lars From neal at walfield.org Mon Jan 18 15:50:15 2021 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 18 Jan 2021 15:50:15 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> Message-ID: <87mtx68fko.wl-neal@walfield.org> On Mon, 18 Jan 2021 13:42:52 +0100, Andr? Colomb wrote: > On 18/01/2021 10.14, Neal H. Walfield wrote: > > In short: I understand the motivation for the subdomain. I understand > > why one should first check there. But, I think we do our users a > > disservice by not falling back to the direct method in the case of > > DNS errors. > > I suppose you mean other errors besides DNS? Right, sorry! > We need to remember that WKD is only a convenience mechanism for > discovery, not any kind of authentication. Sending encrypted e-mail to > a domain which was also used to retrieve the encryption public key adds > no protection against MITM, but only transport obscurity. But that > might still be better than no encryption at all, e.g. to set up an > out-of-band key verification. I agree. From angel at pgp.16bits.net Mon Jan 18 16:47:38 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Mon, 18 Jan 2021 16:47:38 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <87ture8v41.wl-neal@walfield.org> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> Message-ID: On 2021-01-18 at 10:14 +0100, Neal H. Walfield wrote: > I've given this issue some more thought. > > First, I don't think WKD is a strong authentication method. It is > sufficient for doing key discovery for opportunistic encryption (i.e., > it's a reasonable guess), but I wouldn't want someone to rely on it to > protect them from an active adversary, or phishing attempts. > > If you consider WKD to be a strong authentication mechanism, then you > are basically relying on X.509 plus a bit of brittleness (the > certificates aren't signed, only the TLS session is). So, if that's > your position, then just use S/MIME. Hi Neal I have been also giving some thought to this in the recent days. I think the issue here is the lack of a defined policy. Each user may have a completely different policy, but that would affect how this should be treated. In some cases, the user trust on the key will just be inherited from the https certificate of the sate where it was published. In others, the key will be completely validated through WoT. So, while in the first case a bad certificate would be a critical failure, in the second the right thing would be to fetch the key *even if the certificate was invalid*, as it is used purely for discovery. There is also the trust on the https CA itself. Which https CA should the client trust? The https certificate was signed by a private CA, you might not trust certain web CA for WKD, or you could want to augment that set with e.g. the sks-keyservers CA. We usually consider the OpenPGP keys as standalone entities, but the client could be tagging the received keys: "received from keyserver X", fetched via WKD (openpgpkey.foo.com) on $DATE, retrieved through WKD using a broken https certificate, certificate validated with PKI, with DANE, etc. A client could be configured to take all of that into account for computing the key trust in a way consistent with its user opinion. All of that complexity for then having the end user, in almost every case, merrily re-sending it in plain text if asked to. ?\_(?)_/? Some other related ideas that crossed my mind: - If you are allowing certificates, that an unknown CA (or maybe are even self-signed), should the client insist in that the certificate matches the presented hostname? - Should the client attempt to detect openpgpkey wildcard records and ignore the advanced method in such case? (this also covers ISP hijacking NXDOMAIN, which I also thought in) While it's easy to detect when this seems to be the case, that's still an heuristic, and why should I be prevented from serving WKD from a wildcard dns record if I want to ? - An idea that seems worth considering, inspired by the way flowcrypt does its check, is to fall back to the direct method if the openpgpkey subdomain exists but it doesn't serve a policy file. This would solve the issue of non-malicious NXDOMAIN hijackings or DNS wildcards (assuming the certificate was valid). (...) > This attack is likely to go unnoticed, firstly because most key > discovery is done in the background, and probably shouldn't actively > show errors messages to the user. But, more importantly, because > nothing else uses the openpgpkeys subdomain, everything else will > still appear to work! How do you envision the users to use WKD? I would generally expect key retrieval to be a manual action, performed either from command line or a GUI client, but in both cases it would be possible to show a diagnostic about the non-working WKD.* And, even if the MUA was configured to automatically fetch the recipients key every time, it still needs a way to report back whether the message will be sent encrypted, there is no key or it isn't trusted. Unless OpenPGP is being used in a purely opportunistic way. * However, an attack where your DNS server returned a fake NXDOMAIN would be very hard to detect. Best regards ?ngel From spam.trap.mailing.lists at gmail.com Mon Jan 18 17:12:56 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Mon, 18 Jan 2021 17:12:56 +0100 Subject: WKD Checker In-Reply-To: <87y2gq8zir.wl-neal@walfield.org> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> Message-ID: On Mon, Jan 18, 2021 at 8:43 AM Neal H. Walfield wrote: > > On Sun, 17 Jan 2021 19:27:05 +0100, > ?ngel wrote: > > I feel there is a need for a proper wkd test suite (as well as a > > clarifying on the draft itself the things that are coming up). > > FWIW, there is Wiktor Kwapisiewicz's wkd checker: > > https://gitlab.com/wiktor-k/wkd-checker > https://wkd.sequoia-pgp.org/ > > This is more for checking a WKD setup than checking a WKD client. > > I'm sure he'd be open to issues for things that he missed. > > :) Neal Hi Neal, thanks for chiming in here again, which you normally have not to do and instead you could enjoy popcorn while reading this thread. :-) I like to leave this reply here as my last post, while I know this Mailing List is thankfully mirrored ... and links to this whole thread are also floating around in the Internet, in related forums. I repeat here once again GitHub has a *valid* SSL cert. If GnuPG and gpg4win can not handle properly the direct-method, e.g. a fallback if *for* GnuPG or gpg4win a certificate is '?nvalid' and sequoia-pgp, Mailvelope etc. can use the direct-method than it should tell us something. As understood Damien jumped in yesterday to explain why some JavaScript kiddies asked for a sub.sub openpgpkey domain support (Remember the *EU funded* openpgp.js) library used in Mailvelope can handle my github.io key. Let's also assume that Werner, in his ivory tower, 'protected' by the *Old* Guard is correct and I am now officially known as retard, or whatever people like to call me, GitHub would make changes to their IT infrastructure, so that according to a *draft* GnuPG and gpg4win can handle this, what happens if I invent tomorrow WKD for S/MIME and WKD for NaClbox according to Werner's current *draft*, because many people would like it. Should GitHub do then changes *again*? Neal, maybe you and your team, as professionals, can explain what the .well-kown folder in a Web root is good for, because it is not only used for WKD and it is also used by many many apps, for verification purposes, like one can see in my GitHub project folder, regarding Brave verification and one can see that a .well-known folder serves it's purpose for the direct method if one tries Wictor's fine WKD checker with stefan.sac001.github.io. I finish now and I am very thankful that you jumped in for clarification, which you should had not to do and also thanks do dkg for suggesting clarification on dev.gnupg.org. Best regards Stefan From andre at colomb.de Mon Jan 18 21:04:03 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Mon, 18 Jan 2021 21:04:03 +0100 Subject: WKD Checker In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> Message-ID: <78da8c5d-e7de-4540-29d4-39d0f7dccb83@colomb.de> Hi Stefan, On 18/01/2021 17.12, Stefan Claas via Gnupg-users wrote: > I repeat here once again GitHub has a *valid* SSL cert. You are right on that point. Absolutely right, seriously. It's actually their web server configuration which is suboptimal. Those two statements are universally true, while the rest of this thread was only applicable to a specific context :-) Good night. Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stefan at ctemplar.com Mon Jan 18 00:43:11 2021 From: stefan at ctemplar.com (Stefan Claas) Date: Sun, 17 Jan 2021 23:43:11 -0000 Subject: WKD proper behavior on fetch error In-Reply-To: <024e22ec-3a77-2786-261a-bea6b5aeebec@colomb.de> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <024e22ec-3a77-2786-261a-bea6b5aeebec@colomb.de> Message-ID: <616a8a42544340b2aeb8c825b6aa92d3-stefan@ctemplar.com> @Stefan, are you aware that in your scheme involving sac001.github.io,whoever convinces GitHub to give them control over that subdomain, cansilently replace those public keys and start a man-in-the-middle attack?You could not even rely on the TLS layer, because GitHub probably willnot revoke their wildcard certificate just for you. Hijacking a GitHubPages user name seems more likely than taking over a well secured domainhosting account.I encountered only one MITM attack a couple of years ago so far, from anSKS user. He was a retired police officer from Austria, who contacted me.But what you say I was thinking about as well. My proposal was to includein the policy file fingerprint(s) of key(s) and generate an .ots file, fromopentimestamps.org, from the policy file and put that .ots file somewhere.In the old days it was common, prior starting encrypted comms to comparefingerprints over other channels.And regarding secure domains, would you consider VPS servers securetoo for WKD?I must say good night now.?BTW. I did not received yet your reply for my two other accounts, hence thelate reply.Best regardsStefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg at raf.org Tue Jan 19 00:11:58 2021 From: gnupg at raf.org (raf) Date: Tue, 19 Jan 2021 10:11:58 +1100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> Message-ID: <20210118231158.2gkas6ojrcxmtiex@raf.org> On Mon, Jan 18, 2021 at 01:42:52PM +0100, Andr? Colomb wrote: > We need to remember that WKD is only a convenience mechanism for > discovery, not any kind of authentication. > > Kind regards > Andr? And it's discovery that begins with an email address. I still can't work out what functionality WKD provides in a situation that isn't email-related. If you have a non email-related use case for obtaining a key, why use a non-functioning email address lookalike as a label for the key, and then require the user to use WKD client software to obtain the key, when you could even more easily just give the user a URL which can act as the label for the key, and the user could then use any simple HTTP client to obtain the key. In other words, when there is no email address, there is no link between an email address's domain and a website with the same domain (and a presumed connection between the administration of the email and web services for that domain), what functionality does WKD actually provide? It's the existence of a working email address that the user already possesses, in combination with the presumed link between the administration of a mail service and a web service, that make WKD able to provide discovery that is automatic and reliable. Without all of the above, there is no discovery, reliable or otherwise, and it's not automatic, because the user has to obtain the label first somehow. If you have to give the user a special new label that they don't already possess (because it isn't a natural email address), why can't that label be a URL instead? Why do they need special WKD software when they could use any HTTP client? What does the user gain from it? What does the key owner gain from it? Forgive me if I'm being ignorant and unimaginative, and perhaps I should just stop trying to understand, but it looks to me like a case of finding a hammer, and things starting to look more and more nail-like. There should be some benefit to be had from the additional complexity of using WKD in the absence of email, but I can't see what it is, and it hasn't been explained (unless I missed that). cheers, raf From angel at pgp.16bits.net Tue Jan 19 02:07:48 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Tue, 19 Jan 2021 02:07:48 +0100 Subject: The meaning of /.well-known/ (was: WKD Checker) In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> Message-ID: <0bf4f8e9f978770d36dd5d05a2817b641a99175b.camel@16bits.net> On 2021-01-18 at 17:12 +0100, Stefan Claas via Gnupg-users wrote: > Neal, maybe you and your team, as professionals, can explain > what the .well-kown folder in a Web root is good for, because > it is not only used for WKD and it is also used by many many > apps, for verification purposes, like one can see in my GitHub > project folder, regarding Brave verification and one can see > that a .well-known folder serves it's purpose for the direct > method if one tries Wictor's fine WKD checker with > stefan.sac001.github.io. Well-known URIs were defined nearly 11 years ago in rfc5785 (now obsoleted by rfc 8615), see https://tools.ietf.org/html/rfc5785 Basically, the /.well-known/ path introduces a namespace with a semantic for other protocols. Thus, example.com/.well-known/openpgpkey/ has a meaning for Web Key Directory. http://example.com/.well- known/acme-challenge/ is used for Automatic Certificate Management Environment (ACME) [rfc 8555], example.com/.well-known/mta-sts.txt is used to request that all emails are sent with SMTP encryption (rfc8461) and so on. Compare this with an url like https://example.com/cat, which has no special meaning. That could talk about your pet, an essay about the felis catus, a telecom operator in Thailand, a minecraft song, an Indian entrance exam, a UNIX program, a psychological therapy, the Catalan language, a unit of US Secret Service, a time zone, or the name of your significant other. If a new protocol wanted to use with an special meaning an url you were already using for the above, perfectly fine, content you would be understandably upset (and the new protocol could easily get confused by the existing pages). Reserving a portion of the namespace for these uses allows separating this. You can have a look at the multiple things it is used for at the corresponding IANA registry: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml Best regards From angel at pgp.16bits.net Tue Jan 19 02:33:32 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Tue, 19 Jan 2021 02:33:32 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <616a8a42544340b2aeb8c825b6aa92d3-stefan@ctemplar.com> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <024e22ec-3a77-2786-261a-bea6b5aeebec@colomb.de> <616a8a42544340b2aeb8c825b6aa92d3-stefan@ctemplar.com> Message-ID: <02aef74f20bfaef65033d10ec837378de694212e.camel@16bits.net> On 2021-01-17 at 23:43 +0000, Stefan Claas via Gnupg-users wrote: > I encountered only one MITM attack a couple of years ago so far, from an > SKS user. He was a retired police officer from Austria, who contacted me. > But what you say I was thinking about as well. My proposal was to include > in the policy file fingerprint(s) of key(s) and generate an .ots file, from > opentimestamps.org, from the policy file and put that .ots file somewhere. > In the old days it was common, prior starting encrypted comms to compare > fingerprints over other channels. If you can safely publish that ots file, you could as well publish your openpgp key in the same place. And if you are exchanging fingerprints over a separate, secure channel, you can use that to directly verify/fetch the key. (It often makes sense to publish it in many redundant ways, but strictly it _shouldn't_ be needed) Best regards From wk at gnupg.org Tue Jan 19 09:24:46 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Jan 2021 09:24:46 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <20210118231158.2gkas6ojrcxmtiex@raf.org> (raf via Gnupg-users's message of "Tue, 19 Jan 2021 10:11:58 +1100") References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <20210118231158.2gkas6ojrcxmtiex@raf.org> Message-ID: <87lfcpe3ld.fsf@wheatstone.g10code.de> On Tue, 19 Jan 2021 10:11, raf said: > And it's discovery that begins with an email address. I > still can't work out what functionality WKD provides in > a situation that isn't email-related. The Web Key Directory maps mail addresses to a key. Mail addresses are universal identifiers and thus they can be used in most context where you need to lookup a key which is not under the control of your organization. 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 neal at walfield.org Tue Jan 19 09:28:16 2021 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 19 Jan 2021 09:28:16 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> Message-ID: <87bldl8h5r.wl-neal@walfield.org> On Mon, 18 Jan 2021 16:47:38 +0100, ?ngel wrote: > So, while in the first case a bad certificate would be a critical > failure, in the second the right thing would be to fetch the key > *even if the certificate was invalid*, as it is used purely for > discovery. When you look up the openpgpkey.example.org domain, you are revealing to anyone snooping DNS traffic that you are using OpenPGP and are looking for a key related to example.org. That's a privacy issue. When you send the HTTP GET request, you reveal what email address you are interested in (yes, it is obfuscated by the hash, but that can often be broken using a dictionary attack). That's an even bigger privacy issue. Given how easy it is to get a valid TLS certificate using Let's Encrypt, I think it is better to flatout reject invalid TLS certificates. > - Should the client attempt to detect openpgpkey wildcard records and > ignore the advanced method in such case? (this also covers ISP > hijacking NXDOMAIN, which I also thought in) > While it's easy to detect when this seems to be the case, that's still > an heuristic, and why should I be prevented from serving WKD from a > wildcard dns record if I want to ? It's an interesting idea. But I'm afraid that it really complicates the WKD client's implementation for marginal security improvements. > - An idea that seems worth considering, inspired by the way flowcrypt > does its check, is to fall back to the direct method if the openpgpkey > subdomain exists but it doesn't serve a policy file. > > This would solve the issue of non-malicious NXDOMAIN hijackings or DNS > wildcards (assuming the certificate was valid). That's a neat idea. > How do you envision the users to use WKD? I would generally expect key > retrieval to be a manual action, performed either from command line or > a GUI client, but in both cases it would be possible to show a > diagnostic about the non-working WKD.* And, even if the MUA was > configured to automatically fetch the recipients key every time, it > still needs a way to report back whether the message will be sent > encrypted, there is no key or it isn't trusted. Unless OpenPGP is being > used in a purely opportunistic way. First, I'd regularly refresh keys in the background using all available methods (WKD, multiple keyservers, gpg sync-style key lists) using something like parcimonie: https://github.com/EtiennePerot/parcimonie.sh Second, for key discovery, there are two main types of users. For security-sensitive users (people whose threat model includes dying if this type of information is revealed), we should probably make key discovery via WKD a manual operation. For privacy-sensitive users, I'd just transparently, and automatically look for a key when the user types in an email address. For a bit more privacy, one could wait until the user presses send so that any WKD lookup will normally immediately be followed by an SMTP connection to the same domain. If key discovery fails, the MUA could show an error ("can't encrypted, because..."), or just send the message unencrypted, like Signal. :) Neal From neal at walfield.org Tue Jan 19 09:51:14 2021 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 19 Jan 2021 09:51:14 +0100 Subject: WKD Checker In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> Message-ID: <878s8p8g3h.wl-neal@walfield.org> On Mon, 18 Jan 2021 17:12:56 +0100, Stefan Claas wrote: > I repeat here once again GitHub has a *valid* SSL cert. You're right. github has a valid TLS certificate. But that valid TLS certificate is not valid for openpgpkey.sac001.github.io. That's just the way it is, sorry. :) Neal From wk at gnupg.org Tue Jan 19 11:11:52 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Jan 2021 11:11:52 +0100 Subject: Please tackle the Right Thing (was: WKD Checker) In-Reply-To: (Stefan Claas via Gnupg-users's message of "Mon, 18 Jan 2021 17:12:56 +0100") References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> Message-ID: <877do9dymv.fsf_-_@wheatstone.g10code.de> Stefan, It has been mentioned several time here that the use of the openpgpkey sub-domain is required to allow implementation of the Web Key Directory in browsers. This is a real world use case and pretty important for web mailers like protonmail. I would suggest that you put your energy on a useful task instead of confusing people here with crude arguments why we should support invalid X.509 certificates for TLS connections. Thus go for Google and Mozilla and convince them that SRV records are important for many applications. That is not just for the Web Key Directory but also for XMPP clients in a browser and many other modern protocols. After that as been achieved we can eventually migrate back to SRV records. 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 Tue Jan 19 11:26:45 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Jan 2021 11:26:45 +0100 Subject: Fundraising In-Reply-To: ("Lars =?utf-8?Q?Nood=C3=A9n?= via Gnupg-users"'s message of "Mon, 18 Jan 2021 16:29:40 +0200") References: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> <87wnwae4sb.fsf@wheatstone.g10code.de> Message-ID: <87zh15cjdm.fsf@wheatstone.g10code.de> On Mon, 18 Jan 2021 16:29, Lars Nood?n said: > Yes, but that did not stop the bank's payment web interface from > requiring the name and address for payments to other countries. For Okay, I added our address to the SEPA 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 Tue Jan 19 13:08:19 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Jan 2021 13:08:19 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <87bldl8h5r.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 19 Jan 2021 09:28:16 +0100") References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> Message-ID: <87pn21ceoc.fsf@wheatstone.g10code.de> On Tue, 19 Jan 2021 09:28, Neal H. Walfield said: > When you look up the openpgpkey.example.org domain, you are revealing > to anyone snooping DNS traffic that you are using OpenPGP and are > looking for a key related to example.org. That's a privacy issue. No, it isn't. The next thing you do is to send the mail and get a reply. Get real. 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 spam.trap.mailing.lists at gmail.com Tue Jan 19 16:31:25 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 19 Jan 2021 16:31:25 +0100 Subject: Please tackle the Right Thing (was: WKD Checker) In-Reply-To: <877do9dymv.fsf_-_@wheatstone.g10code.de> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> Message-ID: On Tue, Jan 19, 2021 at 11:15 AM Werner Koch wrote: > > Stefan, > > It has been mentioned several time here that the use of the openpgpkey > sub-domain is required to allow implementation of the Web Key Directory > in browsers. This is a real world use case and pretty important for web > mailers like protonmail. > > I would suggest that you put your energy on a useful task instead of > confusing people here with crude arguments why we should support invalid > X.509 certificates for TLS connections. > > Thus go for Google and Mozilla and convince them that SRV records are > important for many applications. That is not just for the Web Key > Directory but also for XMPP clients in a browser and many other modern > protocols. After that as been achieved we can eventually migrate back > to SRV records. Hello Werner, What you or maybe other people here do not get, I accept that there is for the advanced-method a requirement to use an openpgpkey subdomain part, which a) is triggered first and b) as understood by Damien's reply was asked for by some JavaScript programmers. This is perfectly fine! *But* when there exists also a direct-method in you current draft, which people like to use, when low on budged or which like to avoid, for whatever privacy reasons they have, the openpgpkey subdomain part, they should be IMHO allowed to use the direct-method only or at least GnuPG and gpg4win should fallback to this method, if a cert error, according to GnuPG's or gpg4win's WKD implementation occurs. I guess this would be a <5 minute quick fix in your codebase. Please try also to not use the term invald cert, if a cert is valid and only is 'invalid' in the current way of how GnuPG and gpg4win handles your WKD implementation. People know now that other OpenPGP apps can handle my github.io key, from my GitHUb page. Best regards Stefan From spam.trap.mailing.lists at gmail.com Tue Jan 19 17:05:48 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 19 Jan 2021 17:05:48 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <02aef74f20bfaef65033d10ec837378de694212e.camel@16bits.net> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <024e22ec-3a77-2786-261a-bea6b5aeebec@colomb.de> <616a8a42544340b2aeb8c825b6aa92d3-stefan@ctemplar.com> <02aef74f20bfaef65033d10ec837378de694212e.camel@16bits.net> Message-ID: On Tue, Jan 19, 2021 at 2:36 AM ?ngel wrote: > > On 2021-01-17 at 23:43 +0000, Stefan Claas via Gnupg-users wrote: > > I encountered only one MITM attack a couple of years ago so far, from an > > SKS user. He was a retired police officer from Austria, who contacted me. > > But what you say I was thinking about as well. My proposal was to include > > in the policy file fingerprint(s) of key(s) and generate an .ots file, from > > opentimestamps.org, from the policy file and put that .ots file somewhere. > > In the old days it was common, prior starting encrypted comms to compare > > fingerprints over other channels. > > If you can safely publish that ots file, you could as well publish your > openpgp key in the same place. > > And if you are exchanging fingerprints over a separate, secure channel, > you can use that to directly verify/fetch the key. > > > (It often makes sense to publish it in many redundant ways, but > strictly it _shouldn't_ be needed) My thinking is the following, if there would be a consensus for this by the OpenPGP community, after discussing this, while currently not breaking the specs, it could be arranged like thisl: The submitting part of an policy file, containing the fingerprint(s) can be done even on a compromised online computer, because the policy file is immediately accepted by opentimestamps.org and others and then included in the Bitcoin blockchain. As suggestion, for easy implementation,, for WKD clients, could be that then the policy.ots file is placed in the same directory the policy file resides. A policy file could look like this, with remark lines at the beginning: # WKD policy for sac001.github.io # Maintainer: Stefan Claas, stefan at sac001.github.io # Updated: current date of last update. fingerprint #1 fingerprint #2 etc. A WKD client could then fetch with an additional --all parameter all three files and save them in the current working directory, e.g pub key, policy file and policy.ots, thus allowing a WKD users to quickly check, if desired, to compare the downloaded data with the sha256 hash at opentimestamp.org and others. To make it for Mallory harder to exchange the whole directory a WKD user could for example put in his MUA/NUA .signature file the following: WOH sha256 hash. instead of gpg pub key availabe at etc. WOH = WKD-OTS-Hash And a WKD client could do this as CLI app: wkd get [--all] alice at example.com Well, only a proposal. Best regards Stefan From wk at gnupg.org Tue Jan 19 17:13:18 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Jan 2021 17:13:18 +0100 Subject: [Announce] Libgcrypt 1.9.0 relased Message-ID: <87k0s8dhwh.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of Libgcrypt version 1.9.0. This release starts a new stable branch of Libgcrypt with full API and ABI compatibility to the 1.8 series. Over the last 3 or 4 years Jussi Kivilinna put a lot of work into speeding up the algorithms for the most commonly used CPUs. See below for a list of improvements and new features in 1.9. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in Libgcrypt 1.9.0 ------------------------------------- * New and extended interfaces: - New curves Ed448, X448, and SM2. - New cipher mode EAX. - New cipher algo SM4. - New hash algo SM3. - New hash algo variants SHA512/224 and SHA512/256. - New MAC algos for Blake-2 algorithms, the new SHA512 variants, SM3, SM4 and for a GOST variant. - New convenience function gcry_mpi_get_ui. - gcry_sexp_extract_param understands new format specifiers to directly store to integers and strings. - New function gcry_ecc_mul_point and curve constants for Curve448 and Curve25519. [#4293] - New function gcry_ecc_get_algo_keylen. - New control code GCRYCTL_AUTO_EXPAND_SECMEM to allow growing the secure memory area. Also in 1.8.2 as an undocumented feature. * Performance: - Optimized implementations for Aarch64. - Faster implementations for Poly1305 and ChaCha. Also for PowerPC. [b9a471ccf5,172ad09cbe,#4460] - Optimized implementations of AES and SHA-256 on PowerPC. [#4529,#4530] - Improved use of AES-NI to speed up AES-XTS (6 times faster). [a00c5b2988] - Improved use of AES-NI for OCB. [eacbd59b13,e924ce456d] - Speedup AES-XTS on ARMv8/CE (2.5 times faster). [93503c127a] - New AVX and AVX2 implementations for Blake-2 (1.3/1.4 times faster). [af7fc732f9, da58a62ac1] - Use Intel SHA extension for SHA-1 and SHA-256 (4.0/3.7 times faster). [d02958bd30, 0b3ec359e2] - Use ARMv7/NEON accelerated GCM implementation (3 times faster). [2445cf7431] - Use of i386/SSSE3 for SHA-512 (4.5 times faster on Ryzen 7). [b52dde8609] - Use 64 bit ARMv8/CE PMULL for CRC (7 times faster). [14c8a593ed] - Improve CAST5 (40% to 70% faster). [4ec566b368] - Improve Blowfish (60% to 80% faster). [ced7508c85] * Bug fixes: - Fix infinite loop due to applications using fork the wrong way. [#3491][also in 1.8.4] - Fix possible leak of a few bits of secret primes to pageable memory. [#3848][also in 1.8.4] - Fix possible hang in the RNG (1.8.3 only). [#4034][also in 1.8.4] - Several minor fixes. [#4102,#4208,#4209,#4210,#4211,#4212] [also in 1.8.4] - On Linux always make use of getrandom if possible and then use its /dev/urandom behaviour. [#3894][also in 1.8.4] - Use blinding for ECDSA signing to mitigate a novel side-channel attack. [#4011,CVE-2018-0495] [also in 1.8.3, 1.7.10] - Fix incorrect counter overflow handling for GCM when using an IV size other than 96 bit. [#3764] [also in 1.8.3, 1.7.10] - Fix incorrect output of AES-keywrap mode for in-place encryption on some platforms. [also in 1.8.3, 1.7.10] - Fix the gcry_mpi_ec_curve_point point validation function. [also in 1.8.3, 1.7.10] - Fix rare assertion failure in gcry_prime_check. [also in 1.8.3] - Do not use /dev/srandom on OpenBSD. [also in 1.8.2] - Fix test suite failure on systems with large pages. [#3351] [also in 1.8.2] - Fix test suite to not use mmap on Windows. [also in 1.8.2] - Fix fatal out of secure memory status in the s-expression parser on heavy loaded systems. [also in 1.8.2] - Fix build problems on OpenIndiana et al. [#4818, also in 1.8.6] - Fix GCM bug on arm64 which troubles for example OMEMO. [#4986, also in 1.8.6] - Detect a div-by-zero in a debug helper tool. [#4868, also in 1.8.6] - Use a constant time mpi_inv and related changes. [#4869, partly also in 1.8.6] - Fix mpi_copy to correctly handle flags of opaque MPIs. [also in 1.8.6] - Fix mpi_cmp to consider +0 and -0 the same. [also in 1.8.6] - Fix extra entropy collection via clock_gettime. Note that this fallback code path is not used on any decent hardware. [#4966, also in 1.8.7] - Support opaque MPI with gcry_mpi_print. [#4872, also in 1.8.7] - Allow for a Unicode random seed file on Windows. [#5098, also in 1.8.7] * Other features: - Add OIDs from RFC-8410 as aliases for Ed25519 and Curve25519. [also in 1.8.6] - Add mitigation against ECC timing attack CVE-2019-13626. [#4626] - Internal cleanup of the ECC implementation. - Support reading EC point in compressed format for some curves. [#4951] For a list of interface changes and links to commits and bug numbers see the release info at https://dev.gnupg.org/T4294 Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at https://gnupg.org/download/mirrors.html. On the primary server the source tarball and its digital signature are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.0.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.0.tar.bz2.sig or gzip compressed: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.0.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.0.tar.gz.sig In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at https://gnupg.org/download/integrity_check.html. In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.9.0.tar.bz2 you would use this command: gpg --verify libgcrypt-1.9.0.tar.bz2.sig libgcrypt-1.9.0.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 libgcrypt-1.9.0.tar.bz2, you run the command like this: sha1sum libgcrypt-1.9.0.tar.bz2 and check that the output matches the first line from the this list: 459383a8b6200673cfc31f7b265c4961c0850031 libgcrypt-1.9.0.tar.bz2 25b36d1e3c32ef76be5098da721dd68933798a3d libgcrypt-1.9.0.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and if needed ask on the gcrypt-devel mailing list. In case of problems specific to this release please first check https://dev.gnupg.org/T4294 for updated information. Please also consult the archive of the gcrypt-devel mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html . We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and still mostly financed by donations. Three full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME, and Gpg4win. We like to thank all the nice people who are helping Libgcrypt, be it testing, coding, suggesting, auditing, administering the servers, spreading the word, or 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 and Libgcrypt in a good and secure shape and to address all the small and larger requests made by our users. Thanks. Happy hacking, Your Libgcrypt hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-devel'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: ed25519 2020-08-24 [expires: 2030-06-30] Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) 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) rsa2048 2011-01-12 [expires: 2021-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- "If privacy is outlawed, only outlaws will have privacy." - PRZ 1991 -------------- 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 spam.trap.mailing.lists at gmail.com Tue Jan 19 17:16:45 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 19 Jan 2021 17:16:45 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <024e22ec-3a77-2786-261a-bea6b5aeebec@colomb.de> <616a8a42544340b2aeb8c825b6aa92d3-stefan@ctemplar.com> <02aef74f20bfaef65033d10ec837378de694212e.camel@16bits.net> Message-ID: On Tue, Jan 19, 2021 at 5:05 PM Stefan Claas wrote: > A policy file could look like this, with remark lines at the > beginning: > > # WKD policy for sac001.github.io (WRONG) # WKD policy file for https://sac001.github.io > # Maintainer: Stefan Claas, stefan at sac001.github.io > # Updated: current date of last update. > fingerprint #1 > fingerprint #2 > etc. Regards Stefan From gnupg at eckner.net Tue Jan 19 17:24:02 2021 From: gnupg at eckner.net (Erich Eckner) Date: Tue, 19 Jan 2021 17:24:02 +0100 (CET) Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS Message-ID: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I'm playing around with my WKD setup (guess, why) and encountered the error in the subject when doing `gpg -vvvv --locate-external-keys erich at eckner.net`. Retrieving via curl and the manually-constructed url works fine, also I cannot find any problems in dns on that box. A second box shows the same behaviour, but on a third machine, it works. All three run the latest arch linux :-/ What can cause a "Connection closed in DNS" error? (Maybe the error message can be improved: Doesn't dns use udp by default, which is connectionless?) Cheers, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAHB6QACgkQCu7JB1Xa e1o5EBAAlwWivpw2CYX+FgWfFOqCVEy26uHpX6vbcUjG5F5hM54pxs7OUw+iFvOr i9lAWpIaFFpE9zE98U02caycNmrV6JvazrXb/NvmIxiAwVTbXGjoJxWF1+GzMow5 xhaUeeac+TzYDEC+4XdB1crWmWbe1EHbXuWzq6UGjCisaTKEqRk7Wtvj+XeeVbrH hjEHLySG53s5BmC8WlAzM7h+AeY6q6asmnMDPxtYSUAvErDsjtT/9X+UsVHp+Qrg JSfrLriVHEmTmJBpCsil/B7PIaOV4BhBy4+1qCWrytE/DZav+nz97TI+z6ZP40LC RCxEK1SHbSGNDrOoIzv8WddMRM3wpjlU1lDPlecgykKCWsu0X/Js64mpq1Ext6RV vEF94I399odyb2qJOv1icg8l7770BJyjqvgcIBV3QBPEKkSVpHCN3Pi8m2rO1Ahc hTHsBAeyDM4uqWHjfK+8UWxXe1464u6vyQ3SseWDqdFPVHXS4IkmUfEV9MUpAr0y UOfPEWID4Awmp/ZMs2pad4GSYhhY/Mqzy1WN3DAHs3O5WtZ9gTwHYnJOT8e3DE/V i3gRUmUBjCNIByq2cCTc764TK7B6q+J1No5euLy4QYqH/ZeHTqBEm35wqdae6SQs VorbRIhlXTHpMvR8vvr1xG2gnV2uA4s/3lOsaxv/5HLOFWpIyMY= =6cGU -----END PGP SIGNATURE----- From spam.trap.mailing.lists at gmail.com Tue Jan 19 17:41:43 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 19 Jan 2021 17:41:43 +0100 Subject: WKD Checker In-Reply-To: <878s8p8g3h.wl-neal@walfield.org> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <878s8p8g3h.wl-neal@walfield.org> Message-ID: On Tue, Jan 19, 2021 at 9:51 AM Neal H. Walfield wrote: > > On Mon, 18 Jan 2021 17:12:56 +0100, > Stefan Claas wrote: > > I repeat here once again GitHub has a *valid* SSL cert. > > You're right. github has a valid TLS certificate. But that valid TLS > certificate is not valid for openpgpkey.sac001.github.io. That's just > the way it is, sorry. Hi Neal, you don't have to say sorry ... because it is the way GnuPG and gpg4win handles this required openpgpkey subdomain part in their WKD advanced-method implementation, while I personally like the direct-method to use only, which according to Wiktor's WKD checker is properly set-up for my github.io page and most important it is working with sequoia-pgp and Mailvelope etc. :-) Best regards Stefan Best regards Stefan From spam.trap.mailing.lists at gmail.com Tue Jan 19 18:11:20 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 19 Jan 2021 18:11:20 +0100 Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> Message-ID: On Tue, Jan 19, 2021 at 5:24 PM Erich Eckner via Gnupg-users wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > I'm playing around with my WKD setup (guess, why) and encountered the > error in the subject when doing `gpg -vvvv --locate-external-keys > erich at eckner.net`. Retrieving via curl and the manually-constructed url > works fine, also I cannot find any problems in dns on that box. A second > box shows the same behaviour, but on a third machine, it works. All three > run the latest arch linux :-/ > > What can cause a "Connection closed in DNS" error? (Maybe the error > message can be improved: Doesn't dns use udp by default, which is > connectionless?) I did a quick check and according to Wiktor's WKD checker the direct-method says that key is missing and the advanced method seems to be ok. sq.exe can fetch your key and when I do a gpg --locate-keys erich at eckner.net it fetches also a couple of others from you (with differrent email addresses , which I must admit I do not understand why and would probably not need when communicating with you. Regards Stefan From gnupg at eckner.net Tue Jan 19 18:23:03 2021 From: gnupg at eckner.net (Erich Eckner) Date: Tue, 19 Jan 2021 18:23:03 +0100 (CET) Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> Message-ID: <32dffcd4-5786-ea81-2712-457b205517d5@eckner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Stefan, thanks for your answer. On Tue, 19 Jan 2021, Stefan Claas wrote: > On Tue, Jan 19, 2021 at 5:24 PM Erich Eckner via Gnupg-users > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Hi, >> >> I'm playing around with my WKD setup (guess, why) and encountered the >> error in the subject when doing `gpg -vvvv --locate-external-keys >> erich at eckner.net`. Retrieving via curl and the manually-constructed url >> works fine, also I cannot find any problems in dns on that box. A second >> box shows the same behaviour, but on a third machine, it works. All three >> run the latest arch linux :-/ >> >> What can cause a "Connection closed in DNS" error? (Maybe the error >> message can be improved: Doesn't dns use udp by default, which is >> connectionless?) > > I did a quick check and according to Wiktor's WKD checker the direct-method > says that key is missing and the advanced method seems to be ok. sq.exe can > fetch your key and when I do a gpg --locate-keys erich at eckner.net it > fetches also a couple of others from you (with differrent email addresses > , which I must admit I do not understand why and would probably not need > when communicating with you. Yes, this is the proper behaviour (which I also see on one machine of the three mentioned machines): Advanced method is set up, direct method is not. The key has multiple UIDs (one for each of my email addresses). Or did I do something wrong when exporting the key to the WKD? Should I have removed the other UIDs there? (how?) However, on two machines, I only get this strange "Connection closed in DNS" error. Ah, wait, I checked again, and one box says: "gpg: error retrieving 'erich at eckner.net' via WKD: Permission denied" Something is oddly wrong :-/ > > Regards > Stefan > regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAHFXgACgkQCu7JB1Xa e1rSvBAAttQc553QJAWAsjmSMEDAYp21pOiRLGcPEGInkhcF2DvQaLpW2Y4WQZR+ Xj+m8hOf3IbYPHs7k07Xqu35oD0KrXh//lPkZ0kben/EkY2TMzMjuwvZhW9KN9do QMiZJ8DfEiD2E88EliwqTDZoLsjpjtZLEfMjd0Cp/nk2r1LqPmLzYCDvjh2kxhyt 1W16B/xsnB9ITsb3odDcuGxRA4dPuWwuX9z1qIiInXqBFP39P4W/6Fi3aKPm1aOq Dir0uygAWDKytV7XNZlFsKqGc4ndOmj398LWHS0dSIg/EYOOS4O8ja/SGiacNKu+ l26DkWiECZk7FQDvKZuzCZbxbdSIej8fPa1m4adTCB0nR9XZCimg0EZHKlzfK/7A 88IPNq1UuMsTDimimROh0wR8ZZFRLFkEdMf/IB5pGE9nfOFhOc0sXIsmnO60ZoJa pmstR0mjuicDd0bsPHl3QDx9zTjqz5448MOCGfelBgfbxWVB4TmSKQxLqoqTmVyB 1z+fuDq+IjUzHt3RyjwebMOMZlwRuZjEvdwOFwz/+NdjqEHpX6z4sWpRlrZmyq7w vIL4lrdBUuOqCxZmkIbMZMVQOu+ZMoRzA44cvMZAIMhYoTvmL5NjzL6LWlMv0jRo pSk+QMFMnxoVFr/8ntlJN+vSjVuTHVgSUXrb1YltsWLfR2Uy4wg= =YNH1 -----END PGP SIGNATURE----- From spam.trap.mailing.lists at gmail.com Tue Jan 19 18:28:25 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 19 Jan 2021 18:28:25 +0100 Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: <32dffcd4-5786-ea81-2712-457b205517d5@eckner.net> References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <32dffcd4-5786-ea81-2712-457b205517d5@eckner.net> Message-ID: On Tue, Jan 19, 2021 at 6:26 PM Erich Eckner via Gnupg-users wrote: > Advanced method is set up, direct method is not. The key has multiple UIDs > (one for each of my email addresses). Or did I do something wrong when > exporting the key to the WKD? Should I have removed the other UIDs there? > (how?) Hi Erich, No, not wrong, but then WKD users would know your other email addresses as well, I would say. In case you like to avoid that I would check GnuPG for editing the key, e.g. removing the unwanted UIDs and then save and then export for WKD. Regards Stefan From spam.trap.mailing.lists at gmail.com Tue Jan 19 18:32:08 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 19 Jan 2021 18:32:08 +0100 Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <32dffcd4-5786-ea81-2712-457b205517d5@eckner.net> Message-ID: On Tue, Jan 19, 2021 at 6:28 PM Stefan Claas wrote: > > On Tue, Jan 19, 2021 at 6:26 PM Erich Eckner via Gnupg-users > wrote: > > > Advanced method is set up, direct method is not. The key has multiple UIDs > > (one for each of my email addresses). Or did I do something wrong when > > exporting the key to the WKD? Should I have removed the other UIDs there? > > (how?) > > Hi Erich, > > No, not wrong, but then WKD users would know your other email addresses > as well, I would say. In case you like to avoid that I would check GnuPG for > editing the key, e.g. removing the unwanted UIDs and then save and then > export for WKD. gpg [Optionen] --edit-key user-id [commands] Regards Stefan From spam.trap.mailing.lists at gmail.com Tue Jan 19 18:47:03 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 19 Jan 2021 18:47:03 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <024e22ec-3a77-2786-261a-bea6b5aeebec@colomb.de> <616a8a42544340b2aeb8c825b6aa92d3-stefan@ctemplar.com> <02aef74f20bfaef65033d10ec837378de694212e.camel@16bits.net> Message-ID: On Tue, Jan 19, 2021 at 5:16 PM Stefan Claas wrote: > > On Tue, Jan 19, 2021 at 5:05 PM Stefan Claas > wrote: > > > A policy file could look like this, with remark lines at the > > beginning: > > > > # WKD policy for sac001.github.io (WRONG) > # WKD policy file for https://sac001.github.io > > # Maintainer: Stefan Claas, stefan at sac001.github.io > > # Updated: current date of last update. > > fingerprint #1 > > fingerprint #2 > > etc. And I guess Alice or Bob would be quite happy that this looks GDPR compatible, e.g. only putting the fingerprints in the policy file ... :-) Regards Stefan From spam.trap.mailing.lists at gmail.com Tue Jan 19 19:06:41 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 19 Jan 2021 19:06:41 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <87pn21ceoc.fsf@wheatstone.g10code.de> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> Message-ID: On Tue, Jan 19, 2021 at 1:14 PM Werner Koch via Gnupg-users wrote: > > On Tue, 19 Jan 2021 09:28, Neal H. Walfield said: > > > When you look up the openpgpkey.example.org domain, you are revealing > > to anyone snooping DNS traffic that you are using OpenPGP and are > > looking for a key related to example.org. That's a privacy issue. > > No, it isn't. The next thing you do is to send the mail and get a > reply. Get real. I share the same sentiments as Neal, why? I am aware that the whole WWW can be scraped or searched in about a couple of minutes and let's say in my GitHub case I could imagine that for an explicit openpgpkey subdomain it could be possible to get all WKD directories, with an openpgpkey subdomain part, in case GitHub would do this (which they will hopefully not do.) And at least we have the direct-method for usage without an openpgpkey sub or sub-sub domain part. So why give WKD enthusiast not this option and out of curiousity please try to explain to us why the current draft say MUST and not MAY or SHOULD? I like to learn, because WKD is freaking cool with OpenPGP apps, like sequoia-pgp or Mailvelope etc. Best regards Stefan From spam.trap.mailing.lists at gmail.com Tue Jan 19 19:29:03 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 19 Jan 2021 19:29:03 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> Message-ID: On Tue, Jan 19, 2021 at 7:06 PM Stefan Claas wrote: > > On Tue, Jan 19, 2021 at 1:14 PM Werner Koch via Gnupg-users > wrote: > > > > On Tue, 19 Jan 2021 09:28, Neal H. Walfield said: > > > > > When you look up the openpgpkey.example.org domain, you are revealing > > > to anyone snooping DNS traffic that you are using OpenPGP and are > > > looking for a key related to example.org. That's a privacy issue. > > > > No, it isn't. The next thing you do is to send the mail and get a > > reply. Get real. > > I share the same sentiments as Neal, why? > > I am aware that the whole WWW can be scraped or searched in about > a couple of minutes and let's say in my GitHub case I could imagine > that for an explicit openpgpkey subdomain it could be possible to > get all WKD directories, with an openpgpkey subdomain part, in > case GitHub would do this (which they will hopefully not do.) > > And at least we have the direct-method for usage without an > openpgpkey sub or sub-sub domain part. So why give WKD > enthusiast not this option and out of curiousity please try to > explain to us why the current draft say MUST and not MAY > or SHOULD? I like to learn, because WKD is freaking cool > with OpenPGP apps, like sequoia-pgp or Mailvelope etc. Example: Mallory sitting in the United States likes to prepare a list (without my consent) and published on a U.S. site, so that like SKS key server dumps the whole world can obtain a list of all openpgpkey subdomains. So far so good. Mr 'edge case' Stefan knows this and counterstrikes with his domain radio-eriwan.su (which I own) and set's up for Mr Mallory a WKD direct-method dir with n dummy keys. Good luck Mr Mallory figuring out which domains have real OpenPGP users keys hosted and which not. Best regards Stefan From erich at eckner.net Tue Jan 19 20:07:28 2021 From: erich at eckner.net (Erich Eckner) Date: Tue, 19 Jan 2021 20:07:28 +0100 (CET) Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <32dffcd4-5786-ea81-2712-457b205517d5@eckner.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, 19 Jan 2021, Stefan Claas wrote: > On Tue, Jan 19, 2021 at 6:28 PM Stefan Claas > wrote: >> >> On Tue, Jan 19, 2021 at 6:26 PM Erich Eckner via Gnupg-users >> wrote: >> >>> Advanced method is set up, direct method is not. The key has multiple UIDs >>> (one for each of my email addresses). Or did I do something wrong when >>> exporting the key to the WKD? Should I have removed the other UIDs there? >>> (how?) >> >> Hi Erich, >> >> No, not wrong, but then WKD users would know your other email addresses >> as well, I would say. In case you like to avoid that I would check GnuPG for >> editing the key, e.g. removing the unwanted UIDs and then save and then >> export for WKD. > > gpg [Optionen] --edit-key user-id [commands] I checked the manual, and there is even a non-permanent solution: - --export-filter keep-uid="mbox = ..." lets you filter the exported uids :-) > > Regards > Stefan > regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAHLfEACgkQCu7JB1Xa e1rmjBAAvqUdx+hoqtg3lDWPUqQE69QtmmUgnxBSXPo4VJbFLQKccsog270mzJXh ccGbqYLHHpj5X0BfFWcIn/7UII7QRfscp8/lvt+IM7I5pHvGpGky21jrMgVhm6h7 VrnioKV97MgHZcFG1ihCOLI5txVL81efSulaS9akUkhB096nJy6j8G05L1ZUlLkJ q/ZwXaqdBH2aG9moHh0zCC0a7081FfwmBf120c9ZH9MmBHM47TPqDauI2/ECgi52 wB7LzaGPyvbQngGrxsD3aUTftOE+dq7XChp4kuiuIA4o5+rmJ/0umwdm8IBr324R mW9Cs/iSJcVA/XXuAIWSe5uFLgg2ZrqdeMA2HHQF90ElxnRsCeKYs9Bq3HIBqqEn zJ3DR5J87uUgsgLxEZfStCSVMz0nC5jpcP2Ycyv0qKpZ8zu15wBYl0GuUZ7SLQS8 Db21TerHsDr2RFvLj3K/YfVIIRxFJD7hZtP3hGW0+cuqQcyAGtbHbJm9Id5h0G2f 5EvpJGn4d6b6w2nsGGP5hQOQ99WYTnJGpjiUvQvOd+f06IQ76BgIZdMIlwENFlSt nY6du0KZKMHhiUOp5+nBFRIzqWpoI4NGvZAnHR16ClJVKNymIdMm6R/SsYlM5XHt rv6LtEotIF4b72pMhwAgckEOcAl2NM4UTLIOeWa5ZME03oKMypc= =g12g -----END PGP SIGNATURE----- From spam.trap.mailing.lists at gmail.com Tue Jan 19 23:51:39 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 19 Jan 2021 23:51:39 +0100 Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <32dffcd4-5786-ea81-2712-457b205517d5@eckner.net> Message-ID: On Tue, Jan 19, 2021 at 11:01 PM Erich Eckner via Gnupg-users wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > I checked the manual, and there is even a non-permanent solution: > > - --export-filter keep-uid="mbox = ..." > > lets you filter the exported uids :-) Cool :-) , I did not know this. Regards Stefan From angel at pgp.16bits.net Wed Jan 20 00:38:33 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Wed, 20 Jan 2021 00:38:33 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> Message-ID: <22faa6d19c271bb849ba46ce3bcac325039f6f6a.camel@16bits.net> On 2021-01-19 at 19:29 +0100, Stefan Claas wrote: > Example: Mallory sitting in the United States likes to prepare > a list (without my consent) and published on a U.S. site, > so that like SKS key server dumps the whole world can > obtain a list of all openpgpkey subdomains. So far so good. > > Mr 'edge case' Stefan knows this and counterstrikes with > his domain radio-eriwan.su (which I own) and set's up for > Mr Mallory a WKD direct-method dir with n dummy keys. > > Good luck Mr Mallory figuring out which domains have real > OpenPGP users keys hosted and which not. > > Best regards > Stefan A list of all (well, most) openpgpkey subdomains can be easily created. However, there is no need for or dummy keys. Mallory sees that radio-eriwan.su supports WKD (this is immediate, it doesn't matter if it uses the advanced or direct method). However, it can't ask for all keys it stores. Mallory will need to ask for every possible key: Do you have an OpenPGP key for a at radio-eriwan.su ? Do you have an OpenPGP key for b at radio-eriwan.su ? Do you have an OpenPGP key for c at radio-eriwan.su ? ? Do you have an OpenPGP key for z at radio-eriwan.su ? Do you have an OpenPGP key for aa at radio-eriwan.su ? Do you have an OpenPGP key for ab at radio-eriwan.su ? and so on until zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzz at radio-eriwan.su even if Mallory only checks email addresses with lowercase letters (although they are not the only allowed characters in an email address), he would need to ask for 5.8?10??? email addresses. Just for radio-eriwan.su This can be optimized by checking instead the full space of sha-1 hashes, to "only" perform 1.46?10?? requests (assuming the server doesn't validate the local part on WKD requests). Anyway, such attack is completely unrealistic. In order to get all keys Mallory would either need access to the server files (e.g. it compromised the server, or the contents are published in github), or the web server to have been (mis?)configured with Directory Listings. Best regards From angel at pgp.16bits.net Wed Jan 20 01:47:59 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Wed, 20 Jan 2021 01:47:59 +0100 Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> Message-ID: <198b470f1228d4b59ec891d86071620d1e7b3326.camel@16bits.net> On 2021-01-19 at 17:24 +0100, Erich Eckner via Gnupg-users wrote: > What can cause a "Connection closed in DNS" error? (Maybe the error > message can be improved: Doesn't dns use udp by default, which is > connectionless?) I think it means dns.c returned DNS_ECONNFIN [1], which gets converted to GPG_ERR_DNS_CLOSED in dns-stuff.c and is then libgpg-error describes as "Connection closed in DNS" I'm not sure if this error can happen when using UDP, but do note that you can also (and in some cases must) perform DNS queries using tcp. Best regards 1- https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=dirmngr/dns.c;h=3ac6a2d021288bf4124745b6e9567e665e09fe49;hb=93d5d7ea2a8b110b3ad88be25f2f67d706361e44#l360 2- https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=dirmngr/dns-stuff.c;h=cdda86d63086184bf09e8dce7d946989a61d14d0;hb=93d5d7ea2a8b110b3ad88be25f2f67d706361e44#l394 From angel at pgp.16bits.net Wed Jan 20 03:32:31 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Wed, 20 Jan 2021 03:32:31 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <87o8hkj2nn.fsf@fifthhorseman.net> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <87o8hkj2nn.fsf@fifthhorseman.net> Message-ID: <780b90f468c3e160b56121e2ed02a564cb0429f8.camel@16bits.net> Hello all First, I agree with Neal in considering there is a privacy leak in using WKD (with no analysis/mitigations). dkg has already provided an excelent explanation about this, and seems material directly usable into the Security Considerations section. As noted, the openpgpkey server sysadmin has direct access to the full email address being requested, not just because it would be trivial for them to undo the hashing for all the they have, but the local part is there ?l= query string (this was requested by protonmail in order to process the actual email). However, a network eavesdropper could as well obtain information about the keys being fetched. For a practical example, watch the (encrypted traffic) while you request the following keys: alice.missing at wkdtest.pgp.16bits.net alice.rsa at wkdtest.pgp.16bits.net alice.ecc at wkdtest.pgp.16bits.net The TLS 1.2 *encrypted* reply by the server is 250, 1474, 554. >From a recipient privacy point of view, you would ideally be connecting to a server which has many users (a domain with a single-user would immediately betray the recipient) which have openpgp keys (in this sense, a public keyserver accessed via hkps are great), and also that their keys are somewhat similar (e.g. all RSA 2048), so that they are not distinguishable on the wire. In this context, there would be a possible attack by tricking the user into making their key recognizable. If the aforementioned regime wanted to detect people writing to dissenting-newsroom at popularmailprovider.com, but not to anyone else at @popularmailprovider.com (let's assume mail clients now automatically perform WKD, so requesting a key from popularmailprovider.com is not a signal by itself), they could send an agent to provide to the people of dissenting-newsroom at popularmailprovider.com their key with his signature (or signed by all his friends), so that it stands out when requested. Of course, it would have been preferable for them to sign up at popularmailprovider.com with an account name which collides with dissenting-newsroom so they end up in the same bucket, and so they would be able to add content there at will. But SHA-1 preimage resistance makes that infeasible. A WKD server operator could protect from this by padding the result with other keys so that the actual key size is concealed. In order to simplify this, I would recommend stating that WKD clients must ignore a trailing block of nuls (not part of a pgp packet, obviously) so that keys can easily be padded without calculating openpgp packets. You can test this by requesting alice.padding at wkdtest.pgp.16bits.net (gnupg chokes on this, since it is expecting a valid packet) Note that doing this requires that the files are server with no compression, as otherwise padding with nuls wouldn't really be effective. Best regards PS: dkg email doesn't seem to have reached the list yet (only the one from Jan 15 appear in the archives), although later messages are already there. From spam.trap.mailing.lists at gmail.com Wed Jan 20 08:08:46 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 20 Jan 2021 08:08:46 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <22faa6d19c271bb849ba46ce3bcac325039f6f6a.camel@16bits.net> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <22faa6d19c271bb849ba46ce3bcac325039f6f6a.camel@16bits.net> Message-ID: On Wed, Jan 20, 2021 at 12:41 AM ?ngel wrote: > A list of all (well, most) openpgpkey subdomains can be easily created. Yes and I believe that what Neal and you (in your new posting) have explained makes it only worthwhile for Mallory to start his work, because he has such an openpgpkey list created. Anyways, even if creating and maintaining a list also for all domains (direct-method) why give him this opportunity, if it is so easy to do so for openpgpkey subdomains? There is a demand for openpgpkey, so it seems, which I have accepted, but you know my points (which I have outlined) in the whole thread that we should be allowed to have direct-method usage too, with GnuPG and gpg4win, without having cert errors in GnuPG and gpg4win's WKD implementation. Whatever the outcome of this thread will be, as long as other OpenPGP apps work and will hopefully not change, so that this no longer works, people know now what they can do/use. Best regards Stefan From balducci at units.it Wed Jan 20 10:33:46 2021 From: balducci at units.it (balducci at units.it) Date: Wed, 20 Jan 2021 10:33:46 +0100 Subject: libgcrypt-1.9.0: 32 bit cross build fails on asm code Message-ID: <892.1611135250@dschgrazlin2.units.it> hello (my specs are enclosed below) just tried to cross-build 32 bit libgcrypt-1.9.0 on a 64 bit machine and getting: ----8<---- libtool: compile: gcc -m32 -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I../mpi -I../mpi -I/usr/include -I/usr/Xorg/include -fvisibility=hidden -fno-delete-null-pointer-checks -Wall -c rijndael-aesni.c -fPIC -DPIC -o .libs/rijndael-aesni.o rijndael-aesni.c: In function 'aesni_ocb_enc': rijndael-aesni.c:2815:7: error: 'asm' operand has impossible constraints 2815 | asm volatile ("pxor %[tmpbuf0],%%xmm1\n\t" | ^~~ make[3]: *** [Makefile:1355: rijndael-aesni.lo] Error 1 make[3]: Leaving directory '/home/balducci/tmp/install-us-d/libgcrypt-1.9.0.d/libgcrypt-1.9.0/cipher' ---->8---- No problem whatsoever building for native 64 bit. I get the same error (always for the 32 bit cross build) on two machines with different cpu's (both AMD, though) 32 bit build succeeds if I run with --disable-asm, but since it has worked flawlessly for ages (without --disable-asm), I'm just wondering if asm is not supported any longer for this cross build, or if 1.9.0 needs some fix (or if I am missing something obvious, of course) I haven't changed anything in my installation script (since 1.4.6). thanks in advance for any hint/help ciao -gabriele Configuring with: ================ --build=x86_64-unknown-linux-gnu --host=i686-pc-linux-gnu ----8<---- Libgcrypt v1.9.0 has been configured as follows: Platform: GNU/Linux (i686-pc-linux-gnu) Hardware detection module: libgcrypt_la-hwf-x86 Enabled cipher algorithms: arcfour blowfish cast5 des aes twofish serpent rfc2268 seed camellia idea salsa20 gost28147 chacha20 sm4 Enabled digest algorithms: crc gostr3411-94 md4 md5 rmd160 sha1 sha256 sha512 sha3 tiger whirlpool stribog blake2 sm3 Enabled kdf algorithms: s2k pkdf2 scrypt Enabled pubkey algorithms: dsa elgamal rsa ecc Random number generator: default Try using jitter entropy: yes Using linux capabilities: no Try using Padlock crypto: yes Try using AES-NI crypto: yes Try using Intel SHAEXT: yes Try using Intel PCLMUL: yes Try using Intel SSE4.1: yes Try using DRNG (RDRAND): yes Try using Intel AVX: yes Try using Intel AVX2: yes Try using ARM NEON: n/a Try using ARMv8 crypto: n/a Try using PPC crypto: n/a ---->8---- gcc -v: ====== Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/stow.d/versions/gcc-10.2.0/usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/balducci/tmp/install-us-d/gcc-10.2.0.d/gcc-10.2.0/configure --prefix=/opt/stow.d/versions/gcc-10.2.0/usr --libdir=/opt/stow.d/versions/gcc-10.2.0/usr/lib64 --libexecdir=/opt/stow.d/versions/gcc-10.2.0/usr/lib64 --enable-shared --disable-bootstrap --enable-languages=c,c++,objc,fortran --enable-multilib Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.0 (GCC) uname -srvmo: ============ Linux 5.9.8 #1 SMP Wed Nov 11 08:36:17 CET 2020 x86_64 GNU/Linux cat /proc/cpuinfo (machine 1): ============================= processor : 0 vendor_id : AuthenticAMD cpu family : 23 model : 113 model name : AMD Ryzen 5 3600 6-Core Processor stepping : 0 microcode : 0x8701021 cpu MHz : 4155.077 cache size : 512 KB physical id : 0 siblings : 6 core id : 0 cpu cores : 6 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 16 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca bugs : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass bogomips : 7200.27 TLB size : 3072 4K pages clflush size : 64 cache_alignment : 64 address sizes : 43 bits physical, 48 bits virtual power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14] cat /proc/cpuinfo (machine 2): ============================= processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 16 model name : AMD Athlon(tm) X4 740 Quad Core Processor stepping : 1 microcode : 0x6001116 cpu MHz : 2622.409 cache size : 2048 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass bogomips : 6400.21 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro From mettodo at riseup.net Wed Jan 20 09:41:10 2021 From: mettodo at riseup.net (mettodo) Date: Wed, 20 Jan 2021 11:41:10 +0300 Subject: make check failed tests Message-ID: Hey, 14 of 20 tests failed when doing "make check" for gnupg 2.2.27. What should I do? thanks! From wk at gnupg.org Wed Jan 20 13:33:10 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Jan 2021 13:33:10 +0100 Subject: libgcrypt-1.9.0: 32 bit cross build fails on asm code In-Reply-To: <892.1611135250@dschgrazlin2.units.it> (balducci's message of "Wed, 20 Jan 2021 10:33:46 +0100") References: <892.1611135250@dschgrazlin2.units.it> Message-ID: <878s8nbxfd.fsf@wheatstone.g10code.de> Hi! thanks for the report. I opened a ticket for this: https://dev.gnupg.org/T5257 Please check over there for status updates. (I accidently mentioned gnupg-users in the annoucement mail and not gcryypt-devel which would been the right one). 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 Jan 20 13:40:08 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Jan 2021 13:40:08 +0100 Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> (Erich Eckner via Gnupg-users's message of "Tue, 19 Jan 2021 17:24:02 +0100 (CET)") References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> Message-ID: <874kjbbx3r.fsf@wheatstone.g10code.de> On Tue, 19 Jan 2021 17:24, Erich Eckner said: > error in the subject when doing `gpg -vvvv --locate-external-keys Many -v don't really help here because the actual task is done by the dirmngr process. Thus to debug this put log-file /somewhere/dirmngr.log verbose debug ipc,network,dns into ~/.gnupg/dirmngr.conf and "gpgconf --kill dirmngr". The log file should give you a pretty good insight what's going on. You may also use log-file socket:// and run in another tty watchgnupg --time-only --force or with older version of gnupg watchgnupg --time-only --force $(gpgconf --list-dirs socketdir)/S.log If we can identify common error patterns in the diagnostics we can convey them to the gpg process to make debugging easier. 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 Wed Jan 20 13:51:26 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Jan 2021 13:51:26 +0100 Subject: Please tackle the Right Thing In-Reply-To: (Stefan Claas via Gnupg-users's message of "Tue, 19 Jan 2021 16:31:25 +0100") References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> Message-ID: <87zh13ai0h.fsf@wheatstone.g10code.de> On Tue, 19 Jan 2021 16:31, Stefan Claas said: > there exists also a direct-method in you current draft, which people like > to use, when low on budged or which like to avoid, for whatever privacy If you do some research on the infrastructure of large providers (which includes talking to them) you may learn that there might be an example.com address which is not under the control of the example company. However, SRV records and sub-domains are under their control. Thus not allowing the direct method if there is a sub-domain or SRV record is important. > Please try also to not use the term invald cert, if a cert is valid and only > is 'invalid' in the current way of how GnuPG and gpg4win handles your An X.509 certifiate used for TLS conenctions in the web must carry the server name. If it does not it is invalid. > WKD implementation. People know now that other OpenPGP apps can > handle my github.io key, from my GitHUb page. Broken implementations are not a reason to break correct implementations. 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 at eckner.net Wed Jan 20 14:46:08 2021 From: gnupg at eckner.net (Erich Eckner) Date: Wed, 20 Jan 2021 14:46:08 +0100 (CET) Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: <874kjbbx3r.fsf@wheatstone.g10code.de> References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <874kjbbx3r.fsf@wheatstone.g10code.de> Message-ID: <615d7260-d5fe-71f0-2510-5cb67b51b7@eckner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, 20 Jan 2021, Werner Koch wrote: > On Tue, 19 Jan 2021 17:24, Erich Eckner said: > >> error in the subject when doing `gpg -vvvv --locate-external-keys > > Many -v don't really help here because the actual task is done by the > dirmngr process. Thus to debug this put > > log-file /somewhere/dirmngr.log > verbose > debug ipc,network,dns > > into ~/.gnupg/dirmngr.conf and "gpgconf --kill dirmngr". The log file > should give you a pretty good insight what's going on. Thank you. I'm always confused by the different parts involved and how to properly increase verbosity :-) - From the log, I see, that _openpgpkey._tcp.eckner.net SRV is queried. This resolves to some old address (my DNS configuration error), which serves the wrong content. Is it right, that this SRV record should be queried? Should I update it or remove it? > > You may also use > > log-file socket:// > > and run in another tty > > watchgnupg --time-only --force > > or with older version of gnupg > > watchgnupg --time-only --force $(gpgconf --list-dirs socketdir)/S.log > I assume, this is for debugging *a lot* of gnupg in one place (like your work station, Werner). I'm totally happy with (temporarily) dumping log files in /tmp :-D > > If we can identify common error patterns in the diagnostics we can > convey them to the gpg process to make debugging easier. Ok, I understand. > > > Salam-Shalom, > > Werner Thank you for your help! Cheers, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAINCAACgkQCu7JB1Xa e1q3sQ/9EuJaERLiHdOqCYEXaqUu+O1Q7Tm7h6h9DLHLHykcJGs+XOK39XStmzTI 1XhHp5CRZJ+f88Dd98eJPSGcGCvnLauHBfyVJwq33TzgQQXzh3D88kpr9RrZjvc1 wLRiaQ3Mx4Jzk26Fmh56qrweQFGOq/RdXzvN45QatM4fSB6hdfB2+sV+RYU6yvpi ABqfFk/RHCnEZGDwI0Du2k6yfbIASgPJozJpVFLsiEv9OmK6IHibyQCOjcjSCBDs RvhRFeS2XrEfpktq+FPYRDuc5t6nnmbvTTk2agdoDaxnmr+LxBZJRSOG3NzcdzXJ Ikg3jOp9KU+Oq9cSijt8E/9wRYT/ukrzehH2j+fEqH62ypqtAU6dtTcX+6tKpZct QxYMxr/A+ovq/H68szfoC4WAZkX7baqj3IF53O8z6XZ4qv5611OA4DN7Tb9B8G97 QuZXu+30pbvrNigyLO/8RsX3KttFfB02md8DF/0NNGT91Ua2iYm1cu650Zl2dtkW TehKWvT6627+1FAL4WrQx5GAPetfiP34pyIXSUZyNhzozLCNAjeXh3RhNoMLgFI+ 5rTh0lwNYf/BqS35QOvHbE7pWR/c7OnzKyOsMDO8AdIPNz7WAXV+HTa9QXa8zrfj 4j7UQETYC9Df4FdLn4LCOpIlD3GuWfkMgvZ3q0lQqHzP4v9AfIU= =CIVf -----END PGP SIGNATURE----- From wk at gnupg.org Wed Jan 20 15:02:51 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Jan 2021 15:02:51 +0100 Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: <615d7260-d5fe-71f0-2510-5cb67b51b7@eckner.net> (Erich Eckner via Gnupg-users's message of "Wed, 20 Jan 2021 14:46:08 +0100 (CET)") References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <874kjbbx3r.fsf@wheatstone.g10code.de> <615d7260-d5fe-71f0-2510-5cb67b51b7@eckner.net> Message-ID: <87bldjaepg.fsf@wheatstone.g10code.de> On Wed, 20 Jan 2021 14:46, Erich Eckner said: > is queried. This resolves to some old address (my DNS configuration > error), which serves the wrong content. Is it right, that this SRV record > should be queried? Should I update it or remove it? Yes, the SRV record is used if there is no openpgpkeys sub-domain. The reason is that the original scheme was to use SRV records but we had to switch to a subdomain due to problems with browser based code. > I assume, this is for debugging *a lot* of gnupg in one place (like your Right. It is also cool to watch the diagnostccs fly by during regular use ;-) 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 spam.trap.mailing.lists at gmail.com Wed Jan 20 16:15:39 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 20 Jan 2021 16:15:39 +0100 Subject: Please tackle the Right Thing In-Reply-To: <87zh13ai0h.fsf@wheatstone.g10code.de> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> Message-ID: On Wed, Jan 20, 2021 at 1:55 PM Werner Koch wrote: > Broken implementations are not a reason to break correct > implementations. Since 'broken' implementations are available and can handle both cases, and this is now generally known, people do *not* need to follow a *draft* and can *happily* write code as they please to wish. Regards Stefan From ca+gnupg-users at esmtp.org Wed Jan 20 17:27:45 2021 From: ca+gnupg-users at esmtp.org (ca+gnupg-users at esmtp.org) Date: Wed, 20 Jan 2021 17:27:45 +0100 Subject: make check failed tests In-Reply-To: References: Message-ID: <20210120162745.GA36683@kiel.esmtp.org> On Wed, Jan 20, 2021, mettodo via Gnupg-users wrote: > 14 of 20 tests failed when doing "make check" for gnupg 2.2.27. What > should I do? Most certainly you should not tell anyone which OS or compiler or options you used. Neither should you include the actual test failures. From spam.trap.mailing.lists at gmail.com Wed Jan 20 18:42:14 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 20 Jan 2021 18:42:14 +0100 Subject: make check failed tests In-Reply-To: <20210120162745.GA36683@kiel.esmtp.org> References: <20210120162745.GA36683@kiel.esmtp.org> Message-ID: On Wed, Jan 20, 2021 at 6:11 PM wrote: > > On Wed, Jan 20, 2021, mettodo via Gnupg-users wrote: > > > 14 of 20 tests failed when doing "make check" for gnupg 2.2.27. What > > should I do? > > Most certainly you should not tell anyone which OS or compiler > or options you used. > Neither should you include the actual test failures. :-D :-D :-D ... Regards Stefan From andre at colomb.de Wed Jan 20 20:29:57 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Wed, 20 Jan 2021 20:29:57 +0100 Subject: Please tackle the Right Thing In-Reply-To: <87zh13ai0h.fsf@wheatstone.g10code.de> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> Message-ID: <7441f18a-8e59-3ec0-5b22-b535667bf38e@colomb.de> Hi all, after some more thought I came up with a possible wording to clarify the fallback behavior. Assuming that an opportunistic approach is preferred, so the direct method should be used not only based on the existence of openpgpkey as a SRV or other record. Here goes: ---SNIP--- (page 3, second paragraph in the current draft version 11) There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. If that does not conclude with a successful HTTP response (e.g. status code 2xx), they MUST fall back to the direct method. If the required sub-domain exists, but other errors occur during the connection, they SHOULD output an error message pointing out the failure reason to the end user. Such other errors include, for example, invalid, expired or misconfigured TLS certificates and HTTP failure codes (4xx or 5xx). ---SNIP--- The last "SHOULD" clause would allow for Sequoia's current behavior to silently switch over, but shows what the Right Way would encompass. Regarding GnuPG, the second "MUST" clause requires a change to fall back after later connection errors. I think that this logic still holds just in case SRV records are to be used again. So what do you think? I'm not subscribed to any IETF mailing lists, but feel free to propose this in the relevant circles. I hereby renounce my rights on the modified text :-) Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Wed Jan 20 21:21:32 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 20 Jan 2021 21:21:32 +0100 Subject: Please tackle the Right Thing In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> Message-ID: On Wed, Jan 20, 2021 at 4:15 PM Stefan Claas wrote: > > On Wed, Jan 20, 2021 at 1:55 PM Werner Koch wrote: > > > Broken implementations are not a reason to break correct > > implementations. > > Since 'broken' implementations are available and can handle both cases, > and this is now generally known, people do *not* need to follow a *draft* > and can *happily* write code as they please to wish. P.S. I would like to inform the community that I installed the lastest version of Mozilla Thunderbird, a couple of minutes ago, and guess what ... Thunderbird fetched my github.io properly with their WKD implemtentation. Regards Stefan From spam.trap.mailing.lists at gmail.com Wed Jan 20 21:31:02 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 20 Jan 2021 21:31:02 +0100 Subject: Please tackle the Right Thing In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> Message-ID: On Wed, Jan 20, 2021 at 9:21 PM Stefan Claas wrote: > > On Wed, Jan 20, 2021 at 4:15 PM Stefan Claas > wrote: > > > > On Wed, Jan 20, 2021 at 1:55 PM Werner Koch wrote: > > > > > Broken implementations are not a reason to break correct > > > implementations. > > > > Since 'broken' implementations are available and can handle both cases, > > and this is now generally known, people do *not* need to follow a *draft* > > and can *happily* write code as they please to wish. > > P.S. I would like to inform the community that I installed the lastest > version of Mozilla Thunderbird, a couple of minutes ago, and guess > what ... Thunderbird fetched my github.io pub key properly with their > WKD implemtentation. P.P.S. 78.6.1 from their offical web site and not a nightly build etc. Regards Stefan From angel at pgp.16bits.net Thu Jan 21 00:23:52 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Thu, 21 Jan 2021 00:23:52 +0100 Subject: ctf-like WKD challenge (was: WKD proper behavior on fetch error) In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <22faa6d19c271bb849ba46ce3bcac325039f6f6a.camel@16bits.net> Message-ID: On 2021-01-20 at 08:08 +0100, Stefan Claas via Gnupg-users wrote: > On Wed, Jan 20, 2021 at 12:41 AM ?ngel wrote: > > > A list of all (well, most) openpgpkey subdomains can be easily > > created. > > Yes and I believe that what Neal and you (in your new posting) have > explained makes it only worthwhile for Mallory to start his work, > because he has such an openpgpkey list created. No, no, no. The idea of my previous mail, was *precisely* that there is no point for Mallory to do that. Counting wkd servers can be interesting for statistics, measuring adoption, etc. but that would be of no use for an attacker. Ok, let's frame it a bit different. I will give a game for you. Last night, I prepared the domain wkdtest.pgp.16bits.net It is a valid wkd server. I have just created and uploaded there a new pgp key, and you have to obtain it: ?We have intercepted the following communication sent to an spy using an undisclosed openpgp implementation. Based on the detected network traffic, we are sure the key itself was downloaded using wkd, and the domain of the userid to be ?wkdtest.pgp.16bits.net? Your mission, should you choose to accept it, is to find out the name of the spy to which this communication was addressed: -----BEGIN PGP MESSAGE----- hQEMA80mh7+7fSYkAQf+PAyI1VWXZRST42basod3Rk7/44hi8nw+ARdmEy61esdJ qIWQvz2qyPJsmS5if5xfUhwzmGI6itNC+wqIrNNo5AGt+qzkHHYZswuaintmk5IF Wrh6xxHdiH1q2UMgl/SGhEQcPStUy1GdTUcx9wygjmSQwdgQhimezmdbhhoYQ13s hlZ001IhiGkBse8V+qK0g7vhWCO5XTHwMLMr3I1twcRbow4RYtw1BGp4mco1llgm BkRpAL+WFw/CFBp7W7Dn9Yz9wN5q7LDLlyO3sGmWex7IcxD2McHSYNR7roiPjwu8 5ke+MO7CM3VHmMyx1eCAXRJY7RwDvIYaZLJHbtai+owuBAkDAjJqwNFYeYiW6r/E 9KRfCCy/LsKDQW7rWCs0dLW1BM5xswAIk/SzaJDTMNJQAW6yb7Le32ao1MsEfx47 EAwlArtFZTWZvwiICcBHFPbJ8V6+mHRr4qjRKQFIE96zGCLQHnoZfUjhl+Hb5zPb +L3PfKDvYARTEOJvj/4w2Tc= =6hHu -----END PGP MESSAGE-----? Can you figure this out? From angel at pgp.16bits.net Thu Jan 21 01:29:49 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Thu, 21 Jan 2021 01:29:49 +0100 Subject: Please tackle the Right Thing In-Reply-To: <7441f18a-8e59-3ec0-5b22-b535667bf38e@colomb.de> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> <7441f18a-8e59-3ec0-5b22-b535667bf38e@colomb.de> Message-ID: <3d693337c4a59a4ac871e297433d3fc418d86a8e.camel@16bits.net> On 2021-01-20 at 20:29 +0100, Andr? Colomb wrote: > Hi all, > > after some more thought I came up with a possible wording to clarify > the > fallback behavior. Assuming that an opportunistic approach is > preferred, so the direct method should be used not only based on the > existence of openpgpkey as a SRV or other record. Here goes: > > > ---SNIP--- (page 3, second paragraph in the current draft version 11) > > There are two variants on how to form the request URI: The advanced > and the direct method. Implementations MUST first try the advanced > method. > If that does not conclude with a successful HTTP response (e.g. > status code 2xx), they MUST fall back to the direct method. If the > required sub-domain exists, but other errors occur during the > connection, they SHOULD output an error message pointing out the > failure reason to the end user. Such other errors include, for > example, invalid, expired or misconfigured TLS certificates and HTTP > failure codes (4xx or 5xx). > > ---SNIP--- Hello Andr? Thanks for contributing Suitable return codes for fetching a key would be 200 (for successful keys) and 404 (the key is not in the server). In both cases, if it is a valid wkd server, the server shouldn't fall back to direct. You could also have a 304 if the client was refreshing a key. Maybe 201 if a web-based submission protocol was added in the future. https://mailarchive.ietf.org/arch/msg/openpgp/f6V8W9wKY6dt2wAq4FBOWk8wtos/ seems to expect that HTTP redirects would work as well (seems reasonable), although it isn't explicitly stated in the document. I think the main status that would bring such trouble would be 401, 403, 5xx, although there could be some exotic cases (e.g. 407). Erroring to the user on any status code the client does not know how to handle seems the safe procedure. > So what do you think? I'm not subscribed to any IETF mailing lists, > but feel free to propose this in the relevant circles. I hereby > renounce my rights on the modified text :-) I think the right venue would be the openpgp wg. This was discussed there in the past, and I hope to see WKD published through it one day. However, although there were interesting ideas on this thread for advancing it (amidst all the generated noise), I am hesitant to open a discussion there about wkd, since openpgp working group was recently rechartered to produce the rfc 4880 bis, and wkd is not covered by its current scope. I don't think there would be opposition for adopting it if rechartering after rfc 4880bis is out, but it's a bit odd to open a discussion about something else before starting the actual chartered work. Maybe other people have an opiniono on this ? Kind regards From spam.trap.mailing.lists at gmail.com Thu Jan 21 08:02:42 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 21 Jan 2021 08:02:42 +0100 Subject: ctf-like WKD challenge (was: WKD proper behavior on fetch error) In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <22faa6d19c271bb849ba46ce3bcac325039f6f6a.camel@16bits.net> Message-ID: On Thu, Jan 21, 2021 at 12:25 AM ?ngel wrote: > Last night, I prepared the domain wkdtest.pgp.16bits.net It is a valid > wkd server. I have just created and uploaded there a new pgp key, and > you have to obtain it: > > > ?We have intercepted the following communication sent to an spy using > an undisclosed openpgp implementation. Based on the detected network > traffic, we are sure the key itself was downloaded using wkd, and the > domain of the userid to be ?wkdtest.pgp.16bits.net? > > Your mission, should you choose to accept it, is to find out the name > of the spy to which this communication was addressed: > > > -----BEGIN PGP MESSAGE----- Well, I am not in the spy business, but according to the meta data of the message it is addressed to key owner 0xCD2687BFBB7D2624, if I see it right. Since you write that you have intercepted the comms, you are aware about the following phrase: 'people get assasinated by meta data ...' I guess this is true, because last year China, for example, executed 24 CIA agents. The nice things about OpenPGP amored messages is also that procmail and friends can be used at providers to filter -----BEGIN blah So in the end, I would say when one intercepts the communications and according how MTAs work the involved parties should have it not to difficult to figure out to whom the message(s) is intended for. My motto is :TCP/IP where C stands for me for *Control* and P for Protokoll, e.g. protokoll or log everything. ;-) Best regards Stefan From spam.trap.mailing.lists at gmail.com Thu Jan 21 08:10:39 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 21 Jan 2021 08:10:39 +0100 Subject: ctf-like WKD challenge (was: WKD proper behavior on fetch error) In-Reply-To: References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <22faa6d19c271bb849ba46ce3bcac325039f6f6a.camel@16bits.net> Message-ID: On Thu, Jan 21, 2021 at 8:02 AM Stefan Claas wrote: > The nice things about OpenPGP amored messages is also that > procmail and friends can be used at providers to filter -----BEGIN blah P.S. When Stale Schumacher ran the International PGP Homepage in the 90's people could download PGP for Unix, VAX/VMS, Windows and the Mac (there was no Linux IIRC available at that time) and there was a stealth mode available, e.g. to hide the -----BEGIN blah in armored messages. Regards Stefan From lockywolf at gmail.com Thu Jan 21 11:25:26 2021 From: lockywolf at gmail.com (Vladimir Nikishkin) Date: Thu, 21 Jan 2021 18:25:26 +0800 Subject: RSS/Atom for the GnuPG blog? Message-ID: <87eeiey4ec.fsf@delllaptop.lockywolf.net> Hello, everyone There is a nice blog that GnuPG people write: https://www.gnupg.org/blog/index.html But there seems to be no way to subscribe to it via standard Atom/RSS feed. Is this intentional? Or maybe I just haven't found the links? Thanks. -- Vladimir Nikishkin (MiEr, lockywolf) (Laptop) From gnupg-users at storiepvtride.it Thu Jan 21 11:46:05 2021 From: gnupg-users at storiepvtride.it (jman) Date: Thu, 21 Jan 2021 11:46:05 +0100 Subject: RSS/Atom for the GnuPG blog? In-Reply-To: <87eeiey4ec.fsf@delllaptop.lockywolf.net> References: <87eeiey4ec.fsf@delllaptop.lockywolf.net> Message-ID: <87ft2ueff6.fsf@nyarlathotep> Vladimir Nikishkin via Gnupg-users writes: > There is a nice blog that GnuPG people write: > https://www.gnupg.org/blog/index.html > > But there seems to be no way to subscribe to it via standard Atom/RSS > feed. > Is this intentional? Or maybe I just haven't found the links? There's no direct RSS/Atom feed (afaics). However the blog is a git repository [0] with a RSS/Atom feed (there's a link at the bottom of the page). As a workaround you subscribe to that feed (I didn't test it). regards, [0] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git;a=tree;f=misc/blog.gnupg.org From andrewg at andrewg.com Thu Jan 21 11:48:42 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 21 Jan 2021 10:48:42 +0000 Subject: ctf-like WKD challenge (was: WKD proper behavior on fetch error) In-Reply-To: References: <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <22faa6d19c271bb849ba46ce3bcac325039f6f6a.camel@16bits.net> Message-ID: On 21/01/2021 07:10, Stefan Claas via Gnupg-users wrote: > On Thu, Jan 21, 2021 at 8:02 AM Stefan Claas > wrote: > >> The nice things about OpenPGP amored messages is also that >> procmail and friends can be used at providers to filter -----BEGIN blah > > P.S. When Stale Schumacher ran the International PGP Homepage in the 90's > people could download PGP for Unix, VAX/VMS, Windows and the Mac > (there was no Linux IIRC available at that time) and there was a stealth > mode available, e.g. to hide the -----BEGIN blah in armored messages. ... which was pure security theatre that made it look more obfuscated to the untrained eye, but would never fool even the simplest automated tool. It is important to remember what PGP is for, and what it is not for. It is most definitely NOT for hiding metadata. No system based on email can ever do that, so it is safer not to pretend otherwise. If you need to hide your metadata from the state on pain of torture and death, PGP is NOT the solution. Use Tor, use Signal. And even then you're taking your chances because in many countries it is highly likely that your endpoint is rooted, and no security software can protect you from an pwned endpoint. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gnupg at eckner.net Thu Jan 21 15:05:53 2021 From: gnupg at eckner.net (Erich Eckner) Date: Thu, 21 Jan 2021 15:05:53 +0100 (CET) Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: <87bldjaepg.fsf@wheatstone.g10code.de> References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <874kjbbx3r.fsf@wheatstone.g10code.de> <615d7260-d5fe-71f0-2510-5cb67b51b7@eckner.net> <87bldjaepg.fsf@wheatstone.g10code.de> Message-ID: <53a2e650-118a-c84a-bc7-2f615660c6e4@eckner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, 20 Jan 2021, Werner Koch wrote: > On Wed, 20 Jan 2021 14:46, Erich Eckner said: > >> is queried. This resolves to some old address (my DNS configuration >> error), which serves the wrong content. Is it right, that this SRV record >> should be queried? Should I update it or remove it? > > Yes, the SRV record is used if there is no openpgpkeys sub-domain. The > reason is that the original scheme was to use SRV records but we had to > switch to a subdomain due to problems with browser based code. Ah, right, I see the SRV record being queried *after* the openpgpkey.eckner.net query. However, for whatever reason these (and the SRV) queries fail: 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: chan_6 <- WKD_GET -- erich at eckner.net 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: libdns initialized (tor mode) 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: resolve_dns_name(openpgpkey.eckner.net): Verbindung im DNS geschlossen 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: libdns initialized (tor mode) 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: getsrv(_openpgpkey._tcp.eckner.net): Verbindung im DNS geschlossen 2021-01-21 14:41:32 dirmngr[3623955.6] command 'WKD_GET' failed: Verbindung im DNS geschlossen 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: chan_6 -> ERR 167772876 Verbindung im DNS geschlossen 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: chan_6 <- BYE 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: chan_6 -> OK closing connection 2021-01-21 14:41:32 dirmngr[3623955.6] Handhabungsroutine f?r den fd 6 beendet the other box shows different errors at the same positions: 2021-01-21 14:47:09 dirmngr[1904072.6] DBG: chan_6 <- WKD_GET -- erich at eckner.net 2021-01-21 14:47:09 dirmngr[1904072.6] DBG: dns: resolve_dns_name(openpgpkey.eckner.net): Permission denied 2021-01-21 14:47:09 dirmngr[1904072.6] DBG: dns: getsrv(_openpgpkey._tcp.eckner.net): Permission denied 2021-01-21 14:47:09 dirmngr[1904072.6] command 'WKD_GET' failed: Permission denied 2021-01-21 14:47:09 dirmngr[1904072.6] DBG: chan_6 -> ERR 167804929 Permission denied I wonder, though, why the tried things differ on both machines - both run arch linux with gnupg 2.2.26 and libgcrypt 1.8.7, no gpg.conf. What should I do to dig further into this? > >> I assume, this is for debugging *a lot* of gnupg in one place (like your > > Right. It is also cool to watch the diagnostccs fly by during regular > use ;-) I played around with the socket:// log "file", and I must say, the nice thing is, that you can keep this in your dirmngr.conf without creating endless logs - only when the listening command is started, the socket is created and actual logs will be generated :-) > > > Salam-Shalom, > > Werner regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAJikIACgkQCu7JB1Xa e1q30g/8DbT9NA95gxe3NXEN54oj5Cge1dxqGbuqhg2tQv4Pex5hMNv8YSVE8kMM g0npzK24d5fszFEhOJlfQ+7HGzFb39hPjVVv48RsHjVPw2pGz1e4/K5p4AkqRjde H7D/CghEGPVdIjM52VI9oJRMCFly2iKPZsurNrJhqfbtzAMCSmTv/gUotO9mA23b 1wvlcBryrt8d/Hu653x+Rx0oCygDHj7etzONH5tMFunw7oJiLoonWB65w18aC3yQ qMKyIBEtUJkskH25SJeY8ZUr8h1CTsXAvovqjhgfvOMV+1p9wnj234o/c8m33uUQ si0sSbP6xtc6BcEy2XuVWrpw9lKZYVsRDdAODnXqKCLeIdb7K57P+2EV2Azc80BP Wy1m9qzgGPLK5A6RxDoQD9jSisTDm4okiDM4ZvK5v+0k2NWqy+7hnsoF2Pohe5zE RBlumaSmE6jiw2QaLuUscUFJB/QgxOnh1PpdU7SoMMh6Vmb7Rt7Eau63iZxmJWym lSY+OUCLlWTdDipV8OU86ZI0uzHJo1JJGDkijR2hlJblLI6bOyc1oC2L42R49dbe jLoFUxoK7K6VDOXVcK8spIcmhrJERudg1U96ArP3G2o9S9bg+n4C2B7hTo2wm3Ml zcdk8Zt3PB6G7wmc41bvtd5LDcbLFXvr1/KxT+JLyWy0tJW0RXU= =GAHG -----END PGP SIGNATURE----- From spam.trap.mailing.lists at gmail.com Thu Jan 21 15:55:13 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 21 Jan 2021 15:55:13 +0100 Subject: ctf-like WKD challenge (was: WKD proper behavior on fetch error) In-Reply-To: References: <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <22faa6d19c271bb849ba46ce3bcac325039f6f6a.camel@16bits.net> Message-ID: On Thu, Jan 21, 2021 at 12:25 PM Andrew Gallagher via Gnupg-users wrote: > > On 21/01/2021 07:10, Stefan Claas via Gnupg-users wrote: > > On Thu, Jan 21, 2021 at 8:02 AM Stefan Claas > > wrote: > > > >> The nice things about OpenPGP amored messages is also that > >> procmail and friends can be used at providers to filter -----BEGIN blah > > > > P.S. When Stale Schumacher ran the International PGP Homepage in the 90's > > people could download PGP for Unix, VAX/VMS, Windows and the Mac > > (there was no Linux IIRC available at that time) and there was a stealth > > mode available, e.g. to hide the -----BEGIN blah in armored messages. > > ... which was pure security theatre that made it look more obfuscated to > the untrained eye, but would never fool even the simplest automated tool. > > It is important to remember what PGP is for, and what it is not for. It > is most definitely NOT for hiding metadata. No system based on email can > ever do that, so it is safer not to pretend otherwise. > > If you need to hide your metadata from the state on pain of torture and > death, PGP is NOT the solution. Use Tor, use Signal. And even then > you're taking your chances because in many countries it is highly likely > that your endpoint is rooted, and no security software can protect you > from an pwned endpoint. Very well said, Andrew! Things I usually post here are more or less for the little PGP user whishing to improve his practices, when using OpenPGP software. And regarding Signal, I would think twice about that, which would be to much OT here on this ML, but I can tell people here when I asked Moxie, Signal, Micah Lee a question they did not answer. And when Elon Musk started to advertise Signal usage on Twitter publicity he received a reply from me, which he then not answered. As some of you may know I have sold my smartphone ... Best regards Stefan From bernhard at intevation.de Thu Jan 21 17:04:08 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 21 Jan 2021 17:04:08 +0100 Subject: make check failed tests In-Reply-To: References: Message-ID: <202101211704.09017.bernhard@intevation.de> Am Mittwoch 20 Januar 2021 09:41:10 schrieb mettodo via Gnupg-users: > 14 of 20 tests failed when doing "make check" for gnupg 2.2.27. What > should I do? Please give more details, like used system, compiler and what checks failed and how. If it is getting very technical, the gnupg-devel list would be another place to report. Thanks, 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: 659 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Thu Jan 21 17:10:31 2021 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 21 Jan 2021 11:10:31 -0500 Subject: WKD proper behavior on fetch error In-Reply-To: <780b90f468c3e160b56121e2ed02a564cb0429f8.camel@16bits.net> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <87o8hkj2nn.fsf@fifthhorseman.net> <780b90f468c3e160b56121e2ed02a564cb0429f8.camel@16bits.net> Message-ID: <87czxyi83s.fsf@fifthhorseman.net> (my messages might not be arriving at @gnupg.org addresses right now because their mailserver appears to be rejecting my mailserver claiming (incorrectly, afaict) that the reverse DNS is not configured -- hopefully it will be resolved soon; feel free to re-forward this message to the list if it doesn't show up there) On Wed 2021-01-20 03:32:31 +0100, ?ngel wrote: > In this context, there would be a possible attack by tricking the user > into making their key recognizable. Yes, padding to protect the size of HTTPS traffic is important here. The WKD client itself might want to also pad the query string since its length will be variable based on the size of the l= parameter. This is probably not the best mailing list to discuss either mechanism or policy for HTTPS padding in particular, though. > A WKD server operator could protect from this by padding the result > with other keys so that the actual key size is concealed. > > In order to simplify this, I would recommend stating that WKD clients > must ignore a trailing block of nuls (not part of a pgp packet, > obviously) so that keys can easily be padded without calculating > openpgp packets. Padding HTTPS traffic can already be done at the HTTP layer by adding HTTP headers that will be known to be ignored. I don't have a handy reference for how to set that up, though, so it may be easiest for a WKD operator to pad the distributed files directly. ?ngel proposes to pad with a block of nuls. This is problematic for at least two reasons: - it doesn't appear to be an OpenPGP packet, which might lead to the whole thing being rejected by a strict implementation - it compresses, which might reveal size in a compressed HTTPS session (?ngel recognized this flaw in his message, but doesn't propose a mitigation other than turning off compression, which might not be possible for some operators) For WKD services which cannot control their webserver to disable compression, and automate padding, a better approach would be to pad each published key with an OpenPGP literal data packet, whose content is filled with a high-entropy (uncompressable) stream. Implementations that can parse OpenPGP packets will identify and discard this packet (it is not part of any legitimate OpenPGP certificate); it can't be easily compressed (due to the high entropy); and there won't be any confusion about where the certificate ends, if the actual certificate itself happens to end with any trailing nul octets. Therefore, I'd recommend the following padding guidance be added to the WKD draft to avoid the information leakage described: While all transport for WKD uses HTTPS, the sizes of the requests and responses may themselves leak information to a network observer about the identity of the e-mail address looked up. To avoid this leakage, padding is advised: - A WKD client that provides the l= query parameter SHOULD provide an additional dummy query parameter, padding the size of the overall HTTP query string to a multiple of 256 octets. - A WKD client MUST NOT offer compression in the TLS handshake. - A WKD client's HTTP request MUST NOT offer to accept Transfer Coding or Content Coding that includes compression, including gzip, compress, or deflate. {{someone more knowledgable about HTTPS should rewrite this to be more precise}} - An HTTPS server that publishes a tree of WKD information SHOULD NOT compress HTTPS responses whose URLs fall within that tree. - An HTTPS server that publishes a tree of WKD information SHOULD ensure that returned HTTPS responses with the WKD tree are padded to a multiple of 4096 octets. Padding mechanisms might include: - a dummy HTTP header of sufficient length - appending a Literal Data packet to the returned OpenPGP certificate If the Literal Data packet padding mechanism is used, it SHOULD be filled with high-entropy randomness, in case some HTTPS server, reverse proxy, or other element in the data transmission chain tries to compress the certificate. regards, --dkg From neal at walfield.org Thu Jan 21 18:49:19 2021 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 21 Jan 2021 18:49:19 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <87czxyi83s.fsf@fifthhorseman.net> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <87o8hkj2nn.fsf@fifthhorseman.net> <780b90f468c3e160b56121e2ed02a564cb0429f8.camel@16bits.net> <87czxyi83s.fsf@fifthhorseman.net> Message-ID: <87lfcm6uzk.wl-neal@walfield.org> On Thu, 21 Jan 2021 17:10:31 +0100, Daniel Kahn Gillmor wrote: > For WKD services which cannot control their webserver to disable > compression, and automate padding, a better approach would be to pad > each published key with an OpenPGP literal data packet, whose content is > filled with a high-entropy (uncompressable) stream. > > Implementations that can parse OpenPGP packets will identify and discard > this packet (it is not part of any legitimate OpenPGP certificate); it > can't be easily compressed (due to the high entropy); and there won't be > any confusion about where the certificate ends, if the actual > certificate itself happens to end with any trailing nul octets. Please don't do this. This is the format of a TPK: https://tools.ietf.org/html/rfc4880#section-11.1 It doesn't allow arbitrary packets to follow it, as far as I can see. Let's stick to it. Now, there are few things we could do: we could inject a bad signature. Some implementations won't discard bad signatures, so this is probably a bad idea. We could append a public key packet with fixed creation time and MPIs, and a direct key signature, which is filled with junk. Implementations would detect this as an invalid key for several different reasons (no valid self signature, for instance). And, implementations in the know could recognize the public key packet as being padding and no even emit a warning about an invalid certificate. > If the Literal Data packet padding mechanism is used, it SHOULD be > filled with high-entropy randomness, in case some HTTPS server, > reverse proxy, or other element in the data transmission chain tries > to compress the certificate. Another approach to make the data uncompressable would be to encrypt the keyring with, say, AES and include the key. From spam.trap.mailing.lists at gmail.com Thu Jan 21 21:23:19 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 21 Jan 2021 21:23:19 +0100 Subject: Fundraising In-Reply-To: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> References: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> Message-ID: On Sun, Jan 17, 2021 at 9:59 PM Robert J. Hansen via Gnupg-users wrote: > > A little more than a month ago I said I'd match all donations made to > GnuPG from December 10 to January 6. I'm happy to report y'all made me > contribute 370 Euros, or about $450 USD. The money has been paid and > is sitting in GnuPG's account. > > I hope this encouraged some of y'all to donate to GnuPG this year. And > if you missed out, why not consider making a recurring monthly > contribution of your own? It's a great way to tell the crew thank-you > for all the work they do. > > Thanks, all the GnuPG contributors. I really appreciate it! *Appologies* Robert for highjacking your thread!!! But I would like to spread the word! I also donated already. https://www.crowdjustice.com/case/assangeappeal/ Regards Stefan From andrewg at andrewg.com Thu Jan 21 22:59:48 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 21 Jan 2021 21:59:48 +0000 Subject: Fundraising In-Reply-To: References: Message-ID: > On 21 Jan 2021, at 20:27, Stefan Claas via Gnupg-users wrote: > > *Appologies* Robert for highjacking your thread!!! Can we please try to keep on topic. A From spam.trap.mailing.lists at gmail.com Thu Jan 21 23:07:26 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 21 Jan 2021 23:07:26 +0100 Subject: Fundraising In-Reply-To: References: Message-ID: On Thu, Jan 21, 2021 at 11:00 PM Andrew Gallagher via Gnupg-users wrote: > > > > On 21 Jan 2021, at 20:27, Stefan Claas via Gnupg-users wrote: > > > > *Appologies* Robert for highjacking your thread!!! > > Can we please try to keep on topic. Sure! Regards Stefan From rjh at sixdemonbag.org Fri Jan 22 03:20:55 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 21 Jan 2021 21:20:55 -0500 Subject: Fundraising In-Reply-To: References: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> Message-ID: <90f70b19-fec7-efdb-5113-882219917958@sixdemonbag.org> > *Appologies* Robert for highjacking your thread!!! I have never understood why people apologize for doing something they know is wrong, and then do it anyway. You could see that starting a new thread was appropriate; you know that starting a new thread is easy; you apologized for your inappropriate behavior; and then behaved inappropriately. Your apology is not accepted, as it is clearly insincere. Further, in just the last month and change on this list you've hyped Bitcoin scams, poorly-designed password managers, sown wild confusion about TLS and WKD, and now you're trying to raise funds for politically controversial figures unrelated to GnuPG's mission. I cannot be the only one here who has noticed your track record. I urge you to think long and hard about it, and to turn yourself around. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x1DCBDC01B44427C7.asc Type: application/pgp-keys Size: 9919 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From angel at pgp.16bits.net Fri Jan 22 03:36:47 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 22 Jan 2021 03:36:47 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <87lfcm6uzk.wl-neal@walfield.org> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <87o8hkj2nn.fsf@fifthhorseman.net> <780b90f468c3e160b56121e2ed02a564cb0429f8.camel@16bits.net> <87czxyi83s.fsf@fifthhorseman.net> <87lfcm6uzk.wl-neal@walfield.org> Message-ID: <4c7e454563338ff05019bdbc4c11274cdf6b6d8a.camel@16bits.net> On 2021-01-21 at 18:49 +0100, Neal H. Walfield wrote: > On Thu, 21 Jan 2021 17:10:31 +0100, > Daniel Kahn Gillmor wrote: > > For WKD services which cannot control their webserver to disable > > compression, and automate padding, a better approach would be to > > pad > > each published key with an OpenPGP literal data packet, whose > > content is > > filled with a high-entropy (uncompressable) stream. > > > > Implementations that can parse OpenPGP packets will identify and > > discard > > this packet (it is not part of any legitimate OpenPGP certificate); > > it > > can't be easily compressed (due to the high entropy); and there > > won't be > > any confusion about where the certificate ends, if the actual > > certificate itself happens to end with any trailing nul octets. > > Please don't do this. This is the format of a TPK: > > https://tools.ietf.org/html/rfc4880#section-11.1 > > It doesn't allow arbitrary packets to follow it, as far as I can see. > > Let's stick to it. We do have a bit of leeway here. This is not a "general TPK", as we are defining it inside a protocol. That's the context in which I considered it would be permissible to ignore trailing NULs. My main consideration was that this allowed the admin to simply do? truncate -s 4096 /var/www/html/.well-known/openpgpkey/hu/* and get all the keys padded to 4096 (or whatever value he may want. He would only need not to have real keys already larger than that). I don't think we can expect most users to manually calculate a complex padding. Now, if the operators can't disable compression, that's a problem. > Now, there are few things we could do: we could inject a bad > signature. Some implementations won't discard bad signatures, so > this is probably a bad idea. We could append a public key packet > with fixed creation time and MPIs, and a direct key signature, which > is filled with junk. Implementations would detect this as an invalid > key for several different reasons (no valid self signature, for > instance). > And, implementations in the know could recognize the public key > packet as being padding and no even emit a warning about an invalid > certificate. The right? way would be to append a valid PGP key with an UID not matching the hash. All implementations should already had considered that possibility. One could use a public key with e.g. a Public-Key Algorithm of 0, and define that as a "null key" that should be skipped, but I'm not keen on that since, it isn't really a public key. It is overloading a packet to mean something different, for backwards compatibility. I don't think we are at a point requiring such level of backwards compatibility. There is only a handful of wkd implementations. The spec is just a rfc, and we are finding cases where the implementations differ, and will need to be changed, anyway. It would be a bad choice to fossilize a hack like that. dkg suggested an OpenPGP literal data packet. I suspect it may have been an error, and rather than a Literal Data Packet (Tag 11), he may have intended an _Obsolete_ Literal Packet, now Marker Packet (Tag 10). If it wasn't, consider this a formal proposal to use it. Tag 10 was never used by an official release, and 4880 says: > Such a packet MUST be ignored when received. A new no-op packet could be made, but Marker seems already a perfect fit. Instead of putting "PGP", it would contain the padding data. The content could start with e.g. "PADDING:" to make the intent even more obvious, but the whole packet should have been ignored. I have added several new test keys: alice.nulpadding at wkdtest.pgp.16bits.net The same padding with nuls alice.literal at wkdtest.pgp.16bits.net Padding with a literal packet alice.marker at wkdtest.pgp.16bits.net Padding with a marker packet alice.secret at wkdtest.pgp.16bits.net Padding with a secret key packet alice.experimental at wkdtest.pgp.16bits.net Padding with an unknown packet GnuPG imports without issues the key with a literal or secret packet, but not with a marker, as it verifies (parse_marker) that it strictly contains "PGP" :-/ 4880 mentions that such is the content of a marker packet, but I was expecting a more lenient parsing, given that there might be packets generated from that unreleased version. It would be possible to pad with a number of these (see alice.pgppgppgp at wkdtest.pgp.16bits.net), but it has the same issue of being compressible. I also prepared dynamic.keys at wkdtest.pgp.16bits.net which is simply padded with other different, varying keys. However note that gnupg only looks at the first 5 keys returned. > > If the Literal Data packet padding mechanism is used, it SHOULD be > > filled with high-entropy randomness, in case some HTTPS server, > > reverse proxy, or other element in the data transmission chain tries > > to compress the certificate. > > Another approach to make the data uncompressable would be to encrypt > the keyring with, say, AES and include the key. Do you mean to compress the returned file with AES? That would be a big change from existing protocol. And you still need a way to separate the padding from the key. Regards ?ngel ? or, if you prefer truncate -s 4096 /var/www/html/.well- known/openpgpkey/hu/???????????????????????????????? From spam.trap.mailing.lists at gmail.com Fri Jan 22 05:26:44 2021 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Fri, 22 Jan 2021 05:26:44 +0100 Subject: Fundraising In-Reply-To: <90f70b19-fec7-efdb-5113-882219917958@sixdemonbag.org> References: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> <90f70b19-fec7-efdb-5113-882219917958@sixdemonbag.org> Message-ID: On Fri, Jan 22, 2021 at 3:20 AM Robert J. Hansen wrote: > > > *Appologies* Robert for highjacking your thread!!! > > I have never understood why people apologize for doing something they > know is wrong, and then do it anyway. You could see that starting a new > thread was appropriate; you know that starting a new thread is easy; you > apologized for your inappropriate behavior; and then behaved > inappropriately. Your apology is not accepted, as it is clearly insincere. Perfectly fine, that you don't accept my appology, which were honest of course. And you can be rest assured that you and Andrew had then complained also if I had done so. > Further, in just the last month and change on this list you've hyped > Bitcoin scams, poorly-designed password managers, sown wild confusion > about TLS and WKD, and now you're trying to raise funds for politically > controversial figures unrelated to GnuPG's mission. I really like how you try to paint a picture of me. But everybody knows what kind of character you are. > I cannot be the only one here who has noticed your track record. I urge > you to think long and hard about it, and to turn yourself around. I can only think of what kind of gentleman you are. Try harder next time! Best regards Stefan From andre at colomb.de Fri Jan 22 09:28:42 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Fri, 22 Jan 2021 09:28:42 +0100 Subject: Fundraising In-Reply-To: <90f70b19-fec7-efdb-5113-882219917958@sixdemonbag.org> References: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> <90f70b19-fec7-efdb-5113-882219917958@sixdemonbag.org> Message-ID: <205fb931-119e-0058-c7c2-71dac3ef3a67@colomb.de> Hi Robert, you are not alone. On 22/01/2021 03.20, Robert J. Hansen via Gnupg-users wrote: > I have never understood why people apologize for doing something they > know is wrong, and then do it anyway.? You could see that starting a new > thread was appropriate; you know that starting a new thread is easy; you > apologized for your inappropriate behavior; and then behaved > inappropriately.? Your apology is not accepted, as it is clearly insincere. Well said. I didn't want to make even more noise about this, but that's just what I was thinking. Kind regards Andr? -- Greetings... From: Andr? Colomb From bernhard at intevation.de Fri Jan 22 10:13:04 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 22 Jan 2021 10:13:04 +0100 Subject: make check failed tests In-Reply-To: <3e5d12e7-00f7-8590-a496-e6f301fdc351@riseup.net> References: <202101211704.09017.bernhard@intevation.de> <3e5d12e7-00f7-8590-a496-e6f301fdc351@riseup.net> Message-ID: <202101221013.10984.bernhard@intevation.de> Hi Mettodo, Am Freitag 22 Januar 2021 07:02:34 schrieb mettodo: > I do not exactly know what you ask for, let me know if this is not enough: > - Ubuntu 18.04.5 LTS > - gcc version 7.5.0 > - Attached text with failed checks yes, this is a good start to get, so others are able to give you more suggestions. As far as I can see, it is all the same error: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference Looks like you may need a newer version of libgpg-error (as far as I can see gpgrt_getcwd was introduced with 1.27 of libgpg-error). Did you build libgpg-error yourself? If so, what version? The "configure" script should have complained, was it saying okay? 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: 659 bytes Desc: This is a digitally signed message part. URL: From mettodo at riseup.net Fri Jan 22 07:02:34 2021 From: mettodo at riseup.net (mettodo) Date: Fri, 22 Jan 2021 09:02:34 +0300 Subject: make check failed tests In-Reply-To: <202101211704.09017.bernhard@intevation.de> References: <202101211704.09017.bernhard@intevation.de> Message-ID: <3e5d12e7-00f7-8590-a496-e6f301fdc351@riseup.net> Hi Bernhard, I do not exactly know what you ask for, let me know if this is not enough: - Ubuntu 18.04.5 LTS - gcc version 7.5.0 - Attached text with failed checks Thanks! On 21/01/2021 19:04, Bernhard Reiter wrote: > Am Mittwoch 20 Januar 2021 09:41:10 schrieb mettodo via Gnupg-users: >> 14 of 20 tests failed when doing "make check" for gnupg 2.2.27. What >> should I do? > Please give more details, like used system, compiler and > what checks failed and how. If it is getting very technical, > the gnupg-devel list would be another place to report. > > Thanks, > Bernhard > -------------- next part -------------- Making check in m4 make[1]: Entering directory '/home/mettodo/Downloads/GNUpg/gnupg-2.2.27/m4' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/home/mettodo/Downloads/GNUpg/gnupg-2.2.27/m4' Making check in common make[1]: Entering directory '/home/mettodo/Downloads/GNUpg/gnupg-2.2.27/common' make check-am make[2]: Entering directory '/home/mettodo/Downloads/GNUpg/gnupg-2.2.27/common' make check-TESTS make[3]: Entering directory '/home/mettodo/Downloads/GNUpg/gnupg-2.2.27/common' ./t-stringhelp: relocation error: ./t-stringhelp: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference FAIL: t-stringhelp PASS: t-timestuff ./t-convert: relocation error: ./t-convert: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference FAIL: t-convert PASS: t-percent ./t-gettime: relocation error: ./t-gettime: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference FAIL: t-gettime ./t-sysutils: relocation error: ./t-sysutils: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference FAIL: t-sysutils ./t-sexputil: relocation error: ./t-sexputil: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference FAIL: t-sexputil > Known envvars: GPG_TTY(ttyname) TERM(ttytype) DISPLAY(display) > XAUTHORITY(xauthority) XMODIFIERS WAYLAND_DISPLAY GTK_IM_MODULE > DBUS_SESSION_BUS_ADDRESS QT_IM_MODULE INSIDE_EMACS PINENTRY_USER_DATA(pinentry-user-data) PASS: t-session-env PASS: t-openpgp-oid ./t-ssh-utils: relocation error: ./t-ssh-utils: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference FAIL: t-ssh-utils ./t-mapstrings: relocation error: ./t-mapstrings: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference FAIL: t-mapstrings PASS: t-zb32 ./t-mbox-util: relocation error: ./t-mbox-util: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference FAIL: t-mbox-util ./t-iobuf: relocation error: ./t-iobuf: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference FAIL: t-iobuf ./t-strlist: relocation error: ./t-strlist: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference FAIL: t-strlist ./t-name-value: relocation error: ./t-name-value: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference FAIL: t-name-value PASS: t-ccparray ./t-recsel: relocation error: ./t-recsel: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference FAIL: t-recsel ./t-exechelp: relocation error: ./t-exechelp: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference FAIL: t-exechelp ./t-exectool: relocation error: ./t-exectool: symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference FAIL: t-exectool ======================================= 14 of 20 tests failed Please report to https://bugs.gnupg.org ======================================= Makefile:2829: recipe for target 'check-TESTS' failed make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory '/home/mettodo/Downloads/GNUpg/gnupg-2.2.27/common' Makefile:2955: recipe for target 'check-am' failed make[2]: *** [check-am] Error 2 make[2]: Leaving directory '/home/mettodo/Downloads/GNUpg/gnupg-2.2.27/common' Makefile:2957: recipe for target 'check' failed make[1]: *** [check] Error 2 make[1]: Leaving directory '/home/mettodo/Downloads/GNUpg/gnupg-2.2.27/common' Makefile:619: recipe for target 'check-recursive' failed make: *** [check-recursive] Error 1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Jan 22 11:23:28 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jan 2021 11:23:28 +0100 Subject: Fundraising In-Reply-To: (Stefan Claas via Gnupg-users's message of "Fri, 22 Jan 2021 05:26:44 +0100") References: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> <90f70b19-fec7-efdb-5113-882219917958@sixdemonbag.org> Message-ID: <87eeid6zj3.fsf@wheatstone.g10code.de> On Fri, 22 Jan 2021 05:26, Stefan Claas said: > I really like how you try to paint a picture of me. But everybody knows > what kind of character you are. Stefan: Stop such personal insults. I am pretty sure that there are quite some folks here who would like to get personal too but don't do this because this is here is a civilized discussion medium. In 23 years of this list we had not more than a handful of abusive users on this list. You are on the best way to be one on of those few for whom I had to flip the moderate flag. Messages to this list consists of public information and what you are doing is to attack the repudiation of this list. Stop this! Shalom-Salam, Werner p.s. Political messages not direcly related to GnuPG are off-topic and belong into the sig-line. -- * Free Assange and protect free journalism! * Germany: Sign the Treaty on the Prohibition of Nuclear Weapons! -------------- 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 Jan 22 11:32:21 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jan 2021 11:32:21 +0100 Subject: ctf-like WKD challenge In-Reply-To: (Andrew Gallagher via Gnupg-users's message of "Thu, 21 Jan 2021 10:48:42 +0000") References: <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <22faa6d19c271bb849ba46ce3bcac325039f6f6a.camel@16bits.net> Message-ID: <87a6t16z4a.fsf@wheatstone.g10code.de> On Thu, 21 Jan 2021 10:48, Andrew Gallagher said: > It is important to remember what PGP is for, and what it is not > for. It is most definitely NOT for hiding metadata. No system based on > email can ever do that, so it is safer not to pretend otherwise. Full Ack. There are ways to hide meat data and they exists for a long time. Use them or helpt to get them back to live. Tor is one option but it does not really target mails because it is designed as a low-latency service. > If you need to hide your metadata from the state on pain of torture > and death, PGP is NOT the solution. Use Tor, use Signal. And even then That is not corrct. OpenPGP can and is in the real world part of a solution. But communication in a hostile environment requires training and creative methods to convey the data. Signal for example is not a solution because it is a centralized service, requires easy to subvert OSes, backdoored updates can easiliy be pushed to users, easuy to block, and so forth. It may be part of a solution. > likely that your endpoint is rooted, and no security software can > protect you from an pwned endpoint. There are ways to mitigate this but again training is required. 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 Fri Jan 22 11:55:09 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 22 Jan 2021 10:55:09 +0000 Subject: ctf-like WKD challenge In-Reply-To: <87a6t16z4a.fsf@wheatstone.g10code.de> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <22faa6d19c271bb849ba46ce3bcac325039f6f6a.camel@16bits.net> <87a6t16z4a.fsf@wheatstone.g10code.de> Message-ID: On 22/01/2021 10:32, Werner Koch wrote: > On Thu, 21 Jan 2021 10:48, Andrew Gallagher said: > >> If you need to hide your metadata from the state on pain of torture >> and death, PGP is NOT the solution. Use Tor, use Signal. And even then > > That is not corrct. OpenPGP can and is in the real world part of a > solution. But communication in a hostile environment requires training > and creative methods to convey the data. Yes of course, sorry for the crude generalisation. Write in haste, repent at leisure. :-( -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Jan 22 12:00:27 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jan 2021 12:00:27 +0100 Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: <53a2e650-118a-c84a-bc7-2f615660c6e4@eckner.net> (Erich Eckner via Gnupg-users's message of "Thu, 21 Jan 2021 15:05:53 +0100 (CET)") References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <874kjbbx3r.fsf@wheatstone.g10code.de> <615d7260-d5fe-71f0-2510-5cb67b51b7@eckner.net> <87bldjaepg.fsf@wheatstone.g10code.de> <53a2e650-118a-c84a-bc7-2f615660c6e4@eckner.net> Message-ID: <875z3p6xtg.fsf@wheatstone.g10code.de> On Thu, 21 Jan 2021 15:05, Erich Eckner said: > 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: libdns initialized (tor mode) > 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: Your are using Tor for DNS queries, that is the actual DNS server is 8.8.8.8. Tor mode is used if you are running the Tor client or the Tor browser. Put no-use-tor into dirmngr.conf and to get DNS debug messages add "debug dns". > getsrv(_openpgpkey._tcp.eckner.net): Verbindung im DNS geschlossen (Yes, I known, GnUPG has two many debug stuff i18n). > I wonder, though, why the tried things differ on both machines - both run > arch linux with gnupg 2.2.26 and libgcrypt 1.8.7, no gpg.conf. Any proxy, Tor software running. You may try "disable-ipv6" or "disable-ipv4" in your dirmngr.conf. FWIW, "gpgconf --show-versions" gives information on the used libraries, CPU, etc. 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 Jan 22 12:10:26 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jan 2021 12:10:26 +0100 Subject: RSS/Atom for the GnuPG blog? In-Reply-To: <87eeiey4ec.fsf@delllaptop.lockywolf.net> (Vladimir Nikishkin via Gnupg-users's message of "Thu, 21 Jan 2021 18:25:26 +0800") References: <87eeiey4ec.fsf@delllaptop.lockywolf.net> Message-ID: <87y2gl5isd.fsf@wheatstone.g10code.de> On Thu, 21 Jan 2021 18:25, Vladimir Nikishkin said: > But there seems to be no way to subscribe to it via standard Atom/RSS > feed. > Is this intentional? Or maybe I just haven't found the links? I have simply not yet come around to implement it. I got some code but iirc, I was not sure whether to use RSS or Atom and forgot about it. We have an open bug, though: https://dev.gnupg.org/T3211 and I just raised the priority. New blog entries are rare, which needs to be addressed as well. Salam-Shalom, Werner -- * Free Assange and protect free journalism! * Germany: Sign the Treaty on the Prohibition of Nuclear Weapons! -------------- 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 Fri Jan 22 13:08:28 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 22 Jan 2021 13:08:28 +0100 Subject: behaviour on this list (Re: Fundraising) In-Reply-To: References: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> <90f70b19-fec7-efdb-5113-882219917958@sixdemonbag.org> Message-ID: <202101221308.47250.bernhard@intevation.de> Moin Stefan, Am Freitag 22 Januar 2021 05:26:44 schrieb Stefan Claas via Gnupg-users: > > I cannot be the only one here who has noticed your track record. ?I urge > > you to think long and hard about it, and to turn yourself around. > > I can only think of what kind of gentleman you are. a mailing list is useful and can be fun, if we all behave civilized. For this there needs to be feedback about posts. And when done well, the feedback is respectful and explains things. Stefan, I believe Robert and Andr?, while being brief, gave you feedback and explanations. It took them some personal time and efforts. I agree with them in: Some of your posts were over the line (as others and them pointed out to you.) Their explanations are a chance to reflect and learn, so we all have a nice list here! 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: 659 bytes Desc: This is a digitally signed message part. URL: From gnupg at eckner.net Fri Jan 22 13:24:22 2021 From: gnupg at eckner.net (Erich Eckner) Date: Fri, 22 Jan 2021 13:24:22 +0100 (CET) Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: <875z3p6xtg.fsf@wheatstone.g10code.de> References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <874kjbbx3r.fsf@wheatstone.g10code.de> <615d7260-d5fe-71f0-2510-5cb67b51b7@eckner.net> <87bldjaepg.fsf@wheatstone.g10code.de> <53a2e650-118a-c84a-bc7-2f615660c6e4@eckner.net> <875z3p6xtg.fsf@wheatstone.g10code.de> Message-ID: <5da07512-2584-3edb-25ef-b39cdb9f4ba@eckner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, 22 Jan 2021, Werner Koch wrote: > On Thu, 21 Jan 2021 15:05, Erich Eckner said: > >> 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: libdns initialized (tor mode) >> 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: > > Your are using Tor for DNS queries, that is the actual DNS server is > 8.8.8.8. Tor mode is used if you are running the Tor client or the Tor > browser. Put no-use-tor into dirmngr.conf and to get DNS debug messages > add "debug dns". Ah, indeed: one machine runs a tor client, adding "no-use-tor" makes things work, there (as far as I can see, there is no tor dns endpoint exposed on that box). The other doesn't run tor, but adding "no-use-tor" makes things work, there, too. To summarize the running DNS relevant software: Box 1: tor (but no DNS endpoint exposed), named listening on 127.0.0.1:53 (used by /etc/resolv.conf) Box 2: named listening on 127.0.0.1:53 (used by /etc/resolv.conf), dnsdist listening on $all_public_ips:53 (used by external clients, relaying to named and iodine as needed), iodine listening on 127.0.0.1:5353 Does gnupg interpret any of these as tor dns endpoints? How does gnupg determine, how to query dns? The additional "debug dns" line didn't change anything noticeably for me, I already have "debug ipc,network,dns", so probably it's redundant? I'd prefer to use tor for retrieving keys (if possible). Is there a possibility to turn off dns resolution via tor, but still do all the rest through tor? > >> getsrv(_openpgpkey._tcp.eckner.net): Verbindung im DNS geschlossen > > (Yes, I known, GnUPG has two many debug stuff i18n). > >> I wonder, though, why the tried things differ on both machines - both run >> arch linux with gnupg 2.2.26 and libgcrypt 1.8.7, no gpg.conf. > > Any proxy, Tor software running. You may try "disable-ipv6" or > "disable-ipv4" in your dirmngr.conf. disable-ipv4 / disable-ipv6 does not make any difference (without also adding "no-use-tor", of course) > > FWIW, "gpgconf --show-versions" gives information on the used libraries, > CPU, etc. - From Box #2: - ---8<---8<---8<---8<---8<--- * GnuPG 2.2.27 (0000000) GNU/Linux * Libgcrypt 1.8.7 () version:1.8.7:10807:1.39-unknown:12700: cc:100200:gcc:10.2.0: ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20: pubkeys:dsa:elgamal:rsa:ecc: digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2: rnd-mod:linux: cpu-arch:x86: mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S: hwflist:intel-cpu:intel-fast-shld:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-rdrand:intel-avx:intel-avx2:intel-fast-vpgather:intel-rdtsc: fips-mode:n:n: rng-type:standard:1:2010000:1: * GpgRT 1.41-unknown (0000000) * Libassuan 2.5.4 (e368b40) * KSBA 1.4.0 (?) * GNUTLS 3.7.0 - --->8--->8--->8--->8--->8--- I don't see any libdns there. Box #1 only differs in the cpu flags line: - -hwflist:intel-cpu:intel-fast-shld:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-rdrand:intel-avx:intel-avx2:intel-fast-vpgather:intel-rdtsc: +hwflist:intel-cpu:intel-fast-shld:intel-ssse3:intel-sse4.1:intel-pclmul:intel-avx:intel-rdtsc: > > > Shalom-Salam, > > Werner Thank you for your time. Cheers, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAKw/gACgkQCu7JB1Xa e1qPIhAAt/r3BohQnWRd5zdV7DQmfOVEDUbhnoktk5luG/0bPy/zNc5Qr7h2h4Zp aqDM3PsghlCVlqei8S1sM+/FJi+qZzdELMFoFZ/8LCmYORTzee157oBEQXcFvE08 DT0QWeb7QNjEMvof1sKMDbdqSAxh0y+EPm6vsH/CbzRDcvjG7osLgzVNVDf5DDY7 3gUNILnsLCclF3g/u2GEBCVa1j9EaybTgsq3OTya/OVCPbCfoAzJ6FQipwH9Wow1 juUMDM57juX3/YJt5MNPZ50KDI/2E4b83t+YqNobZroZo3o7s/DuIhHiTOHWp4Kf 3BeRMmYzdd4guBsJS3b6pr+PsxXbolECE2g31lWWKck8P+rUxhkZ8kCBVIohx0s4 Ae5bXb4yCA1e/Xh4lIFi61IRcjlLNiPAoVT6hZ0bSDBjsesxdzKgHOmTteUKOLAn sE2QGl4XwN3BhJttOEXZva4GDLPAU9idw/fIljhuvu/dBn3hV6DdOl5HxLpCyVtW dDAaObvwP16TTdO7vYH0dDNC/1CjtUHnk/AeTG1eO3Ji49eJfYn++5L3GEf149Kw voRq82b/X6IGKlm2DVBbEpBUTxU1HyOrPUjC5Kl+hDINxMBmnLl5QIt54fVmhvWP +LEQD9KorvYmEnyj+f7+zbrCL0BOtuKynHRGp4mmCRWOL1cwHkI= =/2O4 -----END PGP SIGNATURE----- From wk at gnupg.org Fri Jan 22 14:49:37 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jan 2021 14:49:37 +0100 Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: <5da07512-2584-3edb-25ef-b39cdb9f4ba@eckner.net> (Erich Eckner via Gnupg-users's message of "Fri, 22 Jan 2021 13:24:22 +0100 (CET)") References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <874kjbbx3r.fsf@wheatstone.g10code.de> <615d7260-d5fe-71f0-2510-5cb67b51b7@eckner.net> <87bldjaepg.fsf@wheatstone.g10code.de> <53a2e650-118a-c84a-bc7-2f615660c6e4@eckner.net> <875z3p6xtg.fsf@wheatstone.g10code.de> <5da07512-2584-3edb-25ef-b39cdb9f4ba@eckner.net> Message-ID: <87h7n93wum.fsf@wheatstone.g10code.de> On Fri, 22 Jan 2021 13:24, Erich Eckner said: > Box 1: tor (but no DNS endpoint exposed), named listening on 127.0.0.1:53 > (used by /etc/resolv.conf) In Tor mode we use 8.8.8.8 as DNS Server unless you use --nameserver ipaddr In ``Tor mode'' Dirmngr uses a public resolver via Tor to resolve DNS names. If the default public resolver, which is 8.8.8.8, shall not be used a different one can be given us? ing this option. Note that a numerical IP address must be given (IPv6 or IPv4) and that no error checking is done for ipaddr. this is all implemented using a full DNS resolver library inside dirmngr (which you can also truns into a --recursive-resolver). If you don't want this, or DNS over Tor and if you are not on Windows you may use --standard-resolver. > Box 2: named listening on 127.0.0.1:53 (used by /etc/resolv.conf), dnsdist > listening on $all_public_ips:53 (used by external clients, relaying to > named and iodine as needed), iodine listening on 127.0.0.1:5353 > > Does gnupg interpret any of these as tor dns endpoints? How does gnupg > determine, how to query dns? In non-Tor mode /etc/resolv.conf etc is parsed. --debug dns should show errors or fallbacks for unknown statements. > The additional "debug dns" line didn't change anything noticeably for me, > I already have "debug ipc,network,dns", so probably it's redundant? I see. I would need to check how to enable all DNS debugging. You have "verbose" also in your dirmngr.conf? > I'd prefer to use tor for retrieving keys (if possible). Is there a > possibility to turn off dns resolution via tor, but still do all the rest > through tor? I don't think so. It is quite some time since I last worked on the Tor features. (dirmngr/dns-stuff.c, dirmngr/dns.c are the main files) > disable-ipv4 / disable-ipv6 does not make any difference (without also > adding "no-use-tor", of course) Sometimes it makes a difference in particular on my Windows VM. > version:1.8.7:10807:1.39-unknown:12700: Build against an older libgpg-error (aka gpgrt) version but that does not matter. > * GpgRT 1.41-unknown (0000000) That is the actual version used. > I don't see any libdns there. Box #1 only differs in the cpu flags line: No library but the (modified) implementation by William Ahern. CPU flags are not relevant here; they are runtime tested. Shalom-Salam, Werner -- * Free Assange and protect free journalism! * Germany: Sign the Treaty on the Prohibition of Nuclear Weapons! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From stefanclaas at riseup.net Fri Jan 22 16:08:59 2021 From: stefanclaas at riseup.net (Stefan Claas) Date: Fri, 22 Jan 2021 07:08:59 -0800 Subject: Fundraising In-Reply-To: <87eeid6zj3.fsf@wheatstone.g10code.de> References: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> <90f70b19-fec7-efdb-5113-882219917958@sixdemonbag.org> <87eeid6zj3.fsf@wheatstone.g10code.de> Message-ID: <4d7a7be559a49a34386dec6ef138ce78@riseup.net> On 2021-01-22 11:23, Werner Koch via Gnupg-users wrote: > You are on the best way to be one on of those few for > whom I had to flip the moderate flag. God sees everything, so to speak, dear Werner! Best regards Stefan #deplatforming does not work in a free world! From wk at gnupg.org Fri Jan 22 17:33:20 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jan 2021 17:33:20 +0100 Subject: [admin] user set to moderation (was: Fundraising) In-Reply-To: <4d7a7be559a49a34386dec6ef138ce78@riseup.net> (Stefan Claas via Gnupg-users's message of "Fri, 22 Jan 2021 07:08:59 -0800") References: <5d036eb44bf2382ff165379ecaabcd2c4802f4f8.camel@sixdemonbag.org> <90f70b19-fec7-efdb-5113-882219917958@sixdemonbag.org> <87eeid6zj3.fsf@wheatstone.g10code.de> <4d7a7be559a49a34386dec6ef138ce78@riseup.net> Message-ID: <874kj93p9r.fsf_-_@wheatstone.g10code.de> On Fri, 22 Jan 2021 07:08, Stefan Claas said: > #deplatforming does not work in a free world! I told you to behave civilized and not like that guy most US people are glad not to be anymore represented by him. I will set you to moderation for two weeks. Shalom-Salam, Werner -- * Free Assange and protect free journalism! * Germany: Sign the Treaty on the Prohibition of Nuclear Weapons! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mettodo at riseup.net Fri Jan 22 16:26:24 2021 From: mettodo at riseup.net (mettodo) Date: Fri, 22 Jan 2021 18:26:24 +0300 Subject: make check failed tests In-Reply-To: <202101221013.10984.bernhard@intevation.de> References: <202101211704.09017.bernhard@intevation.de> <3e5d12e7-00f7-8590-a496-e6f301fdc351@riseup.net> <202101221013.10984.bernhard@intevation.de> Message-ID: <3d68d52f-a9ec-a32d-7cdd-0becfdd53f23@riseup.net> Hi Bernhard, I thought I had installed libgpg-error-1.41 properly. I just tried to install it again and after "make install" I got the messages on the attached text .? From what I understand I didn?t get any problem with GnuPG "configure", you can check the attached text. Thanks! Unai On 22/01/2021 12:13, Bernhard Reiter wrote: > Hi Mettodo, > > Am Freitag 22 Januar 2021 07:02:34 schrieb mettodo: >> I do not exactly know what you ask for, let me know if this is not enough: >> - Ubuntu 18.04.5 LTS >> - gcc version 7.5.0 >> - Attached text with failed checks > yes, this is a good start to get, so others are able to give you more > suggestions. > > As far as I can see, it is all the same error: > symbol gpgrt_getcwd version GPG_ERROR_1.0 not defined in file > libgpg-error.so.0 with link time reference > > Looks like you may need a newer version of libgpg-error (as far as I can see > gpgrt_getcwd was introduced with 1.27 of libgpg-error). > Did you build libgpg-error yourself? If so, what version? > > The "configure" script should have complained, was it saying okay? > > Best Regards, > Bernhard > -------------- next part -------------- **libgpg-error-1.41 after make install** Making install in m4 make[1]: Entering directory '/home/mettodo/Downloads/GNUpg/libgpg-error-1.41/m4' make[2]: Entering directory '/home/mettodo/Downloads/GNUpg/libgpg-error-1.41/m4' make[2]: Nothing to be done for 'install-exec-am'. make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory '/home/mettodo/Downloads/GNUpg/libgpg-error-1.41/m4' make[1]: Leaving directory '/home/mettodo/Downloads/GNUpg/libgpg-error-1.41/m4' Making install in src make[1]: Entering directory '/home/mettodo/Downloads/GNUpg/libgpg-error-1.41/src' make install-am make[2]: Entering directory '/home/mettodo/Downloads/GNUpg/libgpg-error-1.41/src' make[3]: Entering directory '/home/mettodo/Downloads/GNUpg/libgpg-error-1.41/src' /bin/mkdir -p '/usr/local/lib' /bin/bash ../libtool --mode=install /usr/bin/install -c libgpg-error.la '/usr/local/lib' libtool: install: /usr/bin/install -c .libs/libgpg-error.so.0.31.1 /usr/local/lib/libgpg-error.so.0.31.1 /usr/bin/install: cannot remove '/usr/local/lib/libgpg-error.so.0.31.1': Permission denied Makefile:797: recipe for target 'install-libLTLIBRARIES' failed make[3]: *** [install-libLTLIBRARIES] Error 1 make[3]: Leaving directory '/home/mettodo/Downloads/GNUpg/libgpg-error-1.41/src' Makefile:1471: recipe for target 'install-am' failed make[2]: *** [install-am] Error 2 make[2]: Leaving directory '/home/mettodo/Downloads/GNUpg/libgpg-error-1.41/src' Makefile:1465: recipe for target 'install' failed make[1]: *** [install] Error 2 make[1]: Leaving directory '/home/mettodo/Downloads/GNUpg/libgpg-error-1.41/src' Makefile:512: recipe for target 'install-recursive' failed make: *** [install-recursive] Error 1 **GnuPG 2.2.27. After running ./configure** GnuPG v2.2.27 has been configured as follows: Revision: 0c103cde0 (3088) Platform: GNU/Linux (x86_64-pc-linux-gnu) OpenPGP: yes S/MIME: yes Agent: yes Smartcard: yes (without internal CCID driver) G13: no Dirmngr: yes Gpgtar: yes WKS tools: yes Protect tool: (default) LDAP wrapper: (default) Default agent: (default) Default pinentry: (default) Default scdaemon: (default) Default dirmngr: (default) Dirmngr auto start: yes Readline support: no LDAP support: no TLS support: ntbtls TOFU support: no Tor support: yes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From gnupg-users at spodhuis.org Fri Jan 22 17:00:19 2021 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Fri, 22 Jan 2021 11:00:19 -0500 Subject: RSS/Atom for the GnuPG blog? In-Reply-To: <87ft2ueff6.fsf@nyarlathotep> References: <87eeiey4ec.fsf@delllaptop.lockywolf.net> <87ft2ueff6.fsf@nyarlathotep> Message-ID: On 2021-01-21 at 11:46 +0100, jman wrote: > There's no direct RSS/Atom feed (afaics). However the blog is a git > repository [0] with a RSS/Atom feed (there's a link at the bottom of the > page). As a workaround you subscribe to that feed (I didn't test it). I have tested it: I use Slack with the /feed command to manage some topic channels dedicated to RSS feeds on that topic. This is how I first saw the libgcrypt 1.9.0 announcement. That feed is subscribed to: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git;a=rss;f=web/index.org Not all GnuPG related updates make it across to the doc repo in a timely manner, but it's still a useful feed: the docs site is almost entirely updated only for new releases so this is high signal/noise. I have this in my #feed-releases channel. -Phil From bernhard at intevation.de Fri Jan 22 17:59:51 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 22 Jan 2021 17:59:51 +0100 Subject: make check failed tests In-Reply-To: <3d68d52f-a9ec-a32d-7cdd-0becfdd53f23@riseup.net> References: <202101221013.10984.bernhard@intevation.de> <3d68d52f-a9ec-a32d-7cdd-0becfdd53f23@riseup.net> Message-ID: <202101221800.03689.bernhard@intevation.de> Hi Mettodo, Am Freitag 22 Januar 2021 16:26:24 schrieb mettodo via Gnupg-users: > I thought I had installed libgpg-error-1.41 properly. I just tried to > install it again and after "make install" I got the messages on the > attached text .? (looks like you've tried to reinstall it again, but without the necessary rights to be able to overwrite the previous version) > From what I understand I didn?t get any problem with GnuPG "configure", > you can check the attached text. I'm at a loss here, too. Maybe the tests somehow get a different library? Does an ldd ./t-stringhelp (in the right directory) give you any ideas about which libgpg-error library it takes? 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: 659 bytes Desc: This is a digitally signed message part. URL: From gnupg at eckner.net Fri Jan 22 18:05:54 2021 From: gnupg at eckner.net (Erich Eckner) Date: Fri, 22 Jan 2021 18:05:54 +0100 (CET) Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: <87h7n93wum.fsf@wheatstone.g10code.de> References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <874kjbbx3r.fsf@wheatstone.g10code.de> <615d7260-d5fe-71f0-2510-5cb67b51b7@eckner.net> <87bldjaepg.fsf@wheatstone.g10code.de> <53a2e650-118a-c84a-bc7-2f615660c6e4@eckner.net> <875z3p6xtg.fsf@wheatstone.g10code.de> <5da07512-2584-3edb-25ef-b39cdb9f4ba@eckner.net> <87h7n93wum.fsf@wheatstone.g10code.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, first: Maybe I should migrate this discussion to the bug tracker? But I'm always somewhat hesitant to open new bugs, because I always assume, I'm just too stupid to properly configure everything :-) On Fri, 22 Jan 2021, Werner Koch wrote: > On Fri, 22 Jan 2021 13:24, Erich Eckner said: > >> Box 1: tor (but no DNS endpoint exposed), named listening on 127.0.0.1:53 >> (used by /etc/resolv.conf) > > In Tor mode we use 8.8.8.8 as DNS Server unless you use > > --nameserver ipaddr > > In ``Tor mode'' Dirmngr uses a public resolver via Tor to resolve > DNS names. If the default public resolver, which is 8.8.8.8, > shall not be used a different one can be given us? ing this option. > Note that a numerical IP address must be given (IPv6 or IPv4) and > that no error checking is done for ipaddr. > > this is all implemented using a full DNS resolver library inside dirmngr > (which you can also truns into a --recursive-resolver). If you don't > want this, or DNS over Tor and if you are not on Windows you may use > --standard-resolver. standard-resolver works (in DNS) on box 1, all other options (even "nameserver 127.0.0.1") give: 4 - 17:25:37 dirmngr[3382567.6]: DBG: dns: resolve_dns_name(openpgpkey.eckner.net): Permission denied 4 - 17:25:37 dirmngr[3382567.6]: DBG: dns: getsrv(_openpgpkey._tcp.eckner.net): Permission denied However, with "standard-resolver" dns works, but the actual fetch fails: 4 - 17:28:28 dirmngr[3383211.6]: DBG: dns: resolve_dns_name(openpgpkey.eckner.net): Success 4 - 17:28:28 dirmngr[3383211.6]: can't connect to 'openpgpkey.eckner.net': Permission denied 4 - 17:28:28 dirmngr[3383211.6]: error connecting to 'https://openpgpkey.eckner.net/.well-known/openpgpkey/eckner.net/hu/81t9qcnyscdr3uatodn7eejogt6tpa8q?l=erich': Permission denied 4 - 17:28:28 dirmngr[3383211.6]: command 'WKD_GET' failed: Permission denied This means, the connection through tor fails, right? This is strange, because a plain curl -x socks5h://127.0.0.1:9050 'https://openpgpkey.eckner.net/.well-known/openpgpkey/eckner.net/hu/81t9qcnyscdr3uatodn7eejogt6tpa8q?l=erich' and also with -4 or -6 works just fine. Looking at tor's log, I see: Tor[2692608]: Your application (using socks5 to port 443) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via privoxy or socat) instead. For more information, please see https://wiki.torproject.org/TheOnionRouter/TorFAQ#SOCKSAndDNS. Rejecting. [1 similar message(s) suppressed in last 5 seconds] This is probably due to "SafeSocks 1" in my torrc. So gnupg resolves the ip and tries to connect to that directly through tor, but tor refuses to do that. It would be really nice, if the name resolution could be handed over to the socks layer, but at least, I now understand, why it fails (and that I probably have no other choice as to disable SafeSocks in tor or not-use tor for gpg). > >> Box 2: named listening on 127.0.0.1:53 (used by /etc/resolv.conf), dnsdist >> listening on $all_public_ips:53 (used by external clients, relaying to >> named and iodine as needed), iodine listening on 127.0.0.1:5353 >> >> Does gnupg interpret any of these as tor dns endpoints? How does gnupg >> determine, how to query dns? > > In non-Tor mode /etc/resolv.conf etc is parsed. --debug dns should show > errors or fallbacks for unknown statements. I was more wondering, why gpg decides to go into "tor mode" on box #2, when there is actually no tor installed or running. I'm totally happy to force non-tor mode via config file, but I'm also open to help find the root for gpg's misjudgement of tor-availability. > >> The additional "debug dns" line didn't change anything noticeably for me, >> I already have "debug ipc,network,dns", so probably it's redundant? > > I see. I would need to check how to enable all DNS debugging. You have > "verbose" also in your dirmngr.conf? yes, my current content is: log-file socket:///home/erich/.gnupg/dirmngr.log verbose debug ipc,network,dns Note, that I *do* see some dns lines (the ones which I posted earlier). > >> I'd prefer to use tor for retrieving keys (if possible). Is there a >> possibility to turn off dns resolution via tor, but still do all the rest >> through tor? > > I don't think so. It is quite some time since I last worked on the Tor > features. (dirmngr/dns-stuff.c, dirmngr/dns.c are the main files) Well, from what you wrote before, I understood, that using --nameserver alongside --use-tor, it would query dns directly and do everything else through tor. Maybe, I got something wrong. But this doesn't matter, because I was thinking in the complete wrong direction: If I cannot solve the dns resolution problem through tor, I also cannot use tor (with my current tor config) for direct key retrieval. > >> disable-ipv4 / disable-ipv6 does not make any difference (without also >> adding "no-use-tor", of course) > > Sometimes it makes a difference in particular on my Windows VM. I agree: Switching between ip versions is always worth a trial (especially, since my ipv6 @home is actually a 6in4 routed through ukraine - - and thus also probably russia and the KGB ;-p) > > >> version:1.8.7:10807:1.39-unknown:12700: > > Build against an older libgpg-error (aka gpgrt) version but that does > not matter. > >> * GpgRT 1.41-unknown (0000000) > > That is the actual version used. > >> I don't see any libdns there. Box #1 only differs in the cpu flags line: > > No library but the (modified) implementation by William Ahern. > > CPU flags are not relevant here; they are runtime tested. > > > Shalom-Salam, > > Werner > > -- > * Free Assange and protect free journalism! > * Germany: Sign the Treaty on the Prohibition of Nuclear Weapons! > regards, Erich P.S.: I liked the old signature better. (Nothing against political statements, but it was more witty) -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmALBfMACgkQCu7JB1Xa e1ok2w/9FsoldOMnbIoyR8vvwe0YknX2js//R/UDGuWM3POg67ua/hAtSBniXEPv Lm16zhkICUOsw2Ij8IvpMfOPE5TFfgKfP89V+6Obd9SesaoezhNKXKcO58kWdHal lt3xFlitTxC7AQT+IHeDr4hvtju5Mv/075bpDeF2LvWRyt9HJ/u+zvqFUnudsunE PKzy03bn4jgtGUWxIkWOgTkBC2SvveOyDemLJRTMUq4gLMX6P+nLV0H8sjc9+uKs /VjWDiybvZzSgIg6yZ7MHwEgdAq38rbL3rdWOWTdIMVf6KfitV0WMHsp4X2mcbFb jUdAAseak5cSNgK/3P3g/pFROYval1nmaIpQNYByYgfk/Cfb57TLWHLcB28PTpWa 8lUVw9KB2xk41jBnjHIfQf56hiKmwTS5x17EK3meOWgoDZdutadFpUJuyyHX6VIc ZR5HKNeOLTrKKNhglttvtQNCnQHMRRPPOUqDWwvfLGqxgAh/yVcZHta8rj7/cHY/ pUZ4Vmk6BzOrq9LjLZA8oahdMuHRiAGVv0EFt4U77KjvrIVqITQXsEFItua4v9O0 Ya8BnGswY+HgXZLHuntqnsS/PBnqRApaJJ4h4RGqP5UTQFoeY2G0wZ34NLul65AN DPiWQc0CEGlOmtnZ6a2Vn2NNMRBfsCG1qeP1SdU5qq4l4kabO/Y= =manV -----END PGP SIGNATURE----- From wk at gnupg.org Fri Jan 22 18:10:18 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jan 2021 18:10:18 +0100 Subject: RSS/Atom for the GnuPG blog? In-Reply-To: (Phil Pennock via Gnupg-users's message of "Fri, 22 Jan 2021 11:00:19 -0500") References: <87eeiey4ec.fsf@delllaptop.lockywolf.net> <87ft2ueff6.fsf@nyarlathotep> Message-ID: <87mtx03nk5.fsf@wheatstone.g10code.de> On Fri, 22 Jan 2021 11:00, Phil Pennock said: > That feed is subscribed to: > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git;a=rss;f=web/index.org Interesting. And I thought this repos is something nobody watches - so sorry for possibly not too polite log comments. BTW, if you are just interested in updates to our software you can check also https://versions.gnupg.org/swdb.lst for updates. Or watch the source of this list, which is is in the gnupg-doc repo as swdb.mac. The tool gnupg/build-aux/getswdb.sh might be useful for automation tasks. I use it as part of the release process. Commit subject lines are also posted to twitter @gnuprivacyguard and I tend to tweet about new gnupg versions at @gnupg. But yes, an RSS feed for the blog and gnupg-announce would indeed be useful. Shalom-Salam, Werner -- * Free Assange and protect free journalism! * Germany: Sign the Treaty on the Prohibition of Nuclear Weapons! -------------- 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 Jan 22 18:29:56 2021 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 22 Jan 2021 12:29:56 -0500 Subject: WKD proper behavior on fetch error In-Reply-To: <87lfcm6uzk.wl-neal@walfield.org> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <87o8hkj2nn.fsf@fifthhorseman.net> <780b90f468c3e160b56121e2ed02a564cb0429f8.camel@16bits.net> <87czxyi83s.fsf@fifthhorseman.net> <87lfcm6uzk.wl-neal@walfield.org> Message-ID: <87a6t0hobv.fsf@fifthhorseman.net> On Thu 2021-01-21 18:49:19 +0100, Neal H. Walfield wrote: > Please don't do this. This is the format of a TPK: > > https://tools.ietf.org/html/rfc4880#section-11.1 > > It doesn't allow arbitrary packets to follow it, as far as I can see. fair enough. It also doesn't allow arbitrary trailing NUL octets to follow it, so i was just trying to at least make the subsequent octets parseable. But i agree that perhaps there are still potential failures. > Now, there are few things we could do: we could inject a bad > signature. Some implementations won't discard bad signatures, so this > is probably a bad idea. i think many implementations would treat a signature from an unknown party as something worth keeping. that is, they wouldn't be able to distinguish a bad signature from an unknown signature. so another approach would be to create a bad signature that claims to be from the primary key itself -- that is a *known bad* signature, so it should be possible to discard it. > We could append a public key packet with fixed creation time and MPIs, > and a direct key signature, which is filled with junk. Interesting. this would likely be interpreted as the start of another OpenPGP certificate, if i understand correctly. at the moment, i think wkd instructs client to expect at most two certificates (one expired and one active), but i don't know whether clients are strict about this check. this would show up as a third certificate. > Implementations would detect this as an invalid key for several > different reasons (no valid self signature, for instance). The risk with this approach is that an implementation that isn't strict about requiring a valid self-signature might see this as a usable key for the address they're looking up in WKD. What if the public key packet was instead using a reserved algorithm? then it would be unparseable and unusable by the client even if they mistakenly thought it was the right one? > And, implementations in the know could recognize the public key packet > as being padding and no even emit a warning about an invalid > certificate. That would definitely be a nice outcome. a dedicated/dummy key type would facilitate this kind of discarding too. what do you think? > Another approach to make the data uncompressable would be to encrypt > the keyring with, say, AES and include the key. this is a non-backward-compatible change to the format, so i think that's probably not a great outcome. --dkg From angel at pgp.16bits.net Fri Jan 22 20:52:35 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 22 Jan 2021 20:52:35 +0100 Subject: make check failed tests In-Reply-To: <202101221800.03689.bernhard@intevation.de> References: <202101221013.10984.bernhard@intevation.de> <3d68d52f-a9ec-a32d-7cdd-0becfdd53f23@riseup.net> <202101221800.03689.bernhard@intevation.de> Message-ID: <91cb3170f54ce0135a8ff0e2e81ff21ec172554a.camel@16bits.net> On 2021-01-22 at 17:59 +0100, Bernhard Reiter wrote: > > From what I understand I didn?t get any problem with GnuPG > > "configure", > > you can check the attached text. > > I'm at a loss here, too. > Maybe the tests somehow get a different library? > Does an > ldd ./t-stringhelp > (in the right directory) > give you any ideas about which libgpg-error library it takes? > > Best Regards, > Bernhard It is probably picking the system library, not the manually installed libgpg-error (I assume a new one was installed as well?) Try running LD_LIBRARY_PATH=$MYPREFIX/lib make check where $MYPREFIX is the value of --prefix that you passed to ./configure or /usr/local (the default) if not provided i.e. LD_LIBRARY_PATH=/usr/local/lib make check Regards ?ngel From gnupg at eckner.net Fri Jan 22 20:59:10 2021 From: gnupg at eckner.net (Erich Eckner) Date: Fri, 22 Jan 2021 20:59:10 +0100 (CET) Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <874kjbbx3r.fsf@wheatstone.g10code.de> <615d7260-d5fe-71f0-2510-5cb67b51b7@eckner.net> <87bldjaepg.fsf@wheatstone.g10code.de> <53a2e650-118a-c84a-bc7-2f615660c6e4@eckner.net> <875z3p6xtg.fsf@wheatstone.g10code.de> <5da07512-2584-3edb-25ef-b39cdb9f4ba@eckner.net> <87h7n93wum.fsf@wheatstone.g10code.de> Message-ID: <7889404e-b5b2-3d74-6b3e-efb86ffa5a97@eckner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, 22 Jan 2021, Erich Eckner via Gnupg-users wrote: > I was more wondering, why gpg decides to go into "tor mode" on box #2, when > there is actually no tor installed or running. I'm totally happy to force > non-tor mode via config file, but I'm also open to help find the root for > gpg's misjudgement of tor-availability. I found it! https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libassuan.git;a=blob;f=src/assuan-socket.c;h=9a24f1a11fbe4e7973fbd6b82a602abe1a009e8e;hb=HEAD#l1106 libassuan merely tries to connect via socks on the correct port (9050 for tor). I have a ssh socks proxy running on that port. Thank you for your time! For everyone to benefit from my problem, I'd like to suggest to clarify in the documentation, that and how tor will be auto-detected (really just a suggestion, feel free to reject or ignore it). cheers, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmALLpEACgkQCu7JB1Xa e1rXhg//WhrPIi6tcW0as1ghKhHjzeQyubz7tvgqhPyPvBbJZuiTvY32gkE8tFKp AAKhVTXxra+izWJup3cfHFmvafTeTRMcFy6z3E+nsE4UscJNvdSAa6IB92iCAYZz UsXWTSu+L3gwryLFuplPUi76HxGGwfbm+4HqY9bo4dw9RvPGWzR2gms9VFwSg0AV Pf2G7VakRLgki5zpBVQBKtbRzoj08X99mRpILF3QJWeYUe5FXAWyH7h6JAUZbmDt YkeHv/b6OhYeZRss/WPuSubP1nMWykBfExj+nPziU6Ojli4oIGQWjJyJ428R/0vl skfUigllJERvqcquRvZ2yNmPQg7aJv2yGdIYQ7wjyrZlN6QDIy+DujE9OEfM3t0X 28uCFuC38tIeyUhgK23dpmwZG3PZCaUp9un7/YhLudshCiLbZmq6uyovkuk5xqBj xn0gkizzrPEjCo6GrOhqqJrdMW2vxwVc9hXHddqmvYWwWD8jMYwcwqrTS7Qw6DFz rv+1C+z+rpIerlCR1NbSHR2KBf1oTU7hm8v7SoZKSZtSguRwbNQq1ke8jLkP+cPG DnR2hZnaQ8x/lhCBabPAv5B2Prxmg9xgmAcDQIR11kt9/cxpfPLb2avwVRQ3M9Hn QfaDDPpPFAR2sAZuviViISECKUepWx79VPcBPcq2SmE6Wo9FAZM= =OPMp -----END PGP SIGNATURE----- From angel at pgp.16bits.net Fri Jan 22 21:13:25 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 22 Jan 2021 21:13:25 +0100 Subject: gpg: error retrieving 'erich@eckner.net' via WKD: Connection closed in DNS In-Reply-To: References: <90e2f419-6df7-8592-9728-a8676bfcd4b7@eckner.net> <874kjbbx3r.fsf@wheatstone.g10code.de> <615d7260-d5fe-71f0-2510-5cb67b51b7@eckner.net> <87bldjaepg.fsf@wheatstone.g10code.de> <53a2e650-118a-c84a-bc7-2f615660c6e4@eckner.net> <875z3p6xtg.fsf@wheatstone.g10code.de> <5da07512-2584-3edb-25ef-b39cdb9f4ba@eckner.net> <87h7n93wum.fsf@wheatstone.g10code.de> Message-ID: <5a85096bee8a39566ff14d0d1f2f522c94c92934.camel@16bits.net> On 2021-01-22 at 18:05 +0100, Erich Eckner via Gnupg-users wrote: > > I was more wondering, why gpg decides to go into "tor mode" on box #2, > when there is actually no tor installed or running. I'm totally happy to > force non-tor mode via config file, but I'm also open to help find the > root for gpg's misjudgement of tor-availability. The check is in dirmngr.c: > int > dirmngr_use_tor (void) > { > if (tor_mode == TOR_MODE_AUTO) > { > /* Figure out whether Tor is running. */ > assuan_fd_t sock; > > sock = assuan_sock_connect_byname (NULL, 0, 0, NULL, ASSUAN_SOCK_TOR); > if (sock == ASSUAN_INVALID_FD) > tor_mode = TOR_MODE_NO; > else > { > tor_mode = TOR_MODE_YES; > assuan_sock_close (sock); > } That assuan_sock_connect_byname() tests the connection by connecting to both tor port (9050) and the tor browser port (9150). It actually starts negotiating a request (see socks5_connect) > > /* For HOST being NULL we pass an empty string which indicates to > socks5_connect to stop midway during the proxy negotiation. Note > that we can't pass NULL directly as this indicates IP address I don't see how it would automatically treat it as having tor unless you have a socks server on either 9050 or 9150. Best regards From gnupg-users at spodhuis.org Fri Jan 22 21:39:58 2021 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Fri, 22 Jan 2021 15:39:58 -0500 Subject: RSS/Atom for the GnuPG blog? In-Reply-To: <87mtx03nk5.fsf@wheatstone.g10code.de> References: <87eeiey4ec.fsf@delllaptop.lockywolf.net> <87ft2ueff6.fsf@nyarlathotep> <87mtx03nk5.fsf@wheatstone.g10code.de> Message-ID: On 2021-01-22 at 18:10 +0100, Werner Koch via Gnupg-users wrote: > BTW, if you are just interested in updates to our software you can check > also https://versions.gnupg.org/swdb.lst for updates. Or watch the > source of this list, which is is in the gnupg-doc repo as swdb.mac. > > The tool gnupg/build-aux/getswdb.sh might be useful for automation > tasks. I use it as part of the release process. > > Commit subject lines are also posted to twitter @gnuprivacyguard and I > tend to tweet about new gnupg versions at @gnupg. But yes, an RSS feed > for the blog and gnupg-announce would indeed be useful. What would be most useful for me is an RSS feed of changes to swdb.lst; I retrieve that file when doing a fresh package build, so will always be up-to-date when there's a new release of gnupg but not always between times. I haven't bothered building my own gateway to RSS for this; the setup was mostly "find the RSS feeds for projects I care about and add them", not, at the time I set it up, spending time on stuff for each project. Like it or not, RSS is the common language for "new event in a series limited to at most a few events a day but sometimes months between events" for stuff on the web. It's not just for desktop dedicated apps, but also integrations into other products. So the team chat product I use (closed source, not naming again) has channels, and I have #feed-blogposts, #feed-releases, #feed-security, #feed-status. Then in #feed-releases I just `/feed subscribe ` for URLs for OpenSSL, GnuPg, Kubernetes, various programming languages, etc. If there were an RSS feed of swdb.lst then it would be easier to set it up as a trigger in a CI system to auto-build packages. All the sorts of things that _can_ be done without it, but life is just easier when the support is baked in for the common interchange format. -Phil From andre at colomb.de Fri Jan 22 22:15:19 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Fri, 22 Jan 2021 22:15:19 +0100 Subject: Please tackle the Right Thing In-Reply-To: <3d693337c4a59a4ac871e297433d3fc418d86a8e.camel@16bits.net> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> <7441f18a-8e59-3ec0-5b22-b535667bf38e@colomb.de> <3d693337c4a59a4ac871e297433d3fc418d86a8e.camel@16bits.net> Message-ID: Hi all, On 21/01/2021 01.29, ?ngel wrote: >> If that does not conclude with a successful HTTP response (e.g. >> status code 2xx), they MUST fall back to the direct method. If the >> required sub-domain exists, but other errors occur during the >> connection, they SHOULD output an error message pointing out the >> failure reason to the end user. Such other errors include, for >> example, invalid, expired or misconfigured TLS certificates and HTTP >> failure codes (4xx or 5xx). > > Suitable return codes for fetching a key would be 200 (for successful > keys) and 404 (the key is not in the server). In both cases, if it is a > valid wkd server, the server shouldn't fall back to direct. Restricting to only the 200 OK status code would probably be fine. I looked at the other 2xx codes and probably no others would apply to WKD. Not quite sure about 228 IM Used (not familiar with RFC 3229). I tend to disagree regarding the 404 case though. As this thread has shown, there might be legitimate use cases where a WKD user has enough control over the domain's web server to set up the direct method. But there might be a wildcard subdomain entry with a webserver and (valid) TLS setup, totally unrelated to WKD, which is not under the same user's control. In that case, the unrelated webserver would happily answer the openpgpkey subdomain request, but simply not find the required directory structure, giving a 404. My proposed solution would give the user a chance to still enjoy the WKD direct method. > You could also have a 304 if the client was refreshing a key. Maybe 201 > if a web-based submission protocol was added in the future. Agree, 304 kind of makes sense, although the WKD client first needs to implement the associated caching / Last-Modified header logic. Not sure it that's worth the effort to explicitly mention it in the WKD protocol. Other 2xx codes could be discussed. 201 Created doesn't make much sense for the GET request, but could also convey that a key was just auto-generated on the fly, e.g. for opportunistic encryption? I would understand a 204 No Content status to mean "yes, this is a WKD server and the requested user is known. There is just deliberately no key offered." In that case stopping without fallback would be desired. All of these somehow acknowledge that the requested .well-known/... resource does make sense to the responding server. Hence my proposal for a generous 2xx in the specification. > I think the main status that would bring such trouble would be 401, > 403, 5xx, although there could be some exotic cases (e.g. 407). > Erroring to the user on any status code the client does not know how to > handle seems the safe procedure. Agree, let's not complicate the protocol with hard-to-implement, very specific error handling rules. One more needed change if the above proposal is accepted: ---SNIP--- (page 4, first paragraph in the current draft version 11) Sites which do not use the advanced method but employ wildcard DNS for their sub-domains MUST make sure that the "openpgpkey" sub-domain is not subject to the wildcarding. This can be done by inserting an empty TXT RR for this sub-domain. ---SNIP--- That MUST becomes a SHOULD, in order to avoid traffic by falling back early. But with the new fallback cases, it's no longer *required*. Regarding where this is discussed, I hope Werner will pick up relevant pieces for a draft version 12 in order to unify the now differing implementations. IIUC, he is the main (and only?) draft author, so before IETF gets formally involved, the draft proposal can be iterated easily. Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Fri Jan 22 23:59:36 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 22 Jan 2021 22:59:36 +0000 Subject: WKD proper behavior on fetch error In-Reply-To: <87a6t0hobv.fsf@fifthhorseman.net> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <87o8hkj2nn.fsf@fifthhorseman.net> <780b90f468c3e160b56121e2ed02a564cb0429f8.camel@16bits.net> <87czxyi83s.fsf@fifthhorseman.net> <87lfcm6uzk.wl-neal@walfield.org> <87a6t0hobv.fsf@fifthhorseman.net> Message-ID: <8c263bce-b1f4-70de-456f-54c14bc5cb65@andrewg.com> On 22/01/2021 17:29, Daniel Kahn Gillmor via Gnupg-users wrote: > this is a non-backward-compatible change to the format, so i think > that's probably not a great outcome. I can't help thinking that length fingerprinting and padding oracles are a general concern, and therefore more appropriately solved at a lower layer of the network stack. A -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jscott at posteo.net Sat Jan 23 04:11:53 2021 From: jscott at posteo.net (John Scott) Date: Fri, 22 Jan 2021 22:11:53 -0500 Subject: Help with GPGME keylisting not listing signatures Message-ID: <806052122.0ifERbkFSE@t450> I'm having trouble writing a program using GPGME that is able to read the signatures of keys from a file. I've ensured that GPGME_KEYLIST_MODE_SIGS is specified and would appreciate additional eyeballs on it. I've tested it with the Debian keyring which has many signatures and not had any luck. The code is at https://salsa.debian.org/-/snippets/519 or can be cloned from https://salsa.debian.org/snippets/519.git I'm using GPGME 1.14.0-1+b2 on Debian Bullseye (testing) with GnuPG 2.2.20 and libgcrypt 1.8.7. Thanks! John -------------- 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 angel at pgp.16bits.net Sat Jan 23 04:17:46 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sat, 23 Jan 2021 04:17:46 +0100 Subject: Please tackle the Right Thing In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210115005604.nlhu3nnvzjdalzxw@raf.org> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> <7441f18a-8e59-3ec0-5b22-b535667bf38e@colomb.de> <3d693337c4a59a4ac871e297433d3fc418d86a8e.camel@16bits.net> Message-ID: On 2021-01-22 at 22:15 +0100, Andr? Colomb wrote: > Restricting to only the 200 OK status code would probably be fine. I > looked at the other 2xx codes and probably no others would apply to WKD. > Not quite sure about 228 IM Used (not familiar with RFC 3229). > > I tend to disagree regarding the 404 case though. As this thread has > shown, there might be legitimate use cases where a WKD user has enough > control over the domain's web server to set up the direct method. But > there might be a wildcard subdomain entry with a webserver and (valid) > TLS setup, totally unrelated to WKD, which is not under the same user's > control. In that case, the unrelated webserver would happily answer the > openpgpkey subdomain request, but simply not find the required directory > structure, giving a 404. My proposed solution would give the user a > chance to still enjoy the WKD direct method. That's the point where the fact that a WKD server MUST have a policy file become useful for a fetching-only client. If it's a real WKD server the file shall be there, if it's a 404, that's probably meaningless. GnuPG first tries to directly fetch the key from the url where it's supposed to be. If it's found, it finishes there. If that's a 404, it then check that there is a policy file (and if there's not, the process caches in memory that there is no WKD on that place and won't contact that server again) On the other hand, flowcrypt first tries to read the policy file, and only after that succeeds, does it go for the public key. On this line, a few days ago I suggested changing the draft to require fallback to direct if such file is missing (as opposed to considering that the openpgpkey subdomain exists just when having an A/AAA record): > - An idea that seems worth considering, inspired by the way flowcrypt > does its check, is to fall back to the direct method if the > openpgpkey subdomain exists but it doesn't serve a policy file. > > This would solve the issue of non-malicious NXDOMAIN hijackings or > DNS wildcards (assuming the certificate was valid). https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064741.html and over the course of the days, I have only become more convinced that this would be a good idea. It doesn't impose any new restriction on existing servers, clarifies when a wkd subdomain "exists" (if it has the appropiate files), neatly solves the exposed cases of unintended wildcard domains (when properly configured), and uses a way available for web clients (which might not be able to obtain the DNS response). Best regards From dkg at fifthhorseman.net Tue Jan 19 17:46:04 2021 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 19 Jan 2021 11:46:04 -0500 Subject: WKD proper behavior on fetch error In-Reply-To: <87pn21ceoc.fsf@wheatstone.g10code.de> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> Message-ID: <87o8hkj2nn.fsf@fifthhorseman.net> On Tue 2021-01-19 13:08:19 +0100, Werner Koch via Gnupg-users wrote: > On Tue, 19 Jan 2021 09:28, Neal H. Walfield said: > >> When you look up the openpgpkey.example.org domain, you are revealing >> to anyone snooping DNS traffic that you are using OpenPGP and are >> looking for a key related to example.org. That's a privacy issue. > > No, it isn't. The next thing you do is to send the mail and get a > reply. I think it's fair to say that this is in fact a privacy issue, stemming from the fact that the act of sending an e-mail to a given recipient these days is largely invisible to the network monitor -- the user agent typically speaks on the network only to user's mail submission agent (and that only through an encrypted connection). any party monitoring the user agent only sees the rough size of the message as it passes to the MSA. Given that situation, there are at least four different forms of privacy leak (in descending order of importance) from using WKD: - the DNS lookup Neal describes above typically happens in the clear, and is visible to anyone watching your DNS traffic. (even with encrypted DNS transport like DoT or DoH, your trusted resolver sees it). Those same parties won't get to know that you're sending mail to someone in that domain otherwise. - When your client does the TLS handshake with openpgpkey.example.org for the HTTPS lookup, that leaks the domain name in the SNI field. This means that anyone observing your network traffic (even if you were using encrypted DNS transport) *also* learns that you're sending mail to someone in that domain. They would not know this otherwise. (this can be fixed with TLS Encrypted Client Hello, but that extension is still under development, must be supported by both HTTPS client and server, and far from widespread) - For many domains, the webserver operator is not the same party as the party that operates the e-mail infrastructure. Thus, when a WKD lookup is made, the webserver operator learns information that they would not have access to without running the mailservers for the domain. Note that the webserver operator also knows *exactly* which address the user has looked up, not just the domain -- while the local part is hashed, that hash can be reversed for low-entropy local parts; and in the current WKD spec the client actually reverses it directly with the l= query parameter. - Finally, even if the webserver operator has access to the same information as the mailserver, the recipient's key is often looked up via WKD *before* the message is sent, so it's possible that the user might not send the mail, or might only send the mail much later, or from a different network. This is a temporal privacy leak, similar in form to the "foo is typing?" notifications displayed by some instant messengers. Now, comparing any of these privacy leaks to the risks of sending e-mail in the clear is another story -- people might well be willing to accept the risks, or to be comfortable with them being mitigated by some of the measures i've outlined above. One could imagine a repressive regime on a crusade against leakers, asking their local ISPs to inform them whenever someone prepares to send an OpenPGP-encrypted e-mail to any e-mail address in the @dissenting-newsroom.example domain, regardless of whether the message is actually sent. Widespread use of WKD would facilitate this kind of risk to press freedom, even if the would-be leakers (and the newsroom) were careful to use mailservers outside of the national jurisdiction. WKD offers a huge boost in the usability of OpenPGP for e-mail, but we shouldn't claim that it doesn't introduce any new privacy concerns. --dkg From kloecker at kde.org Sat Jan 23 16:39:30 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sat, 23 Jan 2021 16:39:30 +0100 Subject: Help with GPGME keylisting not listing signatures In-Reply-To: <806052122.0ifERbkFSE@t450> References: <806052122.0ifERbkFSE@t450> Message-ID: <3153371.sksYtiFmj9@breq> On Samstag, 23. Januar 2021 04:11:53 CET John Scott via Gnupg-users wrote: > I'm having trouble writing a program using GPGME that is able to read the > signatures of keys from a file. I've ensured that GPGME_KEYLIST_MODE_SIGS is > specified and would appreciate additional eyeballs on it. I've tested it > with the Debian keyring which has many signatures and not had any luck. > > The code is at https://salsa.debian.org/-/snippets/519 or can be cloned from > https://salsa.debian.org/snippets/519.git Did you have a look at GPGME's tests as working example code? There is a test for listing signatures: https://dev.gnupg.org/source/gpgme/browse/master/tests/gpg/t-keylist-sig.c Also: Did you run your program with debug output? You can enable GPGME's debug output with the environment variable GPGME_DEBUG=. See https://dev.gnupg.org/source/gpgme/browse/master/src/debug.h for the different debug levels. With debug level 7 (DEBUG_SYSIO) you'll see (among a lot of other debug output) with which arguments GPGME calls gpg. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From neal at walfield.org Sat Jan 23 23:33:16 2021 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 23 Jan 2021 23:33:16 +0100 Subject: WKD proper behavior on fetch error In-Reply-To: <8c263bce-b1f4-70de-456f-54c14bc5cb65@andrewg.com> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <87o8hkj2nn.fsf@fifthhorseman.net> <780b90f468c3e160b56121e2ed02a564cb0429f8.camel@16bits.net> <87czxyi83s.fsf@fifthhorseman.net> <87lfcm6uzk.wl-neal@walfield.org> <87a6t0hobv.fsf@fifthhorseman.net> <8c263bce-b1f4-70de-456f-54c14bc5cb65@andrewg.com> Message-ID: <87im7n707n.wl-neal@walfield.org> On Fri, 22 Jan 2021 23:59:36 +0100, Andrew Gallagher via Gnupg-users wrote: > On 22/01/2021 17:29, Daniel Kahn Gillmor via Gnupg-users wrote: > > this is a non-backward-compatible change to the format, so i think > > that's probably not a great outcome. > > I can't help thinking that length fingerprinting and padding oracles are > a general concern, and therefore more appropriately solved at a lower > layer of the network stack. Padding needs to happen as close to the application as possible. Consider the case where an application has two possible responses: a 1 bit response and a 100 MB response. Most padding schemes won't obfuscate these two responses. Using dkg's suggestion, all 1-bit responses would be padded to 4k and hence all responses would still be fully distinguishable. For a padding scheme to be useful, many different types of messages must end up in the same size bucket. Ensuring that requires application-specific knowledge. Neal From dkg at fifthhorseman.net Sun Jan 24 16:14:05 2021 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 24 Jan 2021 10:14:05 -0500 Subject: WKD proper behavior on fetch error In-Reply-To: <8c263bce-b1f4-70de-456f-54c14bc5cb65@andrewg.com> References: <76eac0fc-52f2-1c24-66a3-3b7dafaa8379@andrewg.com> <2603351.A2BdGa5DQ2@breq> <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <874kjlb3pu.wl-neal@walfield.org> <2a1977606bf8f609645dee22e113263b75bcb73b.camel@16bits.net> <87ture8v41.wl-neal@walfield.org> <87bldl8h5r.wl-neal@walfield.org> <87pn21ceoc.fsf@wheatstone.g10code.de> <87o8hkj2nn.fsf@fifthhorseman.net> <780b90f468c3e160b56121e2ed02a564cb0429f8.camel@16bits.net> <87czxyi83s.fsf@fifthhorseman.net> <87lfcm6uzk.wl-neal@walfield.org> <87a6t0hobv.fsf@fifthhorseman.net> <8c263bce-b1f4-70de-456f-54c14bc5cb65@andrewg.com> Message-ID: <87v9bmfjuq.fsf@fifthhorseman.net> On Fri 2021-01-22 22:59:36 +0000, Andrew Gallagher via Gnupg-users wrote: > On 22/01/2021 17:29, Daniel Kahn Gillmor via Gnupg-users wrote: >> this is a non-backward-compatible change to the format, so i think >> that's probably not a great outcome. > > I can't help thinking that length fingerprinting and padding oracles are > a general concern, and therefore more appropriately solved at a lower > layer of the network stack. they are definitely a general concern for HTTPS -- and that's why TLS 1.3 includes a mechanism to provide padding at that layer as well. However, if the adversary can determine *what kind* of https traffic this is (a hint which is pretty clear given the openpgpkey.* domain name in the SNI of the TLS handshake), then the domain of the padding is much more specific. In particular, the adversary already knows the *application* layer, not just the transport layer. In such a case, the padding is best done closest to the application layer itself, because the transport layer generally doesn't know what the application layer is doing. But padding at both layers might not be bad, if you can afford it. padding as a defense against traffic analysis is far from a solved problem, generally. :( --dkg From dgouttegattat at incenp.org Wed Jan 27 12:22:23 2021 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 27 Jan 2021 11:22:23 +0000 Subject: [Announce] Pinentry 1.1.1 released Message-ID: <20210127112223.sc2hba2xjnznwc5w@dynein.local.incenp.org> Hi, The GnuPG project is pleased to announce the availability of the latest release of the collection of PIN or passphrase entry dialogs for GnuPG, Pinentry 1.1.1. Noteworthy changes in version 1.1.1 (2021-01-21) =================================== * A Pinentry for the Enlightenment environment is available. * In the GTK, QT, TQt, and curses pinentries, echoing can be disabled by pressing the backspace key prior to any other input. * The TTY pinentry now supports line editing. * The GTK pinentry now requires GTK+ 2.12.0 or a later version. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed on . On the primary server the source tarball and its signature are: ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-1.1.1.tar.bz2 ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-1.1.1.tar.bz2.sig The same files are also available via HTTP: https://gnupg.org/ftp/gcrypt/pinentry/pinentry-1.1.1.tar.bz2 https://gnupg.org/ftp/gcrypt/pinentry/pinentry-1.1.1.tar.bz2.sig Signing keys ============ The tarball is signed by the following keys: pub rsa4096 2014-03-14 [SC] Key fingerprint = 4FA2 0823 62FE 73AD 03B8 8830 A8DC 7067 E25F BABB uid Damien Goutte-Gattat pub ed25519 3030-08-24 [SC] [expires: 2030-06-30] Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA uid Werner Koch (dist signing key 2020) The first of those keys is available via a WKD lookup: $ gpg --locate-key dgouttegattat at incenp.org The second is available in https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg. Copying ======= Pinentry is copyright by g10 Code GmbH and licensed under the GNU General Public License version 2 or later (GPL-2.0+). The full text of the license is included in the COPYING file of the source distribution. Support ======= The Pinentry manual is included in the source distribution in TeXinfo format. For community support, you may ask on the gnupg-users mailing list . If you need commercial support, check out . Maintenance and development of Pinentry and of GnuPG as a whole is mostly financed by donations. Please consider donating via . -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 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 andre at colomb.de Wed Jan 27 22:49:13 2021 From: andre at colomb.de (=?UTF-8?Q?Andr=c3=a9_Colomb?=) Date: Wed, 27 Jan 2021 22:49:13 +0100 Subject: Please tackle the Right Thing In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> <7441f18a-8e59-3ec0-5b22-b535667bf38e@colomb.de> <3d693337c4a59a4ac871e297433d3fc418d86a8e.camel@16bits.net> Message-ID: On 23/01/2021 04.17, ?ngel wrote: >> control. In that case, the unrelated webserver would happily answer the >> openpgpkey subdomain request, but simply not find the required directory >> structure, giving a 404. My proposed solution would give the user a >> chance to still enjoy the WKD direct method. > > That's the point where the fact that a WKD server MUST have a policy > file become useful for a fetching-only client. If it's a real WKD > server the file shall be there, if it's a 404, that's probably > meaningless. Very good point. So that could be the second definite point to decide that the advanced method should be working and not fall back to direct. > GnuPG first tries to directly fetch the key from the url where it's > supposed to be. If it's found, it finishes there. If that's a 404, it > then check that there is a policy file (and if there's not, the process > caches in memory that there is no WKD on that place and won't contact > that server again) > On the other hand, flowcrypt first tries to read the policy file, and > only after that succeeds, does it go for the public key. Obviously another case where the draft is not clear enough, as it leads to the same setup working with some clients, but not others. The current draft has this to say about the policy file checking: [Section 3.1] The server MUST serve a Policy Flags file as specified below. That file is even required if the Web Key Directory Update Protocol is not supported. [Section 4.5] A site supporting the Web Key Directory MUST serve this file; it is sufficient if that file has a zero length. Clients may use this file to check for Web Key Directory support. > On this line, a few days ago I suggested changing the draft to require > fallback to direct if such file is missing (as opposed to considering > that the openpgpkey subdomain exists just when having an A/AAA record): > > [...] > > and over the course of the days, I have only become more convinced that > this would be a good idea. I agree it's a nice possibility to explicitly control the fallback cases. How about this suggested wording to specify client behavior: [Section 3.1] There are two variants on how to form the request URI: The advanced and the direct method. For either method, client implementations MUST first request the Policy Flags file at its respective location, described below. Implementations MUST first try the advanced method. If that results in a successful HTTP response (e.g. status code 2xx) for the Policy Flags file, it proves the intention to use the chosen method, so the client MUST NOT fall back to a different method, even when the request for the key itself indicates an error (e.g. not found). If the Policy Flags file is inaccessible, they MUST fall back to the direct method. If the required sub-domain exists, but other errors occur during the connection, implementations SHOULD output an error message pointing out the failure reason to the end user. Such other errors include, for example, invalid, expired or misconfigured TLS certificates and HTTP failure codes (4xx or 5xx). [Section 4.5] A site supporting the Web Key Directory MUST serve this file; it is sufficient if that file has a zero length. Clients MUST use this file to check for Web Key Directory support, before sending requests for any actual keys. Probably still rough around the edges and maybe not quite clear enough, but it's a starting point to attract comments on the approach. By the way, is there something like a repository to send and discuss pull requests against the WKD draft document? Or is it just hand-crafted text edited by the submitter based on suggestions? Kind regards Andr? -- Greetings... From: Andr? Colomb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From chris at mansfieldfamily.me Thu Jan 28 01:51:30 2021 From: chris at mansfieldfamily.me (Christopher Mansfield) Date: Thu, 28 Jan 2021 00:51:30 +0000 Subject: libgcrypt selftest failed Message-ID: <0101017746794baa-b4a9f5f1-8d94-4df9-9058-9365a86b89c0-000000@us-west-2.amazonses.com> Hi there, I'm running libgcrypt-1.9.0 on a Gentoo linux arm64. (actually I have 3 arm64 machines and one x86_64 machine, all running Gentoo). I use the keepassxc application on all of these machines. After updating libgcrypt in the past couple of days, keepassxc won't start on my arm64 machines anymore. If I start it from a terminal, I see this message: libgcrypt selftest: kdf (34): invalid tests data (0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF) libgcrypt selftest: kdf (34): Selftest failed The same keepassxc application works just fine on my x86_64 machine. I created a small c program that calls GCRYTL_SELFTEST and it gives the same error on my arm64 machine. No error from my x86_64 machine. Would appreciate any help with figuring out what's wrong - not sure if it's an actual bug, or maybe just the wrong build options. Thanks, Chris From kloecker at kde.org Thu Jan 28 08:42:03 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 28 Jan 2021 08:42:03 +0100 Subject: libgcrypt selftest failed In-Reply-To: <0101017746794baa-b4a9f5f1-8d94-4df9-9058-9365a86b89c0-000000@us-west-2.amazonses.com> References: <0101017746794baa-b4a9f5f1-8d94-4df9-9058-9365a86b89c0-000000@us-west-2.amazonses.com> Message-ID: <2516445.2KLZD71qlK@breq> On Donnerstag, 28. Januar 2021 01:51:30 CET Christopher Mansfield wrote: > Hi there, > > I'm running libgcrypt-1.9.0 on a Gentoo linux arm64. (actually I have 3 > arm64 machines and one x86_64 machine, all running Gentoo). I use the > keepassxc application on all of these machines. After updating libgcrypt > in the past couple of days, keepassxc won't start on my arm64 machines > anymore. If I start it from a terminal, I see this message: > > libgcrypt selftest: kdf (34): invalid tests data > (0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF) libgcrypt selftest: kdf (34): > Selftest failed > > The same keepassxc application works just fine on my x86_64 machine. > > I created a small c program that calls GCRYTL_SELFTEST and it gives the > same error on my arm64 machine. No error from my x86_64 machine. Several problems with arm64 have been reported for libgcrypt-1.9.0, e.g. https://dev.gnupg.org/T5251 I suggest to report your findings also at https://dev.gnupg.org/ to ensure that it's fixed in 1.9.1. Also: The gcrypt-devel mailing list [1] is better suited for reports/questions about libgcrypt. Regards, Ingo [1] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Jan 28 09:15:42 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Jan 2021 09:15:42 +0100 Subject: libgcrypt selftest failed In-Reply-To: <0101017746794baa-b4a9f5f1-8d94-4df9-9058-9365a86b89c0-000000@us-west-2.amazonses.com> (Christopher Mansfield's message of "Thu, 28 Jan 2021 00:51:30 +0000") References: <0101017746794baa-b4a9f5f1-8d94-4df9-9058-9365a86b89c0-000000@us-west-2.amazonses.com> Message-ID: <87sg6lxys1.fsf@wheatstone.g10code.de> On Thu, 28 Jan 2021 00:51, Christopher Mansfield said: > libgcrypt selftest: kdf (34): Selftest failed Please see the comments at https://dev.gnupg.org/T4294 which lists known bugs and fixes. In your case it is T5254 . We have fixed a couple of bugs this week and even if tehre are still some open bugs a new release will be done by tomorrow. 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 chris at mansfieldfamily.me Thu Jan 28 16:09:14 2021 From: chris at mansfieldfamily.me (Christopher Mansfield) Date: Thu, 28 Jan 2021 15:09:14 +0000 Subject: libgcrypt selftest failed In-Reply-To: <87sg6lxys1.fsf@wheatstone.g10code.de> References: <0101017746794baa-b4a9f5f1-8d94-4df9-9058-9365a86b89c0-000000@us-west-2.amazonses.com> <87sg6lxys1.fsf@wheatstone.g10code.de> Message-ID: <01010177498a9393-7cbeb4b2-6eaa-403b-9db4-f09bb98ecb1c-000000@us-west-2.amazonses.com> Great - I tried the patch from that bug and it fixes the issue. I'll use that until the new release is ready. Thanks! Chris On 2021-01-28 00:15, Werner Koch wrote: > On Thu, 28 Jan 2021 00:51, Christopher Mansfield said: > >> libgcrypt selftest: kdf (34): Selftest failed > > Please see the comments at https://dev.gnupg.org/T4294 which lists > known bugs and fixes. In your case it is T5254 . > > We have fixed a couple of bugs this week and even if tehre are still > some open bugs a new release will be done by tomorrow. > > Shalom-Salam, > > Werner From philipp at knutschmidt.de Thu Jan 28 10:53:13 2021 From: philipp at knutschmidt.de (Philipp Schmidt) Date: Thu, 28 Jan 2021 10:53:13 +0100 (CET) Subject: gpg cards Message-ID: <1387053890.17222.1611827594344@ox73.mailbox.org> Hello Everybody! I have tried to something in the docs about this, but without success. For quite a while now, I am using a yubikey as gpg card and that is working really good. Since it is risky to have only one Key, I just purchased another one to create a clone of the first. So I went ahead and copied the very same keys from the backup to the second. But trying to actually use does not work, I get an error like: 'please insert card: [?]' So. What can I do to make gpg use the card as well (if possible) ? Another thing I would really love to know is: Is it possible to use the gpg card as smartcard for the system login as well? Right now I am using the PIV functionality of the yubikey, but would really prefer to use one system. Does anybody know if that is possible? Last but not least I am still on a quest for a setup to use Full Disk Encryption and Security Token to actually decrypt the Disk on boot. Does anybody know if that is possible with a gpg card? Thanks ahead for any kind of help. Best philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: public.asc Type: application/pgp-keys Size: 1753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From mailinglist at chiraag.me Thu Jan 28 21:54:31 2021 From: mailinglist at chiraag.me (=?utf-8?B?4LKa4LK/4LKw4LK+4LKX4LONIOCyqOCyn+CysOCyvuCynOCzjQ==?=) Date: Thu, 28 Jan 2021 20:54:31 +0000 Subject: gpg cards In-Reply-To: <1387053890.17222.1611827594344@ox73.mailbox.org> References: <1387053890.17222.1611827594344@ox73.mailbox.org> Message-ID: 12021/00/27 02:03.62 ?????, Philipp Schmidt ??????: > Hello Everybody! > > I have tried to something in the docs about this, but without success. For > quite a while now, I am using a yubikey as gpg card and that is working really > good. Since it is risky to have only one Key, I just purchased another one to > create a clone of the first. So I went ahead and copied the very same keys from > the backup to the second. But trying to actually use does not work, I get an > error like: 'please insert card: [?]' So. > > What can I do to make gpg use the card as well (if possible) ? Sorry, I don't know the answer to this one, since I've never tried it. One option is simply creating a separate key and encrypting to two distinct (sub)keys, which is what I would do. You don't want to have to get rid of _both_ keys if one is compromised in some way, and having two copies of the key makes it more likely that it will be compromised or lost or whatever. > Another thing I would really love to know is: Is it possible to use the gpg > card as smartcard for the system login as well? Right now I am using the PIV > functionality of the yubikey, but would really prefer to use one system. > Does anybody know if that is possible? What I do is use my Yubikey for U2F so it functions as a secondary form of authorization. I do this for both login and screen unlocking using the libpam-u2f module. It looks like you can use libpam-poldi (http://www.g10code.com/p-poldi.html) if you want to use your Yubikey GPG key for primary authentication, but YMMV. > Last but not least I am still on a quest for a setup to use Full Disk > Encryption and Security Token to actually decrypt the Disk on boot. > > Does anybody know if that is possible with a gpg card? Possibly, but I haven't really looked into it. > Thanks ahead for any kind of help. Here's a bit of (unsolicited) advice: don't put all your eggs in one basket. I wouldn't use my GPG key to unlock my hard drive, log in, and decrypt _everything_ without having a foolproof way to get back in. In my case, for example, I use my Yubikey for everything as follows: 1. To unlock my LUKS-encrypted hard drives, I enter part of the passphrase from memory and use the yubikey for the rest. The data hard drive has a backup passphrase I never use since it's primarily unlocked by a keyfile stored in /root. The system hard drive has a backup passphrase that I don't ever use, but I also don't care since I can easily re-install the system. 2. To login, I use my Yubikey as U2F. Assuming I can get into my system HDD, I can always de-activate the U2F module to be able to get back in if my Yubikey fails. 3. I use my Yubikey as the primary key for pass, my password manager. I encrypt to a backup key that never leaves my laptop so I can still access the passwords should my Yubikey fail. At *minimum*, you should have backup options for each thing you use the Yubikey for (assuming you don't want data loss). It's like with OTP codes - *always* save the backup codes :) Sincerely, Chiraag -- ?????? ?????? Pronouns: he/him/his -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - mailinglist at chiraag.me - b0c8d720.asc Type: application/pgp-keys Size: 659 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 233 bytes Desc: OpenPGP digital signature URL: From gnupg-users at storiepvtride.it Thu Jan 28 22:10:41 2021 From: gnupg-users at storiepvtride.it (jman) Date: Thu, 28 Jan 2021 22:10:41 +0100 Subject: gpg cards In-Reply-To: <1387053890.17222.1611827594344@ox73.mailbox.org> References: <1387053890.17222.1611827594344@ox73.mailbox.org> Message-ID: <8735yksr72.fsf@nyarlathotep> Hi! Philipp Schmidt writes: > I have tried to something in the docs about this, but without > success. For quite a while now, I am using a yubikey as gpg card and > that is working really good. Since it is risky to have only one Key, I > just purchased another one to create a clone of the first. So I went > ahead and copied the very same keys from the backup to the second. But > trying to actually use does not work, I get an error like: 'please > insert card: [?]' So. This is a known issue, have a look here [0] > What can I do to make gpg use the card as well (if possible) ? You can follow the guide in that repository and move your private key to the Yubikey (be careful, once there the key *cannot* be moved anywhere else) and configure gpg to retrieve the key there (I think by adding `use-agent` in the gpg.conf file). Feel free to have a look here [1] > Another thing I would really love to know is: Is it possible to use > the gpg card as smartcard for the system login as well? Right now I am > using the PIV functionality of the yubikey, but would really prefer to > use one system. AFAIK it is possible using the Yubikey PAM module [2] but never tested and I don't know if it works for all use cases. > Last but not least I am still on a quest for a setup to use Full Disk > Encryption and Security Token to actually decrypt the Disk on boot. Off the top of my head I can think of a setup using LUKS volumes but don't have specific advice on the matter. cheers, [0] https://github.com/drduh/YubiKey-Guide/issues/19#issuecomment-458663857 [1] https://git.sr.ht/~jman/dotfiles/tree/master/item/gnupg/.gnupg [2] https://developers.yubico.com/yubico-pam/ From dkg at fifthhorseman.net Thu Jan 28 23:27:29 2021 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 28 Jan 2021 17:27:29 -0500 Subject: How to report issues and suggest changes to the Web Key Directory specification [was: Re: Please tackle the Right Thing] In-Reply-To: References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> <7441f18a-8e59-3ec0-5b22-b535667bf38e@colomb.de> <3d693337c4a59a4ac871e297433d3fc418d86a8e.camel@16bits.net> Message-ID: <87h7n0elym.fsf@fifthhorseman.net> On Wed 2021-01-27 22:49:13 +0100, Andr? Colomb wrote: > By the way, is there something like a repository to send and discuss > pull requests against the WKD draft document? Or is it just > hand-crafted text edited by the submitter based on suggestions? I think you can find a git repo that contains org-mode source here: git clone https://dev.gnupg.org/source/gnupg-doc.git it's in the misc/id/openpgp-webkey-service folder, and might require a modified version of pandoc2rfc (see the Makefile in that folder, i haven't tested). I've reported concerns about the draft on https://dev.gnupg.org using the "wkd" tag, though that tag is also used for bug reports, feature requests, etc for the wkd implementation in GnuPG itself: https://dev.gnupg.org/project/profile/108/ I don't know whether there is a preferred way to report concerns or suggest problems with the spec. Perhaps Werner can suggest what he prefers? I usually encourage any author of an Internet Draft to include a reference to their preferred issue tracker/source repo in the draft itself while it's in process -- the information can be stripped out once the draft stabilizes, or at the final stage of publication. 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 angel at pgp.16bits.net Fri Jan 29 01:20:55 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 29 Jan 2021 01:20:55 +0100 Subject: How to report issues and suggest changes to the Web Key Directory specification [was: Re: Please tackle the Right Thing] In-Reply-To: <87h7n0elym.fsf@fifthhorseman.net> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> <7441f18a-8e59-3ec0-5b22-b535667bf38e@colomb.de> <3d693337c4a59a4ac871e297433d3fc418d86a8e.camel@16bits.net> <87h7n0elym.fsf@fifthhorseman.net> Message-ID: <5fe79b4e49a976657be336f37da20d76c2aefc6e.camel@16bits.net> On 2021-01-28 at 17:27 -0500, Daniel Kahn Gillmor via Gnupg-users wrote: > I think you can find a git repo that contains org-mode source here: > > git clone https://dev.gnupg.org/source/gnupg-doc.git > > it's in the misc/id/openpgp-webkey-service folder, and might require a > modified version of pandoc2rfc (see the Makefile in that folder, i > haven't tested). Oh, nice. I had only located https://gitlab.com/openpgp-wg/webkey-directory which stops at -08. This one has been further updated. (cfdc5358402e3c49be5ffe509a61b995399bb528 on gitlab is 21258d2561d3e0b88cc58286049e5fc24c9dbb1e in gnupg-doc, it misses the last 4 commits) > I usually encourage any author of an Internet Draft to include a > reference to their preferred issue tracker/source repo in the draft > itself while it's in process -- the information can be stripped out > once the draft stabilizes, or at the final stage of publication. +1 > I've reported concerns about the draft on https://dev.gnupg.org using > the "wkd" tag, though that tag is also used for bug reports, feature > requests, etc for the wkd implementation in GnuPG itself: > > https://dev.gnupg.org/project/profile/108/ > > I don't know whether there is a preferred way to report concerns or > suggest problems with the spec. Perhaps Werner can suggest what he > prefers? +1 as well It would be very useful to know where are issues expected to be raised. During this thread there were a few points that would be very appropriate to have filled somewhere, at the very least so that they don't get forgotten. From angel at pgp.16bits.net Fri Jan 29 01:54:06 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 29 Jan 2021 01:54:06 +0100 Subject: How to report issues and suggest changes to the Web Key Directory specification [was: Re: Please tackle the Right Thing] In-Reply-To: <87h7n0elym.fsf@fifthhorseman.net> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> <7441f18a-8e59-3ec0-5b22-b535667bf38e@colomb.de> <3d693337c4a59a4ac871e297433d3fc418d86a8e.camel@16bits.net> <87h7n0elym.fsf@fifthhorseman.net> Message-ID: <43320eab66c300d0a175ee5b2f449f5c0eddd222.camel@16bits.net> On 2021-01-28 at 17:27 -0500, Daniel Kahn Gillmor via Gnupg-users wrote: > I think you can find a git repo that contains org-mode source here: > > git clone https://dev.gnupg.org/source/gnupg-doc.git > > it's in the misc/id/openpgp-webkey-service folder, and might require > a modified version of pandoc2rfc (see the Makefile in that folder, i > haven't tested). It _mostly_ builds fine. There are a few quirks, in addition to "normal" dependencies (emacs, sed pandoc, xml2rfc, xsltproc), you need to install pandoc2rfc[1] and change directly in its code "-t docbook" to "-t docbook4" On the resulting draft, I find it considers it as created o November 1 instead of November 17, and that all quote characters did not reach there. Best regards 1- https://github.com/miekg/pandoc2rfc From wk at gnupg.org Fri Jan 29 09:01:44 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Jan 2021 09:01:44 +0100 Subject: [Announce] [urgent] Stop using Libgcrypt 1.9.0 ! Message-ID: <87v9bgw4rb.fsf@wheatstone.g10code.de> Hi! A severe bug was reported yesterday evening against Libgcrypt 1.9.0 which we released last week. A new version to fix this as weel as a couple of build problems will be released today. In the meantime please stop using 1.9.0. It seems that Fedora 34 and Gentoo are already using 1.9.0 . 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: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Fri Jan 29 12:20:18 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Jan 2021 12:20:18 +0100 Subject: [Announce] [Security fix] Libgcrypt 1.9.1 relased Message-ID: <87h7n0vvkd.fsf@wheatstone.g10code.de> Hello! We have to announce the availability of Libgcrypt version 1.9.1. This version fixes a *critical security bug* in the recently released version 1.9.0. If you are already using 1.9.0 please update immediately to 1.9.1. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Impact and timeline =================== Only one released version is affected: - Libgcrypt 1.9.0 (released 2021-01-19) All other versions are not affected. On 2021-01-28 Tavis Ormandy contacted us to report a severe bug in 1.9.0 which he found while testing GnuPG: There is a heap buffer overflow in libgcrypt due to an incorrect assumption in the block buffer management code. Just decrypting some data can overflow a heap buffer with attacker controlled data, no verification or signature is validated before the vulnerability occurs. The bug was introduced during the the 1.9 development phase about two years ago with commit e76617cbab018dd8f41fd6b4ec6740b5303f7e13 (Reduce overhead on generic hash write function). Exploiting this bug is simple and thus immediate action for 1.9.0 users is required. A CVE-id has not yet been assigned. We track this bug at https://dev.gnupg.org/T5275. The 1.9.0 tarballs on our FTP server have been renamed so that scripts won't be able to get this version anymore. Solution ======== If Libgcrypt versions 1.9.0 is in use please update immediately to version 1.9.1. If you are using the 1.8 LTS branch you are not affected. While you are checking anyway please make sure that you have at least 1.8.5. If you are using a development version build taken from our Git repository you need to update as well. NB: The use of non-released versions in a production environment is strongly discouraged. There is yet no released GnuPG version hich requires Libgcrypt 1.9 Noteworthy changes in Libgcrypt 1.9.1 ===================================== * Bug fixes: - *Fix exploitable bug* in hash functions introduced with 1.9.0. [#5275] - Return an error if a negative MPI is used with sexp scan functions. [#4964] - Check for operational FIPS in the random and KDF functions. [#5243] - Fix compile error on ARMv7 with NEON disabled. [#5251] - Fix self-test in KDF module. [#5254] - Improve assembler checks for better LTO support. [#5255] - Fix assember problem on macOS running on M1. [#5157] - Support older macOS without posix_spawn. [#5159] - Fix 32-bit cross build on x86. [#5257] - Fix non-NEON ARM assembly implementation for SHA512. [#5263] - Fix build problems with the cipher_bulk_ops_t typedef. [#5264] - Fix Ed25519 private key handling for preceding ZEROs. [#5267] - Fix overflow in modular inverse implementation. [#5269] - Fix register access for AVX/AVX2 implementations of Blake2. [#5271]. * Performance: - Add optimized cipher and hash functions for s390x/zSeries. - Use hardware bit counting functionx when available. * Internal changes: - The macOS getentropy syscall is used when available. [#5268] - Update DSA functions to match FIPS 186-3. [30ed9593f6] - New self-tests for CMACs and KDFs. [385a89e35b,7a0da24925] - Add bulk cipher functions for OFB and GCM modes. [f12b6788f2,f4e63e92dc] For a list of links to commits and bug numbers see the release info at https://dev.gnupg.org/T5259 Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at https://gnupg.org/download/mirrors.html. On the primary server the source tarball and its digital signature are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.1.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.1.tar.bz2.sig or gzip compressed: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.1.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.1.tar.gz.sig In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at https://gnupg.org/download/integrity_check.html. In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.9.1.tar.bz2 you would use this command: gpg --verify libgcrypt-1.9.1.tar.bz2.sig libgcrypt-1.9.1.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 libgcrypt-1.9.1.tar.bz2, you run the command like this: sha1sum libgcrypt-1.9.1.tar.bz2 and check that the output matches the first line from the this list: a15ce7355b028f28a33428eaa0147154861b29d4 libgcrypt-1.9.1.tar.bz2 f4440ce7893c3cf12f633ad4d3f91c77110a3a40 libgcrypt-1.9.1.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and if needed ask on the gcrypt-devel mailing list. In case of problems specific to this release please first check https://dev.gnupg.org/T5259 for updated information. Please also consult the archive of the gcrypt-devel mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html . We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and still mostly financed by donations. Three full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME, and Gpg4win. We like to thank all the nice people who are helping Libgcrypt, be it testing, coding, suggesting, auditing, administering the servers, spreading the word, or 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 and Libgcrypt in a good and secure shape and to address all the small and larger requests made by our users. Thanks. Thanks to Tavis Ormandy for finding an reporting the bug. We are sorry for the trouble, Your Libgcrypt hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-devel'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: ed25519 2020-08-24 [expires: 2030-06-30] Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) 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) rsa2048 2011-01-12 [expires: 2021-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- "If privacy is outlawed, only outlaws will have privacy." - PRZ 1991 -------------- 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 dkg at fifthhorseman.net Fri Jan 29 03:35:15 2021 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 28 Jan 2021 21:35:15 -0500 Subject: How to report issues and suggest changes to the Web Key Directory specification [was: Re: Please tackle the Right Thing] In-Reply-To: <5fe79b4e49a976657be336f37da20d76c2aefc6e.camel@16bits.net> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> <7441f18a-8e59-3ec0-5b22-b535667bf38e@colomb.de> <3d693337c4a59a4ac871e297433d3fc418d86a8e.camel@16bits.net> <87h7n0elym.fsf@fifthhorseman.net> <5fe79b4e49a976657be336f37da20d76c2aefc6e.camel@16bits.net> Message-ID: <87bld8eaho.fsf@fifthhorseman.net> On Fri 2021-01-29 01:20:55 +0100, ?ngel wrote: > Oh, nice. I had only located > https://gitlab.com/openpgp-wg/webkey-directory which stops at -08. This > one has been further updated. yep, see the thread starting at https://lists.gnupg.org/pipermail/gnupg-users/2019-October/062844.html and concluding at https://lists.gnupg.org/pipermail/gnupg-users/2019-November/063056.html for background on the two different repos. > It would be very useful to know where are issues expected to be raised. > During this thread there were a few points that would be very > appropriate to have filled somewhere, at the very least so that they > don't get forgotten. I agree that having a consistent and dedicated place for issues to be filed (if they're not addressed immediately) is useful. https://gitlab.com/openpgp-wg/webkey-directory/-/issues was intended to be that place after discussion with Werner, but it doesn't appear to have seen much use since it was created. Maybe Werner can clarify what place he'd prefer and we can consolidate the issue tracking there. --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 Fri Jan 29 16:09:35 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Jan 2021 16:09:35 +0100 Subject: How to report issues and suggest changes to the Web Key Directory specification [was: Re: Please tackle the Right Thing] In-Reply-To: <87bld8eaho.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via Gnupg-users's message of "Thu, 28 Jan 2021 21:35:15 -0500") References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <20210116004449.ygwy62axauaynze6@raf.org> <20210116230620.vothqvj5frusxbpd@raf.org> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> <7441f18a-8e59-3ec0-5b22-b535667bf38e@colomb.de> <3d693337c4a59a4ac871e297433d3fc418d86a8e.camel@16bits.net> <87h7n0elym.fsf@fifthhorseman.net> <5fe79b4e49a976657be336f37da20d76c2aefc6e.camel@16bits.net> <87bld8eaho.fsf@fifthhorseman.net> Message-ID: <87k0rvvky8.fsf@wheatstone.g10code.de> On Thu, 28 Jan 2021 21:35, Daniel Kahn Gillmor said: > Maybe Werner can clarify what place he'd prefer and we can consolidate > the issue tracking there. Please send patches to gnupg-devel or if you need a bug tracker, use dev.gnupg.org with the wkd tag/project. 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 Jan 29 16:05:59 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Jan 2021 16:05:59 +0100 Subject: gpg cards In-Reply-To: <1387053890.17222.1611827594344@ox73.mailbox.org> (Philipp Schmidt's message of "Thu, 28 Jan 2021 10:53:13 +0100 (CET)") References: <1387053890.17222.1611827594344@ox73.mailbox.org> Message-ID: <87o8h7vl48.fsf@wheatstone.g10code.de> > ahead and copied the very same keys from the backup to the second. But > trying to actually use does not work, I get an error like: 'please > insert card: [?]' So. > > What can I do to make gpg use the card as well (if possible) ? You see the prompt because gpg knows that you aready used the first card and asks for that card. The alternative would be to check whether the currently inserted card can be used, despite that its serial number does not match. IIRC, we have implemented this in 2.3 to be released in th next few weeks. What you can do with 2.2 is to delet the stub file which stores the serial number: gpg --with-keygrip -K shows you the keygrip of the respective file. Now check whether the file ~/.gnupg/private-keys-v1.d/.key has the string "shadowed-private-key". If so, delete this file and run "gpg --card-status". Such a file might look like this: --8<---------------cut here---------------start------------->8--- Token: 276000124010200FFFE372F7910000 OPENPGP.1 Label: My signing yellow signing yoken Key: (shadowed-private-key (ecc (curve Ed25519)(flags eddsa)(q #40CFBE4795E91CD7A26185F23430A7445712DD93185C3023B4646E963010263697#) (shadowed t1-v1 (#D276000124010200FFFE372F7910000# OPENPGP.1)))) --8<---------------cut here---------------end--------------->8--- which can be edited, or it might be some binary gibberish. In any case you should be able to check for the "shadowed-private-key" string. Note that such a file exists for each key. > Another thing I would really love to know is: Is it possible to use > the gpg card as smartcard for the system login as well? Right now I am You can use the poldi PAM module but it is somewhat limited. For proper support we would need to modify the screen locker and the display manager. > Last but not least I am still on a quest for a setup to use Full Disk > Encryption and Security Token to actually decrypt the Disk on boot. I use my card for many years for an encrypted partition. The tool is called g13 but it is not very polished and not easy to install. When building gnupg add --enable-g13 to configure. We have an open task to write a bit of docuemntation: https://dev.gnupg.org/T3423 . What's also missing are features to replace or add OpenPGP keys to a partition so that you can use several cards or an symmetric key for decryption (of the actual dmcrypt key). 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 bernhard at intevation.de Fri Jan 29 16:48:49 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 29 Jan 2021 16:48:49 +0100 Subject: WKD specifiction: Where to channel reports and suggestions? Message-ID: <202101291649.16323.bernhard@intevation.de> Am Freitag 29 Januar 2021 01:20:55 schrieb ?ngel: > > I've reported concerns about the draft on https://dev.gnupg.org using > > the "wkd" tag, though that tag is also used for bug reports, feature > > requests, etc for the wkd implementation in GnuPG itself: > > > > https://dev.gnupg.org/project/profile/108/ As long as there is no other tag or subtag, `wkd` seems okay to me. The wiki or this mailinglist both seem to be okay, too. > > I don't know whether there is a preferred way to report concerns or > > suggest problems with the spec. Perhaps Werner can suggest what he > > prefers? > During this thread there were a few points that would be very > appropriate to have filled somewhere, at the very least so that they > don't get forgotten. Starting some fresh posts with summaries (or summaries on dev.gnupg.org) is helpful to me. I admit that I've lost the overview in the monster thread. It is hard to spot the arguments in the noise, this is why I suggest to split and summarize. 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: 659 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Fri Jan 29 17:52:25 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 29 Jan 2021 17:52:25 +0100 Subject: Protect email experience not Subject:s (hypothesis, draft) Message-ID: <202101291752.32473.bernhard@intevation.de> Hello, for many months now, my feeling is growing that encrypted subject headers in emails shift the security balance in the wrong direction. So I want to summarize and explore this hypothesis. Here are some draft thoughts and notes. Feedback welcome (either to me directly or on the list). Not sure yet, where to place all this, but in the best tradition I'll announce my intentions here and will follow up as I learn. Best Regards, Bernhard == Idea of protected headers. The subject of an email delives contents related to the body of the mail. To raise the confidentiality (as one aspect of security), it is proposed to do end-to-end encryption on the subject Header-Field. == Hypothesis The subject Header-Field is also meta data, needed to keep email usable. Or in other words: to support the availability aspect of security. Because email is the most popular decentral communication solution [5] compatibility with existing installations and existing ways of working for diverse user groups is more important than in other softwar contexts. From an implementers point of view, protected headers seem to make it more complicated and break some ways to implement good access to emails. Examples: * IMAP servers can search emails by subject. A feature that cannot be kept functional with inaccessible contents. * Fast access to filtering in clients by subject is broken, because it would mean indexes and indexes would need to come from a crypto secure store, one each per crypto context (private key). * There are many old or non-header-decrypting clients around, otherwise fine and stable. As observable metadata cannot be avoided totally, maybe the alternative to automating the Header-Fields is to help people manage the different levels of security they need per occasion. Thought experiment: If it is understood that the header section is like notes on a paper envelope, needed for mail transport and to be able to be seen by the transporting agents, this can be used to assess what can be learned from it. And then common ways of distracting from the contents can be used. (I write 'common ways', because this is a core of my concept about how to get end-to-end encryption - especially email - more usable: People already know social ways how to deal with different levels of confidentiality. Sofware application need not to hide it the aspects too much.) As a consequence encrypting the subject of an email can be seen as contributing only very little to the confidentiality. The whole exchange has to done so that it looks unsuspicous anyway. Potential conclusion: Encrypted subject headers contribute a little bit to confidentiality, but they also lower availability for many cases (by the implementation complications). They should not be send by default. == Valid use cases? Where the "Subject:" is a lot more than a writing on the envelope. * Example: a roundup-tracker fully run with OpenPGP/MIME mails, by default it changes the title of an issue and there can be commands to control the issue in the subject. (Also an example where backwards compatiblity failed.) Implementation idea: per recipient (group) settings to explicitely enable encrypted subjects for those groups and contexts where it is known to be more useful. == Material [1] https://github.com/autocrypt/memoryhole archived in favour of [2] lists some alternatives and links elder discussions [2] https://github.com/autocrypt/protected-headers Old source code repo of [3]? [3] https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/ "Header Protection for S/MIME draft-ietf-lamps-header-protection-02 (Last updated 2020-11-02)" also aiming at OpenPGP/MIME? [4] A widely spread version of Thunderbird v78 did not allow disabling the encryption of subjects. https://support.mozilla.org/en-US/kb/openpgp-thunderbird-howto-and-faq#w_can-i-disable-the-encryption-of-the-email-subject [5] Mahn, Jan, 2021, c't 2021/03 pp50-53 "Nichts zu ?verbergen? Sicher und vertraulich kommunizieren: Ein Grundrecht" https://www.heise.de/select/ct/2021/3/2030913061555053970 -- 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: 659 bytes Desc: This is a digitally signed message part. URL: From daniele at grinta.net Fri Jan 29 18:41:24 2021 From: daniele at grinta.net (Daniele Nicolodi) Date: Fri, 29 Jan 2021 18:41:24 +0100 Subject: How to report issues and suggest changes to the Web Key Directory specification [was: Re: Please tackle the Right Thing] In-Reply-To: <87k0rvvky8.fsf@wheatstone.g10code.de> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> <7441f18a-8e59-3ec0-5b22-b535667bf38e@colomb.de> <3d693337c4a59a4ac871e297433d3fc418d86a8e.camel@16bits.net> <87h7n0elym.fsf@fifthhorseman.net> <5fe79b4e49a976657be336f37da20d76c2aefc6e.camel@16bits.net> <87bld8eaho.fsf@fifthhorseman.net> <87k0rvvky8.fsf@wheatstone.g10code.de> Message-ID: <8a8cc15b-566c-7da8-f4c4-5bbfb3ea7d8d@grinta.net> Hello, this is only to report that Thunderbird 78.7.0 is unable to make sense of the MIME structure of Werner's email and it only visualizes the mailing list footer as the body of the email. I don't know if the issue is with Thunderbird or with Werner's MUA, although I suspect the first. Cheers, Dan On 29/01/2021 16:09, Werner Koch via Gnupg-users wrote: > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From jscott at posteo.net Sat Jan 30 00:22:11 2021 From: jscott at posteo.net (John Scott) Date: Fri, 29 Jan 2021 18:22:11 -0500 Subject: Help with GPGME keylisting not listing signatures In-Reply-To: <3153371.sksYtiFmj9@breq> References: <806052122.0ifERbkFSE@t450> <3153371.sksYtiFmj9@breq> Message-ID: <2982267.ouH8jyFxom@t450> On Saturday, January 23, 2021 10:39:30 AM EST Ingo Kl?cker wrote: > Did you have a look at GPGME's tests as working example code? There is a > test for listing signatures: > https://dev.gnupg.org/source/gpgme/browse/master/tests/gpg/t-keylist-sig.c Thanks, I didn't see that. Except for the difference that I read the keys from a gpgme_data_t connected to a stream instead of GnuPG's keyring, my code seems to match up with the test's way of doing things. With the debugging information on the invocation of gpg doesn't look abnormal, and trying in a fresh chroot gets me the same results, so it seems as though getting detailed signature data from a gpgme_data_t may not be possible. My example for testing is at https://salsa.debian.org/-/snippets/519 -------------- 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 angel at pgp.16bits.net Sat Jan 30 02:02:11 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sat, 30 Jan 2021 02:02:11 +0100 Subject: Thunderbird reading Werner mail structure about How to report issues and suggest changes to the Web Key Directory specification In-Reply-To: <8a8cc15b-566c-7da8-f4c4-5bbfb3ea7d8d@grinta.net> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <2dc4e82f3ceaa74cff091b18b48eff71b7b9fbdc.camel@16bits.net> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> <7441f18a-8e59-3ec0-5b22-b535667bf38e@colomb.de> <3d693337c4a59a4ac871e297433d3fc418d86a8e.camel@16bits.net> <87h7n0elym.fsf@fifthhorseman.net> <5fe79b4e49a976657be336f37da20d76c2aefc6e.camel@16bits.net> <87bld8eaho.fsf@fifthhorseman.net> <87k0rvvky8.fsf@wheatstone.g10code.de> <8a8cc15b-566c-7da8-f4c4-5bbfb3ea7d8d@grinta.net> Message-ID: <3fc6a464ca414e1fb6c6379836626ef55ddedfea.camel@16bits.net> On 2021-01-29 at 18:41 +0100, Daniele Nicolodi wrote: > Hello, > > this is only to report that Thunderbird 78.7.0 is unable to make > sense > of the MIME structure of Werner's email and it only visualizes the > mailing list footer as the body of the email. > > I don't know if the issue is with Thunderbird or with Werner's MUA, > although I suspect the first. > > Cheers, > Dan Hello Daniele It's probably an issue of Thunderbird, or maybe of your MTA. I have no issue with a different client. The original structure of Werner mail was: multipart/signed text/plain application/pgp-signature After going through the mailing list, it added the mailing list footer as another part, so it became multipart/mixed multipart/signed text/plain application/pgp-signature text/plain Maybe you can check if you can view an email with this structure in thunderbird source. If so, it's probably failing the "decryption" (signature checking, actually), and just returning an empty block there. Best regards From azbigdogs at gmx.com Sat Jan 30 22:43:33 2021 From: azbigdogs at gmx.com (Mark) Date: Sat, 30 Jan 2021 14:43:33 -0700 Subject: Thunderbird reading Werner mail structure about How to report issues and suggest changes to the Web Key Directory specification In-Reply-To: <3fc6a464ca414e1fb6c6379836626ef55ddedfea.camel@16bits.net> References: <7e8e71c6-5077-5fb0-d327-42e9c9e56f46@colomb.de> <0cc645f83db8d8997976e24c0125e1010e041215.camel@16bits.net> <87y2gq8zir.wl-neal@walfield.org> <877do9dymv.fsf_-_@wheatstone.g10code.de> <87zh13ai0h.fsf@wheatstone.g10code.de> <7441f18a-8e59-3ec0-5b22-b535667bf38e@colomb.de> <3d693337c4a59a4ac871e297433d3fc418d86a8e.camel@16bits.net> <87h7n0elym.fsf@fifthhorseman.net> <5fe79b4e49a976657be336f37da20d76c2aefc6e.camel@16bits.net> <87bld8eaho.fsf@fifthhorseman.net> <87k0rvvky8.fsf@wheatstone.g10code.de> <8a8cc15b-566c-7da8-f4c4-5bbfb3ea7d8d@grinta.net> <3fc6a464ca414e1fb6c6379836626ef55ddedfea.camel@16bits.net> Message-ID: <214fb269-e285-87e2-ce16-5fec47161279@gmx.com> I'm using TB 78.7 as well and I can read Werner's posts just fine. The other issue is with the key. TB reports back that it has an uncertain signature (mismatch). On 1/29/2021 6:02 PM, ?ngel wrote: > On 2021-01-29 at 18:41 +0100, Daniele Nicolodi wrote: >> Hello, >> >> this is only to report that Thunderbird 78.7.0 is unable to make >> sense >> of the MIME structure of Werner's email and it only visualizes the >> mailing list footer as the body of the email. >> >> I don't know if the issue is with Thunderbird or with Werner's MUA, >> although I suspect the first. >> >> Cheers, >> Dan > Hello Daniele > > It's probably an issue of Thunderbird, or maybe of your MTA. I have no > issue with a different client. > > The original structure of Werner mail was: > > multipart/signed > text/plain > application/pgp-signature > > > After going through the mailing list, it added the mailing list footer > as another part, so it became > > multipart/mixed > multipart/signed > text/plain > application/pgp-signature > text/plain > > > Maybe you can check if you can view an email with this structure in > thunderbird source. If so, it's probably failing the "decryption" > (signature checking, actually), and just returning an empty block > there. > > Best regards > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- PGP Key Upon Request