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: WKD proper behavior on fetch error
Am 15. Januar 2021 01:56:04 MEZ schrieb raf via Gnupg-users : >But of course, you're not asking for that. You're just >asking for something to work. There must be other ways. >Accepting invalid certificates might just have been my >first thought at how to deal with this. But that would >enable the advanced method to work (in situations where >it shouldn't). If I remember correctly (possibly not), >you wanted the direct method to work, and github.io's >mis-configuration of certificates caused the advanced >method to be attempted and fail, before the direct >method could even be attempted. I'll try to complete your summary. The DNS wildcard entry for *.example.github.io leads to the advanced method being tried. We can't change that entry, and therefore with the current protocol draft, it makes no sense forcefully wanting to use the direct method. It's easy to set up the advanced method there. But GitHub uses an invalid TLS certificate for openpgpkey.example.github.io. That's what needs fixing and it is also out of our control. So basically Stefan's request is to change the protocol to work around a misconfiguration because both DNS and the TLS certificate are controlled by a company that offers the service totally unrelated to WKD. Such a workaround could hurt the ecosystem because it may hide a misconfiguration in setups where the operator does have control over these things and just needs to notice. >OK. I just had a look at https://wiki.gnupg.org/WKD and >it doesn't refer to "advanced" or "direct" methods. It >seems to consider the "direct" method as the main >method, and the "advanced" method as a "Stopgap method" >which is "Not recommended - but a temporary >workaround". So having an additional mechanism to >disable the "advanced" method sounds reasonable. Or >maybe the wiki page needs to be updated(?). Sorry, you just misread that part. The stopgap solution is to use a server operated by openpgp.org instead of your own web server. For that to work, you must set up the advanced method for WKD on your domain's DNS. That method is perfectly fine and in some scenarios even easier to use. Kind regards André Hi raf, thanks for your perspective on the matter. -- Greetings... From: André Colomb ___ 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 04:33:00PM +0100, Stefan Claas via Gnupg-users wrote: > [...] My initial post was a help request and I also explained > why it IMHO would be good to have such a solution, which > would not hurt the GnuPG ecosystem in any form and would be > IMHO an enrichment for GnuPG usage. > > Best regards > Stefan [Note: First 3 paragraphs are mostly me being stupid - please bear with me] It sounded to me like you would like gnupg to have a bug added to it, whereby it accepts invalid certificates for sub-sub-domains, when the certificate is only valid for sub-domains. To me, that doesn't sound like it "would not hurt the GnuPG ecosystem in any form". To me, that sounds like a security bug, in the sense that it could lead users to think that a certificate is valid, when it isn't. If the ability to not validate certificates exists or gets added to gnupg, it wouldn't be turned on by default, so I'm not sure that it would even help your use case. The only people who could fetch your keys would be the ones who had disabled certificate validation. But of course, you're not asking for that. You're just asking for something to work. There must be other ways. Accepting invalid certificates might just have been my first thought at how to deal with this. But that would enable the advanced method to work (in situations where it shouldn't). If I remember correctly (possibly not), you wanted the direct method to work, and github.io's mis-configuration of certificates caused the advanced method to be attempted and fail, before the direct method could even be attempted. It's been suggested that, when the certificate for openpgpkey.*.github.io is found to be invalid, WKD clients could failover to the direct method (like sequoia does). Then at least the direct method would work with github.io sub-domains. That sounded good (to a non-expert like me). But perhaps it's a bit inefficient. But at least it's automatic. Another possible solution might be for WKD clients to have a list of domains to skip when doing the advanced method. If it had "openpgpkey.*.github.io" by default, then it would know not to try to resolve openpgpkey.*.github.io at all. Any domain that hands out invalid certificates for sub-sub-domains could be in the skip list. The currently documented solution to this expects the administrators of such (mis-configured) domains to add DNS records to prevent this, but when you can't rely on that happening, allowing the client/user to exclude them could be another option. And it wouldn't require accepting invalid certificates. And it would eliminate the attempt to use those domains so it would be more efficient. But it does require additional configuration that the above method doesn't require. A built-in default skip list would help with that. You still couldn't use the advanced method with github.io (until they start issuing a wildcard certificate for each sub-domain), but that's probably OK. I just had a look at https://wiki.gnupg.org/WKD and it doesn't refer to "advanced" or "direct" methods. It seems to consider the "direct" method as the main method, and the "advanced" method as a "Stopgap method" which is "Not recommended - but a temporary workaround". So having an additional mechanism to disable the "advanced" method sounds reasonable. Or maybe the wiki page needs to be updated(?). I'm really not an expert, and the above might not make any sense. I'm just thinking aloud. cheers, raf ___ 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 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 ___ 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
Re: How can I add encrypted comments.
On 1/14/2021 11:52 AM, Stefan Claas wrote: > 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. > Hello World! :-) Regards Stefan > > -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 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. Best regards, Ayoub ___ 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 1/14/2021 at 4:47 AM, "Ayoub Misherghi via Gnupg-users" wrote:
body p { margin-bottom:0; margin-top:0; }
I am encrypting and signing documents with myself as the
receiver. Nobody else will want to look inside them. Is it
possible to add encrypted comments or other information to a
separated signature file; and later retrieve this additional
information? I want to be able to decrypt the signature file alone
and retrieve all the information I put inside it.
=
Not exactly,
but functionally, yes, it can be done.
[1] Armor the signature file( gpg --armor filename.sig )
this outputs to filename.sig.asc
[2[ Armor your encrypted comments, and copy them to the end of the
filename.sig.asc,
(leave one blank line between the pgp footer of the signature file,
and the pgp header of the encrypted file)
[3] Save the whole thing as filename.sig.asc
[4] gpg filename.sig,asc will automatically verify the sig if the
original signed file 'filename' is present, and also decrypt the added
comments
vedaal___
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, 14 Jan 2021 01:47, Ángel said: > I understand this to mean it as "only use the direct method if the > required sub-domain does not exist", with the SHOULD meaning that the > direct method is not required (not sure why, I would have probably used Right. The subdomain is actually a workaround for SRV RR. We can't use the latter in browser based implementation and thus need to resort to this hack. SHOULD was used to allow the direct method in existing use cases. In case this has not yet been mention: If wildcards are used in the DNS a dummy TXT RR should be used to except the openpgpkey subdomain from wildcarding. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
How can I add encrypted comments.
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. Thanks, Ayoub ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
On 14/01/2021 00.06, Stefan Claas wrote: > Maybe, I don't know, readers here on the ML are asking themselves now why do > we > have two methods, e.g. what is their purpose and what informations can > one gain from > an IMHO very nice WKD checker, Wiktor has created. Quoting from your own mail: "As you said this is a draft It should formulated this way IMHO that it allows the greatest flexibility in a protokoll, to fulfill all use cases, when it comes to WKD." https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064645.html Nobody wants to remove any method, as that would reduce flexibility. The "advanced method" is not more complicated to set up, it's just a matter of preference really. > I think I have explained, at least for an expert like you, my set-up > for 300baud.de, I would use. I repeat, it's not clear to me yet. But let's stop here and discuss that when you have the basics up and running. > As soon as time permits I will do this, even if this cost me > money I can spend for other things. But I gives me then a better > overview and I can correct myself while thinking my > set-up would be equally to GitHub's set-up. In case I get stucked I > would like to ask you > for advise. Please note: I will not use the advanced method, I like to > see if this will work > with sequoia-pgp and GnuPG. You don't need to spend money just to prove anything to the ML subscribers. But when you do try, I offer to help with any problems coming up. You should not rule out the advanced method yet. Depending on your setup, it might actually be the easier route if wildcard domains are involved. Kind regards André -- Greetings... From: André Colomb signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
Hi Stefan, On 14/01/2021 08.01, Stefan Claas via Gnupg-users wrote: > The greatest benefit would have been if the author of WKD, namly Werner Koch, > had been so kind to explain to us why WKD needs two methods and what > security implications it has when an application falls back to a valid > direct-method, > instead of people defending him or his implementation. :-) I think Werner would have participated in the discussion already if other people's explanations had been incorrect. It's an open standard, and your focus on one person who happens to be the registered author doesn't help. If you insist on Werner's personal opinion, then you should maybe contact him directly instead of the GnuPG-Users list. Knowing well that he has no obligation to reply to anyone. Hopefully my (and others') attempts to explain / defend the WKD specification were still useful to you. Kind regards André -- Greetings... From: André Colomb signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
Hi Ángel, thanks for your contribution with a clear focus. On 14/01/2021 01.47, Ángel wrote: > Probably the most important part of the rule: "all implementations of > WKD should behave in the same way". I don't mind if it was gnupg that > was changed to behave like sequoia, but given identical conditions, > ideally all clients (and the draft reading) should produce the same > result (find key X, an error, etc.). I agree with that. And the next draft version SHOULD be very clear about this to avoid future discussions :-) > I would recommend to remove the or_else case and fail with an error if > the advanced method is (supposedly) set up but fails. At least, I think > there should be a diagnostic e.g. "WKD advanced method configured but > broken. Connection to openpgpkey.foo.com (1.2.3.4) failed: Bad > certificate. Trying direct method" although I would prefer a hard > error. Definitely, the decision which method to try should be very simple, as the WKD draft intended. Only one decision point instead of many paths leading back to a change of method. > (Of course, if the user explicitly requested the client/library to only > use the direct method, ignore certificate errors, etc. it'd be fine to > do so) That's an excellent suggestion, giving Sequoia an option to force trying one method or the other. I don't know if adding as many command line switches as gpg has is your cup of tea, but e.g. an environment variable could be used to really make it a "debugging" type of option. The great benefit is that Sequoia can then act as a WKD checker, which should always examine the intended, but possibly misconfigured, method or even both. > PPS: Another benefit would be that we could have avoided this long > thread. :-) I couldn't resist trying to help Stefan understand where the error lies, so apologies for my share of the message flood :-) Kind regards André -- Greetings... From: André Colomb signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
