Re: WKD proper behavior on fetch error
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 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
WKD Checker
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why is there a conflict?
"a@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@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@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@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
On Sun, Jan 17, 2021 at 11:02 PM Remco Rijnders 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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 Xin |juergen@bruckner.email / \ Mail | smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Fundraising
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! signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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/ signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -- /¯\ No | \ / HTML |Juergen Bruckner Xin |juergen@bruckner.email / \ Mail | smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why is there a conflict?
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@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, Ayoub ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why is there a conflict?
a@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@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@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
-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-___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
-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-___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
-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-___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
