Re: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages]
Daniel Kahn Gillmor via Gnupg-users wrote: > On Mon 2021-01-11 22:59:10 +0100, Ángel wrote: > > The "make a CNAME of your openpgpkeys subdomain to > > wkd.keys.openpgp.org" couldn't work with https certificate validation, > > thouth (or are they requesting a certificate on-the-fly?) > > In fact, i believe that keys.openpgp.org *is* requesting and retaining a > certificate on-the-fly if it finds itself addressed by such a CNAME. Yep. If that wasn't possible, we wouldn't do it. btw, if anyone is interested: keys.o.o serves wkd for 224 domains right now. - V ___ 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 2021-01-15 at 20:34 +0100, Stefan Claas via Gnupg-users wrote: > If you or someone else set's up a web server, for a big organisation > or for yourself, you simple put in the .well-known folder some > content which would look most likely then like this: > > http://domain.tld/.well-known/etc... or maybe > https://sub.domain.tld/.well-known/etc... Right. For instance, you would use either https://300baud.de/.well-known/... https://openpgpkey.300baud.de/.well-known/... > If someone writes now a program which needs to access content in the > well-known folder, why does a software author needs to implement two > methods to access the well-known folder? This part for example I do > not understand, because if one method is not good or secure enough I > would simply drop one method an implement only the more secure and > more reliable one, or not? Because the specification says that it can be in those two places. It could have stated only one, or a dozen. Or even, "start following links from the main index and stop after you find the first pgp key". > The situation we now have is that we have two popular OpenPGP apps > which handle the access to the well-known openpgp directory > differently, which nobody can deny. They differ *slightly*. Only if the first location exists but fails. But yes, they differ, as agreed by everyone. > I for example can say I don't care about a draft and happily promote > sequoia-pgp usage over GnuPG usage, in case OpenPGP users would like > to use GitHub and WKD for a multi-purpose OpenPGP too. That would > Werner and a couple of other probably pi*#-off very much but I do not > have done something wrong and people are allowed to do the same. Of course, you could. Or you could simply say: the pgp key of @.com shall be at https://www..com/.pub That would be following a completely different "standard", but it would be perfectly fine, too. The beauty of standards is to get everyone following the same rules and not a https://xkcd.com/927/ situation though. A standard allows people to know where to place their keys in a place it will be looked for, and the clients to know where they should look for them and how to act. > My intention was only to promote WKD OpenPGP usage for github.io > pages in case people like the idea. This was a good idea, but github pages don't seem to support being used for WKD (due to the mentioned wildcard issues). Best regards ___ 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 07:56:26AM +0100, André Colomb wrote: > Am 15. Januar 2021 01:56:04 MEZ schrieb raf via Gnupg-users > : > >But of course, you're not asking for that. You're just > >asking for something to work. There must be other ways. > >Accepting invalid certificates might just have been my > >first thought at how to deal with this. But that would > >enable the advanced method to work (in situations where > >it shouldn't). If I remember correctly (possibly not), > >you wanted the direct method to work, and github.io's > >mis-configuration of certificates caused the advanced > >method to be attempted and fail, before the direct > >method could even be attempted. > > I'll try to complete your summary. The DNS wildcard entry for > *.example.github.io leads to the advanced method being tried. We can't > change that entry, and therefore with the current protocol draft, it > makes no sense forcefully wanting to use the direct method. > > It's easy to set up the advanced method there. But GitHub uses an > invalid TLS certificate for openpgpkey.example.github.io. That's what > needs fixing and it is also out of our control. > > So basically Stefan's request is to change the protocol to work around > a misconfiguration because both DNS and the TLS certificate are > controlled by a company that offers the service totally unrelated to > WKD. Such a workaround could hurt the ecosystem because it may hide a > misconfiguration in setups where the operator does have control over > these things and just needs to notice. That's why I thought maybe a skip list might be useful, rather than automatically failing over to the direct method in all cases where the advanced method is mis-configured in some way. The user-controlled skip list could be used in cases where the user knows that the server administrators aren't going to fix their system. I can totally understand a reluctance to add workarounds to other people's bugs into your own software. I've done that and wasn't happy about it. But I imagine that a skip list to avoid the advanced method for certain known-to-be-permanently-misconfigured domains is probably a minor instrusion into the code. But I'm just guessing. And for it to be of any use, github.io would have to be in the list by default, so that all users "benefit" from it without knowing in advance that they need it. Of course, if github.io ever do fix their TLS system, they would need to be removed from the skip list, which presumably wouldn't happen until they next upgrade gnupg. That would be a problem. Trying to be pragmatic in the face of other people's bugs can get tacky. Hmm, does github itself have a bug-tracking system? :-) > >OK. I just had a look at https://wiki.gnupg.org/WKD and > >it doesn't refer to "advanced" or "direct" methods. It > >seems to consider the "direct" method as the main > >method, and the "advanced" method as a "Stopgap method" > >which is "Not recommended - but a temporary > >workaround". So having an additional mechanism to > >disable the "advanced" method sounds reasonable. Or > >maybe the wiki page needs to be updated(?). > > Sorry, you just misread that part. The stopgap solution is to use a > server operated by openpgp.org instead of your own web server. For > that to work, you must set up the advanced method for WKD on your > domain's DNS. That method is perfectly fine and in some scenarios even > easier to use. Thanks for that. That makes more sense. I thought the advanced method sounded quite sensible. :-) > Kind regards > André > > Hi raf, > > thanks for your perspective on the matter. > > -- > Greetings... > From: André Colomb cheers, raf ___ 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 07:56:16AM +0100, Stefan Claas wrote: > On Fri, Jan 15, 2021 at 2:04 AM raf via Gnupg-users > wrote: > > [...] > > > I'm really not an expert, and the above might not make > > any sense. I'm just thinking aloud. > > Me neither ... :-) For me, the questions I had is still unresolved > when it comes to properly explaing what security implication > it gives, when for example sequoia-pgp can handle this and > why the draft explicity says it MUST use the advanced-method > first. > > Don't you think when GitHub, a major player, would have an invalid > SSL cert, that maybe one of the millions programmers there would not > have contacted GitHub, like I did, and say hey GithHub you serve > the global community and visitors an invalid SSL certificate? I would. But that doesn't seem to have happened. I can only assume that github.io users aren't making much using sub-sub-domains of their sub-domains, or if they are, then they are not using TLS with those sub-sub-domains, so the invalid certificate isn't causing them any issues. Github could probably create valid wildcard certificates for sub-sub-domains (now that letsencrypt supports wildcard certificates), but it seems that they only have one certificate that covers their domains and sub-domains, but they then hand them out for sub-sub-domains as well. That is very odd behaviour on their part. They must know that that is an invalid use of their certificate. They are very clever people. > I must admit that I also do not understand what you > mean with sus-sub domains. It's sub-sub-domain, not sus-sub-domain. Sorry if I mistyped it. The "sub-domain" is the sub-domain of github.io, e.g.: sac001.github.io The "sub-sub-domain" is the sub-domain of a sub-domain, e.g.: openpgpkey.sac001.github.io Github's web server is handing out the same certificate for both your sub-domain and your sub-sub-domain, even though it is not valid for your sub-sub-domain. It is only valid for the following hostnames which includes your sub-domain (but not your sub-sub-domain): www.github.com *.github.com github.com *.github.io github.io *.githubusercontent.com githubusercontent.com You can see this for yourself in Firefox, by going to https://sac001.github.io/, clicking on the padlock, then clicking on the right "arrow" to the right of "Connection secure", then clicking on "More information". Github's web server should really just hand out this certificate for hostnames that are covered by it, but instead, they hand it out for sub-sub-domains that are not covered by it. The best solution would be for github, when handing out sub-domains, to register a letsencrypt wildcard certificate for that sub-domain's sub-sub-domains. In your sub-domain's case, such a certificate would cover: *.sac001.github.io. But there is no certificate that covers that sub-sub-domain. That's why browsers complain if you go to https://openpgpkey.sac001.github.io/. I think that letsencrypt didn't originally support wildcard certificates. That might have something to do with what github are doing. But they do support them now, so this could be fixed by github. But there might have to be a reasonable number of users asking for it, for that to happen. It would take some effort on github's part to fix this, and there's probably no money in it for them. > My GitHub page is sac001.github.io and not foo.bar.github.io > or whatever. Yes, but openpgpkey.sac001.github.io is a sub-sub-domain and it is instrumental in the advanced method. When a WKD client attempts to fetch a key for ste...@sac001.github.io, they try to resolve that sub-sub-domain, and the DNS resolution succeeds, and the webserver hands out a certificate for that domain which happens to be invalid. > If Werner had told me/us, hey look, according to my draft > the advanced method MUST been used because of this and that > security implication and it is not allowed in this case to fall back > if an (for WKD) invalid cert is present, because of this/that security > issue, I guess then I had a better understanding and then I guess > also the sequoia team would never had done it so that it works > with sequoia-pgp. I think that's exactly what this part of the draft is saying: 3.1. Key Discovery ... There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. Only if the required sub-domain does not exist, they SHOULD fall back to the direct method. It just doesn't include the background rationale for the algorithm in amongst the algorithm. That's probably discussed elsewhere. But I haven't read the draft. I'm just copying and pasting from an earlier message in this thread. Perhaps the rationale is in the draft or other related documents. I agree that, whenever instructing someone to do something, it's a great idea to explain why they need to do it, if only because it has been
CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages]
On Mon 2021-01-11 22:59:10 +0100, Ángel wrote: > The "make a CNAME of your openpgpkeys subdomain to > wkd.keys.openpgp.org" couldn't work with https certificate validation, > thouth (or are they requesting a certificate on-the-fly?) In fact, i believe that keys.openpgp.org *is* requesting and retaining a certificate on-the-fly if it finds itself addressed by such a CNAME. --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
On 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 2021-01-15 at 07:56 +0100, Stefan Claas via Gnupg-users wrote: > Don't you think when GitHub, a major player, would have an invalid > SSL cert, that maybe one of the millions programmers there would not > have contacted GitHub, like I did, and say hey GithHub you serve > the global community and visitors an invalid SSL certificate? I must > admit that I also do not understand what you mean with sus-sub > domains. My GitHub page is sac001.github.io and not foo.bar.github.io > or whatever. By sub-sub-domains we are all talking about pages such as https://openpgpkey.sac001.github.io or https://helloworld.sac001.github.io Go there, click those links. You will see that -*after forcing your browser to ignore the invalid certificate*- there is a web page there returning a message of "Site not found", "404 There isn't a GitHub Pages site here". *I* don't know why they have such domains resolving. It may have been simpler to configure the dns server that way, or perhaps they just missed it. The funny think is, I don't think there's a way to create a page in helloworld.sac001.github.io or openpgpkey.sac001.github.io, so these sites are mostly useless (if not directly problematic such as in WKD case), and I guess that's why noone really bothered about the invalid certificate for them (which isn't easy to solve, either). I don't know what process you used to contact GitHub support, but the question to ask would be precisely this: > Why is there something on https://openpgpkey.sac001.github.io ? How > can I modify it? If there is not, could you make it not to resolve? The reasons why it is picked has been, I think, explained already many times in this thread. Best regards ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
re: How can I add encrypted comments
vedaal at nym.hush.com vedaal at nym.hush.comwrote on Thu Jan 14 19:37:37 CET 2021: >but functionally, yes, it can be done.- my mistake. Can't really be done this way :-((= >[1] Armor the signature file( gpg --armor filename.sig ) -should be enarmor instead of armor :-( this outputs to filename.sig.asc [2[ Armor your encrypted comments, and copy them to the end of thefilename.sig.asc, (leave one blank line between the pgp footer of the signature file,and the pgp header of the encrypted file) [3] Save the whole thing as filename.sig.asc [4] gpg filename.sig,asc will automatically verify the sig if theoriginal signed file 'filename' is present, and also decrypt the addedcomments-It doesn't.It gives weird error messages. sorry ;-( vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
