Re: How would you do that ...
On 08.05.2021 15:04, Stefan Vasilev via Gnupg-users wrote: Hi, thanks! I already found a solution by using an .onion based email provider, with clearnet usage support. Super simple registration, where the user only supplies a username and a password. Nothing more. :-) Regards Stefan Those already familar with IPFS can also create an encrypted 'diary', where the search term for the 'diary' is a memorizeable 256bit hex key, thus making it not possible to guess the diary name. Thus avoiding any log-in procedures at services and IPFS is used around the world and for example also popular in Russia and China. https://ipjot.herokuapp.com/ Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fundraising
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! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fundraising
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fundraising
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fundraising
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ctf-like WKD challenge (was: WKD proper behavior on fetch error)
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ctf-like WKD challenge (was: WKD proper behavior on fetch error)
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ctf-like WKD challenge (was: WKD proper behavior on fetch error)
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please tackle the Right Thing
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please tackle the Right Thing
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: make check failed tests
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please tackle the Right Thing
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Re: WKD proper behavior on fetch error
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, ste...@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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
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 - --locate-external-keys > er...@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 er...@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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD Checker
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Re: WKD proper behavior on fetch error
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, ste...@sac001.github.io > # Updated: current date of last update. > fingerprint #1 > fingerprint #2 > etc. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Re: WKD proper behavior on fetch error
On Tue, Jan 19, 2021 at 2:36 AM Ángel wrote: > > On 2021-01-17 at 23:43 +, 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, ste...@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] al...@example.com Well, only a proposal. Best regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please tackle the Right Thing (was: WKD Checker)
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Re: WKD proper behavior on fetch error
@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___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD Checker
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 ___ 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: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
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 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
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 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 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
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
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
Re: Why is there a conflict?
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@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 ___ 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: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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages]
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages]
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages]
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@email.address Hope this helps and please report back your results. Best regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why is there a conflict?
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why is there a conflict?
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' 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 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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How can I add encrypted comments.
On Thu, Jan 14, 2021 at 11:15 PM Ayoub Misherghi via Gnupg-users wrote: > > > On 1/14/2021 10:37 AM, ved...@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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How can I add encrypted comments.
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How can I add encrypted comments.
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How can I add encrypted comments.
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
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 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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 > "ste...@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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
On Tue, Jan 12, 2021 at 11:32 PM Remco Rijnders 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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 w...@gnupg.org Using --with-wkd-hash parameter, we can see that > > > this > > > would generate nq6t9teux7edsnwdksswydu4o9i5e...@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=draft-koch-openpgp-webkey-service-07=--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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Reiner-SCT CyberJack secoder 2 (v2.2.0 USB 0c4b:0400)
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 w...@gnupg.org Using --with-wkd-hash parameter, we can see that this > would generate nq6t9teux7edsnwdksswydu4o9i5e...@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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ste...@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 al...@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 b...@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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ste...@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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ste...@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: 'ste...@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_0x0254 <- # Home: C:/Users/Nutzer/AppData/Roaming/gnupg gpg: DBG: chan_0x0254 <- # Config: C:/Users/Nutzer/AppData/Roaming/gnupg/dirmngr.conf gpg: DBG: chan_0x0254 <- OK Dirmngr 2.2.25 at your service gpg: DBG: connection to the dirmngr established gpg: DBG: chan_0x0254 -> GETINFO version gpg: DBG: chan_0x0254 <- D 2.2.25 gpg: DBG: chan_0x0254 <- OK gpg: DBG: chan_0x0254 -> KEYSERVER --clear hkps://keyserver.ubuntu.com gpg: DBG: chan_0x0254 <- OK gpg: DBG: chan_0x0254 -> KEYSERVER gpg: DBG: chan_0x0254 <- S KEYSERVER hkps://keyserver.ubuntu.com gpg: DBG: chan_0x0254 <- OK gpg: DBG: chan_0x0254 -> KEYSERVER --clear hkps://keyserver.ubuntu.com gpg: DBG: chan_0x0254 <- OK gpg: DBG: chan_0x0254 -> KS_GET -- =ste...@sac001.github.io gpg: DBG: chan_0x0254 <- S PROGRESS tick ? 0 0 gpg: DBG: chan_0x0254 <- S SOURCE https://162.213.33.8:443 gpg: DBG: chan_0x0254 <- ERR 167772218 Keine Daten gpg: Fehler beim automatischen holen von `ste...@sac001.github.io' über `keyserver': Keine Daten gpg: DBG: chan_0x0254 -> KEYSERVER --clear hkps://keyserver.ubuntu.com gpg: DBG: chan_0x0254 <- OK gpg: DBG: chan_0x0254 -> DNS_CERT --dane ste...@sac001.github.io gpg: DBG: chan_0x0254 <- ERR 167772187 Nicht gefunden gpg: Fehler beim automatischen holen von `ste...@sac001.github.io' über `DANE': Nicht gefunden gpg: DBG: chan_0x0254 -> DNS_CERT * stefan.sac001.github.io gpg: DBG: chan_0x0254 <- ERR 167772187 Nicht gefunden gpg: Fehler beim automatischen holen von `ste...@sac001.github.io' über `DNS CERT': Nicht gefunden gpg: DBG: chan_0x0254 -> DNS_CERT --pka -- ste...@sac001.github.io gpg: DBG: chan_0x0254 <- ERR 167772187 Nicht gefunden gpg: Fehler beim automatischen holen von `ste...@sac001.github.io' über `PKA': Nicht gefunden gpg: DBG: chan_0x0254 -> WKD_GET -- ste...@sac001.github.io gpg: DBG: chan_0x0254 <- S SOURCE https://openpgpkey.sac001.github.io gpg: DBG: chan_0x0254 <- 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_0x0254 <- ERR 285212985 Falscher Name gpg: Fehler beim automatischen holen von `ste...@sac001.github.io' über `WKD': Falscher Name gpg: Fehler beim automatischen holen von `ste...@sac001.github.io' über `LDAP': Nich implementiert gpg: error reading key: Nich implementiert gpg: DBG: chan_0x0254 -> 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=0x calls=0 bytes=0 gpg: secmem usage: 0/32768 bytes in 0 blocks Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
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 'ste...@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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
WKD for GitHub pages
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 'ste...@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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Plan B - Who carries the torch?
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On future of GnuPG
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
