Re: WKD proper behavior on fetch error

2021-01-17 Thread André Colomb
On 18/01/2021 00.43, Stefan Claas wrote:
> But what you say I was thinking about as well. My proposal was to include
> in the policy file fingerprint(s) of key(s) and generate an .ots file, from
> opentimestamps.org, from the policy file and put that .ots file somewhere.
> In the old days it was common, prior starting encrypted comms to compare
> fingerprints over other channels.

If you are coordinating the use of a separate channel to compare
fingerprints, you can also just coordinate where the public keys are to
be downloaded.  As others have pointed out[1], it's even easier to set
up than WKD (no rules to follow).  And if you're not using the whole
thing for e-mail, then you're probably not using an e-mail client with
automatic WKD retrieval.  So there is no benefit of using WKD over
making up your own URL and telling that to your communication partners.

[1]: https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064633.html

> And regarding secure domains, would you consider VPS servers secure
> too for WKD?

I don't know about the servers, my point was about the domain control.
Whoever can change the DNS records can just have them point to a
different server with their own (malicious) content.  GitHub Pages as a
free web hosting service will certainly not give you the same security
guarantees as a hosting provider where you pay money to administer a
domain of your own.

> BTW. I did not received yet your reply for my two other accounts, hence the
> late reply.

Sorry, I don't quite understand.  Would you like a reply to be addressed
directly in addition to the mailing list?

Kind regards
André

-- 
Greetings...
From: André Colomb 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD proper behavior on fetch error

2021-01-17 Thread Neal H. Walfield
Hi Stefan,

On Sun, 17 Jan 2021 19:41:44 +0100,
Stefan Claas via Gnupg-users wrote:
> Please try to accept that GitHub (and maybe in the future others as well)
> has *no* bad certificate!

As others have tried to explain: the certificate that github uses for
sub.sub.github.com is invalid for sub.sub.github.com; that certificate
is only valid for sub.github.com and github.com.

:) Neal

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


WKD Checker

2021-01-17 Thread Neal H. Walfield
On Sun, 17 Jan 2021 19:27:05 +0100,
Ángel wrote:
> I feel there is a need for a proper wkd test suite (as well as a
> clarifying on the draft itself the things that are coming up).

FWIW, there is Wiktor Kwapisiewicz's wkd checker:

  https://gitlab.com/wiktor-k/wkd-checker
  https://wkd.sequoia-pgp.org/

This is more for checking a WKD setup than checking a WKD client.

I'm sure he'd be open to issues for things that he missed.

:) Neal

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD proper behavior on fetch error

2021-01-17 Thread raf via Gnupg-users
On Sun, Jan 17, 2021 at 10:27:24PM +0100, Stefan Claas via Gnupg-users 
 wrote:

> On Sun, Jan 17, 2021 at 10:16 PM Juergen Bruckner via Gnupg-users
>  wrote:
> 
> Please try to accept that GitHub's SSL cert is *valid*, or do you think
> that a CA certifies and invalid cert?

Please try to accept that github's certificate is only
valid for the domains that the CA certified it as being
valid for (which are listed in the certificate itself
for all to see), and that it is not valid for any other
domain (that the CA did not certify it as being valid
for).

I thought the passport example was very good. A slight
tweak (for wildcard certificates) is to imagine a
passport that identifies a person and their children,
but not their grand children. I think such passports
exist (or used to), but only for very young children.
It's not a perfect analogy, but I hope it paints the
picture well enough.

cheers,
raf


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD proper behavior on fetch error

2021-01-17 Thread raf via Gnupg-users
On Sun, Jan 17, 2021 at 09:14:37AM +0100, Stefan Claas 
 wrote:

> Regarding a multi-purpose key and WKD. I mentioned here already
> that a multi-purpose usage key can be used for other tasks as well,
> besides popular email.

I know that keys can be used for things other than
email, but the point I was making is that WKD is only
for email. It's entire reason for existing is to
automatically and reliably find the key that
corresponds to an email address. It has no other
purpose.

But I can see that what you really want is to be able
to use WKD for other purposes. But I don't see how that
would work well. I assume that all existing WKD clients
are email clients. I think you are suggesting that
other types of system that are not email-related start
to adopt WKD for locating keys. That sounds reasonable.
Perhaps they will.

But I think that it would look strange to require a
label for a key that looks like an email address but
isn't, in order to obtain a key. I can't help thinking
that just publishing the URL of the key would be much
much simpler. Simpler still, and more automatable,
would be to come up with your own proposal for placing
keys in a website's .well-known directory and not have
anything at all to do with labels that look like email
addresses but aren't. I can't help thinking that if you
use labels that look like addresses but aren't, people
are likely to assume that it is an email address and
will try to send emails to it, and be thwarted. It
breaks the principle of least astonishment. But maybe
that won't be a problem, depending on the nature of
these other systems.

cheers,
raf


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD proper behavior on fetch error

2021-01-17 Thread André Colomb
On 17/01/2021 21.39, Juergen Bruckner via Gnupg-users wrote:
> And as far as Sequoia is concerned, Stefen's explanations only confirmed
> that this is software that I definitely don't want to use.
> Software that accepts an invalid digital certificate as correct, has no
> place in an environment where security and confidentiality are concerned.
> This is an  a b s o l u t e  NO-GO.

To be fair, it's not quite that bad.  Sequoia does recognize the invalid
certificate as such, as Neal pointed out.  It just doesn't scream out
loud about it.  Instead it goes on silently trying the direct method
instead, for which everything is configured correctly in Stefan's setup.

That is not following the current WKD draft correctly, as interpreted by
the majority of those who spoke up IIRC.  But so far no scenario was
brought up where it poses an obvious security risk.  More like hiding
the problem from an admin trying to deliberately set up the advanced
method and possibly ending up with some forgotten remains of the direct
method having been used before.

In my opinion, the WKD spec needs clear rules about cases when to switch
to the direct method.  And making it hinge solely on proper DNS
configuration is perfectly fine.  Having enough control over the domain
is one more prerequisite (besides the CA stuff) which an impostor would
need to get around.  After all, the corresponding web server is trusted
to deliver the correct OpenPGP public key for authenticated communication.

@Stefan, are you aware that in your scheme involving sac001.github.io,
whoever convinces GitHub to give them control over that subdomain, can
silently replace those public keys and start a man-in-the-middle attack?
 You could not even rely on the TLS layer, because GitHub probably will
not revoke their wildcard certificate just for you.  Hijacking a GitHub
Pages user name seems more likely than taking over a well secured domain
hosting account.

Kind regards
André

-- 
Greetings...
From: André Colomb 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why is there a conflict?

2021-01-17 Thread bereska--- via Gnupg-users
"a@b:c$ gpg -e -b -r Mike data.file" produces the encrypted file 
data.file.sig with the detached signature of data.file

I don't think there's a oneliner for what you're trying to achieve

gpg -er Mike data.file
gpg -b data.file.gpg


17.01.2021 00:56, Ayoub Misherghi via Gnupg-users пишет:


a@b:c$ gpg -e -b -r Mike data.file


produced "data.file.sig" and no "data.file.gpg"


Thanks,


Ayoub



On 1/16/2021 2:53 AM, Dmitry Gudkov wrote:

Just get rid of -s

On Jan 16, 2021 12:35, Ayoub Misherghi via Gnupg-users 
 wrote:



The intention is to sign and encrypt "data.file" producing a detached 
signature file.



a@b:c$ gpg -s -e -b -r Mike data.file

gpg: conflicting commands


Why is there a conflict? I do not want to produce an attached signature.


Ayoub



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD proper behavior on fetch error

2021-01-17 Thread Stefan Claas via Gnupg-users
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

2021-01-17 Thread Remco Rijnders
On Sun, Jan 17, 2021 at 10:27:24PM +0100, Stefan wrote in 
:

On Sun, Jan 17, 2021 at 10:16 PM Juergen Bruckner via Gnupg-users
 wrote:

Hi Juergen.


Your showcase with github.io also says nothing else than that Sequoia
considers an invalid certificate to be correct. That this happens in
audited software says just as much about the value of the audit.


Please try to accept that GitHub's SSL cert is *valid*, or do you think
that a CA certifies and invalid cert?


It is not valid for the requested sub-sub-domain. Just as if you would hold my
passport, the passport itself might be valid, but it is not valid for you to
identify yourself with.

That said, welcome to my kill file.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD proper behavior on fetch error

2021-01-17 Thread Stefan Claas via Gnupg-users
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

2021-01-17 Thread Juergen Bruckner via Gnupg-users

Well Stefan,

Am 17.01.21 um 21:44 schrieb Stefan Claas:

On Sun, Jan 17, 2021 at 9:40 PM Juergen Bruckner via Gnupg-users
 wrote:


I can only agree with Andre's words.


Perfectly fine for me if you take this route.


And as far as Sequoia is concerned, Stefen's explanations only confirmed
that this is software that I definitely don't want to use.


You don't have to, because we live in a free world.


Yes we live in a free world, and you shouldn't forget this!



Software that accepts an invalid digital certificate as correct, has no
place in an environment where security and confidentiality are concerned.
This is an  a b s o l u t e  NO-GO.


You talking nonsense while not knowing!


Thank you very much! I'll take that as compliment!


GnuPG doesn't have to change anything here.
The change MUST be made at Sequoia, preferably yesterday!


Utterly nonsense, IMHO. sequoia-pgp, Mailvelope (supported by BSI
and *audited*) and flowcrypt do all work with github.io pages! And you
were not able to reply to me here if your WKD set-up for dummies worked
for you. So much for that part...


If something, or a software ist supported by BSI and/or audited *does 
not* say it is free of bugs or failures.


Your showcase with github.io also says nothing else than that Sequoia 
considers an invalid certificate to be correct. That this happens in 
audited software says just as much about the value of the audit.


And it's not 'my' setup for dummies, it was a general question because 
most of the explanations are very specific and can pose major problems 
for a 'beginner'.


I have been using WKD successfully in different versions for a long 
time. The only thing that was new for me in this context is the 
possibility of implementing WKD via the openpgp server using a CNAME entry.


Best
Juergen
--
/¯\   No  |
\ /  HTML |Juergen Bruckner
 Xin  |juergen@bruckner.email
/ \  Mail |



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Fundraising

2021-01-17 Thread Robert J. Hansen via Gnupg-users
A little more than a month ago I said I'd match all donations made to
GnuPG from December 10 to January 6.  I'm happy to report y'all made me
contribute 370 Euros, or about $450 USD.  The money has been paid and
is sitting in GnuPG's account.

I hope this encouraged some of y'all to donate to GnuPG this year.  And
if you missed out, why not consider making a recurring monthly
contribution of your own?  It's a great way to tell the crew thank-you
for all the work they do.

Thanks, all the GnuPG contributors.  I really appreciate it!



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD proper behavior on fetch error

2021-01-17 Thread Stefan Claas via Gnupg-users
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

2021-01-17 Thread Damien Goutte-Gattat via Gnupg-users

On Sun, Jan 17, 2021 at 06:53:29PM +0100, Erich Eckner via Gnupg-users wrote:
And I assume, it's non-trivial or even impossible to start proper DNS 
queries (for a SRV record) from within JS?


Apparently not, at least that what folks on the IETF openpgp mailing 
lists said when the issue had been debated [1].


That’s why the WKD protocol (which *used* to rely on SRV records to 
provide a level of indirection between the domain name and the WKD 
server, which was The Right Thing™ do to) had to drop the SRV records in 
favor of a fixed subdomain, at the demand of Javascript developers.




Because it seems to me, the root for this debate is in gnupg's "ab"use 
of a subdomain for something which should actually be a SRV record. 


Given that this “abuse” was almost forced upon GnuPG developers by JS 
developers who basically said “please change your protocol otherwise 
there’s no way I can implement it”, and that Werner was on the record 
reluctant to the change [2], I find it quite disheartening that the 
blame should be put at GnuPG’s feet. :(


Oh well, all problems in the OpenPGP world are GnuPG’s fault anyway. It 
is known.



- Damien

[1] 
https://mailarchive.ietf.org/arch/msg/openpgp/f6V8W9wKY6dt2wAq4FBOWk8wtos/


[2] 
https://mailarchive.ietf.org/arch/msg/openpgp/SH1dzlERTgJsaCoKvxQGsnckq-w/


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD proper behavior on fetch error

2021-01-17 Thread Stefan Claas via Gnupg-users
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

2021-01-17 Thread Juergen Bruckner via Gnupg-users

I can only agree with Andre's words.

And as far as Sequoia is concerned, Stefen's explanations only confirmed 
that this is software that I definitely don't want to use.
Software that accepts an invalid digital certificate as correct, has no 
place in an environment where security and confidentiality are concerned.

This is an  a b s o l u t e  NO-GO.

GnuPG doesn't have to change anything here.
The change MUST be made at Sequoia, preferably yesterday!

regards
Juergen

Am 17.01.21 um 21:17 schrieb André Colomb:

Hi Stefan,

On 17/01/2021 19.41, Stefan Claas via Gnupg-users wrote:

Please try to accept that GitHub (and maybe in the future others as well)
has *no* bad certificate! The only thing which could be considered "bad"
or at least sub-optimal for a global ML, like this one, Is the support in
form of the GnuPGP ecosystem devs.


GitHub's web server, *in your specific use case* is sending a
certificate proving it is an apple when you're asking for it under the
name "orange".  That makes the certificate *invalid* for that connection
request as it could not be distinguished from a man in the middle attack
asking your browser to "Please try to accept that this apple is an orange".

Don't you find it strange that you are the only one still insisting that
it's valid when several very knowledgeable people have explained to you
in many different ways why it's simply not true?

And please tone down on the GnuPG criticism.  It's your right to dislike
the software or even Werner Koch personally.  But this is not the right
place for anti-publicity or constant personal stabs against people who
have patiently spent a lot of time to help and educate you.  Please try
to keep the discussion productive.

Kind regards
André


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users



--
/¯\   No  |
\ /  HTML |Juergen Bruckner
 Xin  |juergen@bruckner.email
/ \  Mail |



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD proper behavior on fetch error

2021-01-17 Thread André Colomb
Hi Stefan,

On 17/01/2021 19.41, Stefan Claas via Gnupg-users wrote:
> Please try to accept that GitHub (and maybe in the future others as well)
> has *no* bad certificate! The only thing which could be considered "bad"
> or at least sub-optimal for a global ML, like this one, Is the support in
> form of the GnuPGP ecosystem devs.

GitHub's web server, *in your specific use case* is sending a
certificate proving it is an apple when you're asking for it under the
name "orange".  That makes the certificate *invalid* for that connection
request as it could not be distinguished from a man in the middle attack
asking your browser to "Please try to accept that this apple is an orange".

Don't you find it strange that you are the only one still insisting that
it's valid when several very knowledgeable people have explained to you
in many different ways why it's simply not true?

And please tone down on the GnuPG criticism.  It's your right to dislike
the software or even Werner Koch personally.  But this is not the right
place for anti-publicity or constant personal stabs against people who
have patiently spent a lot of time to help and educate you.  Please try
to keep the discussion productive.

Kind regards
André

-- 
Greetings...
From: André Colomb 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why is there a conflict?

2021-01-17 Thread Ayoub Misherghi via Gnupg-users

  
  


On 1/16/2021 3:18 AM, Stefan Claas
  wrote:


  On Sat, Jan 16, 2021 at 11:57 AM Stefan Claas
 wrote:

  

On Sat, Jan 16, 2021 at 11:34 AM Ayoub Misherghi via Gnupg-users
 wrote:


  

The intention is to sign and encrypt "data.file" producing a detached signature file.


a@b:c$ gpg -s -e -b -r Mike data.file

gpg: conflicting commands


Why is there a conflict? I do not want to produce an attached signature.



You use -s and -b, try 'gpg -a -b -e file'

  
  
You can shorten this like: 'gpg -aber Mike data.file' (cool German
word 'aber' :-)

Regards
Stefan

gpg -aber data.file
produced "data.file.asc" and no "data.file.sig"


Danke,


Ayoub





  


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why is there a conflict?

2021-01-17 Thread Ayoub Misherghi via Gnupg-users

  
  
a@b:c$ gpg -e -b -r Mike data.file


produced "data.file.sig" and no "data.file.gpg"


Thanks,


Ayoub





On 1/16/2021 2:53 AM, Dmitry Gudkov
  wrote:


  
  
  
  Just get rid of -s
  
On Jan 16, 2021 12:35, Ayoub Misherghi
  via Gnupg-users  wrote:

  
  


The intention is to sign and encrypt "data.file" producing a
  detached signature file.


a@b:c$ gpg -s -e -b -r Mike data.file
gpg: conflicting commands


Why is there a conflict? I do not want to produce an attached
  signature.



Ayoub

  

  


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD proper behavior on fetch error

2021-01-17 Thread Stefan Claas via Gnupg-users
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

2021-01-17 Thread Ángel
On 2021-01-17 at 16:28 +0100, Stefan Claas wrote:
> sorry, but simply said I discovered now that a second major and
> trusted
> contender, Mailvelope supported by BSI and audited, works also as
> sequoia-pgp does. Werner and his (shrinking in numbers) supporters
> should think now what do to, instead of defending something, that
> could
> be improved. Try to see it this way, It does not hurt, I promise! :-)
> 
> I will try to find the US competitor for Mailvelope and test this as
> well.

Looking at mailvelope dns queries, it isn't even trying the advanced
method, so no wonder it doesn't fail on a bad certificate there.

Looking at flowcrypt code at 
https://github.com/FlowCrypt/flowcrypt-browser/blob/master/extension/js/common/api/key-server/wkd.ts
they do support the advanced method but on any failure fetching the
policy file, they will check the direct method (this may be slightly
different to the condition in which way sequoia falls back).

I feel there is a need for a proper wkd test suite (as well as a
clarifying on the draft itself the things that are coming up).

Best regards


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD proper behavior on fetch error

2021-01-17 Thread Erich Eckner via Gnupg-users

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 17 Jan 2021, Ingo Klöcker wrote:


On Sonntag, 17. Januar 2021 10:48:17 CET Erich Eckner via Gnupg-users wrote:

Hi all,

On Thu, 14 Jan 2021, Werner Koch via Gnupg-users wrote:

On Thu, 14 Jan 2021 01:47, Ángel said:

I understand this to mean it as "only use the direct method if the
required sub-domain does not exist", with the SHOULD meaning that the
direct method is not required (not sure why, I would have probably used


Right.  The subdomain is actually a workaround for SRV RR.  We can't
use the latter in browser based implementation and thus need to resort
to this hack.


Forgive my ignorance, but can someone explain, what "browser based
implementation" of WKD exists (or might exist) and/or why this is
desirable?


https://openpgpjs.org/ supports WKD. OpenPGP.js is used by many web
applications (see link). This is desirable to allow webmailers (and other web
applications that support OpenPGP) to lookup OpenPGP keys via WKD.


Ah, yes, I didn't see the possibility/need to have the keyring in the 
browser (or no keyring at all) and receive keys from within the browser. 
:-)


Thanks for the pointers!

And I assume, it's non-trivial or even impossible to start proper DNS 
queries (for a SRV record) from within JS?


Because it seems to me, the root for this debate is in gnupg's "ab"use of 
a subdomain for something which should actually be a SRV record. (Plus the 
fact, that DNS wildcards and TLS wildcard certficates work differently.)




Regards,
Ingo



regards,
Erich

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAEeZoACgkQCu7JB1Xa
e1prNhAAnSOXwNUZSQtpU1716Nccb1pywGpvNkKn/KWSA6kDhacKqtjs3KzOtXNW
0bppT7QaCNxAcJVKqKhbki5epNRRDdft/KM9Pw1I/c+n+TjOPS6340r7qlZXBV1c
0wlCuAPSGLvV6nl5oeGnDmQqn0uT7fT52Gt8iUQdRnrHI+u6Q/kR4SEQyDAili2A
HnN58CXotrNeihAooOoQZxc8Qlfd1DRWyAQ60wgFQX/0HTIkAaAXlPljN5DBlbAd
1c1cEFMmHAxfz5CsWS77jl9G30ysxt3JKpGy0Xr6Pe2WfEipdUBQCwMO6lS82iXo
RUFQm4ybDByXVBaqpJXCnFPZT+Mxe3gSS4BwpFwsDWMh5V7iIp1atExazsjQPc5U
UC7KldS6NqMqFhFtDn17sNATx/lKqmeh2Lze8vQ4x/tqxzNiR6tXZ43S/DJEiPsR
uo0K2h7DPFnEt34HvQeiq3bt/kPAKEwg6Lj80fWq9zA506j2elg1PlXfj/hSqEPh
rw/9CVD414uuf4W7ncF/9ijOPhO1k4hJIdv32VTWOxso8oSHIdEH+sjZwINH8ABn
Jb8eq05BVRQwsnCqSZShyaMJCVXYh9dDDe6TLebfhTS13aUzvbqqw9hhGNbSB9Xj
DCL3M9uCX8rIpcorihGsBN0Oa0yXpVwdkf8Jv2AHWiSpidsF3nw=
=Fwhi
-END PGP SIGNATURE-___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD proper behavior on fetch error

2021-01-17 Thread Ingo Klöcker
On Sonntag, 17. Januar 2021 10:48:17 CET Erich Eckner via Gnupg-users wrote:
> Hi all,
> 
> On Thu, 14 Jan 2021, Werner Koch via Gnupg-users wrote:
> > On Thu, 14 Jan 2021 01:47, Ángel said:
> >> I understand this to mean it as "only use the direct method if the
> >> required sub-domain does not exist", with the SHOULD meaning that the
> >> direct method is not required (not sure why, I would have probably used
> > 
> > Right.  The subdomain is actually a workaround for SRV RR.  We can't
> > use the latter in browser based implementation and thus need to resort
> > to this hack.
> 
> Forgive my ignorance, but can someone explain, what "browser based
> implementation" of WKD exists (or might exist) and/or why this is
> desirable?

https://openpgpjs.org/ supports WKD. OpenPGP.js is used by many web 
applications (see link). This is desirable to allow webmailers (and other web 
applications that support OpenPGP) to lookup OpenPGP keys via WKD.

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD proper behavior on fetch error

2021-01-17 Thread Stefan Claas via Gnupg-users
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

2021-01-17 Thread Stefan Claas via Gnupg-users
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

2021-01-17 Thread Stefan Claas via Gnupg-users
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

2021-01-17 Thread Ángel
On 2021-01-17 at 00:28 +0100, Stefan Claas wrote:
> On Sun, Jan 17, 2021 at 12:09 AM raf wrote:
> > What you refer to as "proper" is just the direct method.
> > That's only half of the WKD protocol. There is also the
> > advanced method. Both methods together comprise the WKD
> > protocol.
> 
> And in the case of GnuPG and gpg4win it does not work
> like one would expect, if the direct method is part of the
> protocol, because it will not be triggered if an error occurs
> with the advanced method.


It is part of the protocol, under certain rules:
> Only if the required sub-domain does not exist, they SHOULD
> fall back to the direct method.
(from section 3.1)

The sub-domain exists, and thus gnupg does not fall back to the direct
method.


I guess most people (still) reading this thread to be somewhat familiar
with their local driving regulation (however that is called).


Let's suppose we were all building autonomous cars, intended to be
driven¹ in San Serriffe, where the law stated:
> When approaching a road intersection, the driver² must first
> determine if there is a traffic light, in which case they are allowed
> to cross it if it is Green. Else, they should verify if there is a
> zebra crossing, and can go through if there is no pedestrian on it.



The current discussion is analogous to having a car approaching an
intersection where there is a red traffic light lit and a zebra
crossing with no people.

One brand of car sees the red light and stops. The other falls back to
looking at the zebra crossing and goes through.







> You know what I like in the whole discussion most ,that people
> always assume, when trying to convince me, that like
> you say, that I am not familiar enough with this and
> that and when I counter argument that I do not yet have received
> here a simple answer, for all laymens here reading, why
> can GnuPG or gpg4win not fallback or test the availabilty
> of the direct-method? I thing it is a quite simple question
> and nor Werner or anybody else can, so it seems, answer
> this. The only satisfactory and honest answer came only
> from Neal so far, explaining why it properly works with
> sequoia-pgp.

GnuPG (gpg4win is just including GnuPG) see that the advanced method is
available, so why should they fall back to the direct method?
Of course, the code *could* be changed to do that, but there should be
a reason. Similarly, some San Seriffe car owners could argue that if a
pedestrian crosses the road not on a zebra crossing, the proper action
by their car was to run over them. The car manufacturers may still
prefer not to do that.




¹ Or may be just "observed while it drives itself"
² Usually human, but the car in this case


> You can assume what ever you like and try to convince me,
> but sorry to say this, fact is sequoia-pgp works and GnuPG
> and gpg4win does not.

That highly depends on what you consider to be "working". You
have a certificate error on https://yourbank.de. Browser A
simply shows an error to the user. Browser B automatically goes to 
http://yourbank.de, letting the user perform their banking there.

Which browser "works"?



> My advise would be that Werner thinks of proper wildcard
> subdomain support, like my Github case and as already
> suggested (as I have seen now) to give WKD users are
> *clear* picture.

There is no "wildcard subdomain support" issue for TLS certificates.
Both GnuPG and sequoia agree that the certificate presented by
github.io for the advanced method is invalid.



If you mean for wildcard DNS subdomains, that was already taken into
account months ago in the draft, it even hints at how domain owners can
avoid this issue:

> Sites which do not use the advanced method but employ wildcard DNS
> for their sub-domains MUST make sure that the "openpgpkey" sub-domain
> is not subject to the wildcarding.  This can be done by inserting an
> empty TXT RR for this sub-domain.



Best regards



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD proper behavior on fetch error

2021-01-17 Thread Ángel
On 2021-01-17 at 10:48 +0100, Erich Eckner wrote:
> Hi all,
> 
> On Thu, 14 Jan 2021, Werner Koch via Gnupg-users wrote:
> 
> > On Thu, 14 Jan 2021 01:47, Ángel said:
> >
> >> I understand this to mean it as "only use the direct method if the
> >> required sub-domain does not exist", with the SHOULD meaning that the
> >> direct method is not required (not sure why, I would have probably used
> >
> > Right.  The subdomain is actually a workaround for SRV RR.  We can't
> > use the latter in browser based implementation and thus need to resort
> > to this hack.
> 
> Forgive my ignorance, but can someone explain, what "browser based 
> implementation" of WKD exists (or might exist) and/or why this is 
> desirable?
> 
> Shouldn't the WKD draft rather give the WKD implementation the 
> responsibility to use a proper dns client library? I assume other 
> protocols (which allow SRV records to redirect requests) do this
> (xmpp, 
> irc, ...)?
> 
> regards, Erich

Hi Erich

I think that would be an implementation such as https://encrypt.to/ or
a wemail that wanted to only source openpgp.js, without needing to set
up a server-side gateway to resolve SRV records.

Best,

Ángel


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD proper behavior on fetch error

2021-01-17 Thread Stefan Claas via Gnupg-users
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

2021-01-17 Thread Erich Eckner via Gnupg-users

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 17 Jan 2021, Stefan Claas wrote:


On Sun, Jan 17, 2021 at 10:51 AM Erich Eckner via Gnupg-users
 wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all,

On Thu, 14 Jan 2021, Werner Koch via Gnupg-users wrote:


On Thu, 14 Jan 2021 01:47, Ángel said:


I understand this to mean it as "only use the direct method if the
required sub-domain does not exist", with the SHOULD meaning that the
direct method is not required (not sure why, I would have probably used


Right.  The subdomain is actually a workaround for SRV RR.  We can't
use the latter in browser based implementation and thus need to resort
to this hack.


Forgive my ignorance, but can someone explain, what "browser based
implementation" of WKD exists (or might exist) and/or why this is
desirable?


Well, Mailvelope, for example is a Browser based add-on with WKD support.
Mailvelope can be used with services like Gmail, so that you don't need a MUA.


Ah, I see. That makes sense: integrate the keyring (and thus also a WKD 
client) into the webmailer. OTOH: How do web-chat clients request SRV 
records? Or do they simply not work with servers, who offer their 
connection information via SRV?


regards,
Erich

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAEH74ACgkQCu7JB1Xa
e1qa4g/+IJxZDT0FpGVNCog2kXCmEJvouqxxnFrhVv62Xy3ycbOBQ8FAmOz1+3+9
NRPtonFVRBEQBk5Dd+tozIYIPC1pOLRCQPkuPr9CZ9Z+XcPWLyEtjV2FHESsWNHE
w2yI3aWfa1jpLymXNVWVpi0fmXzFS4dSsz3EU4lGWuwLbbFrBa9eg/2WEo9n15Ec
pdY2QBfAYEnzi8F9vnrkHlMDYb6uoaEbEkv4lDYIBUOocDYeLVLQaXyp4hZ154MU
qUnabQD1w9ZRhFFXz9k661Nbf8lp8xfodrqEB3FSaHoES16tlN7j18/O2a933exA
nRrdOzqGrRBJDa6UOp6HuxAZJ2bQtoDhSpOOihDC8ncAeox0Uw3dDb22FV7wDXNJ
FVaIf/ISpCDO+5H09HaNxro0Qwa/En8X1h4H7XrtfETGwgkvyPaO/zqoILGgSQsb
jCMSaDT1XUP++mtF+DR6RruizB29BkxiRMBo3cDrc4jE632MNq2sbFVWbpic3RZn
7L6OIsKWC1StmHWD1CLMgVULMBwTDveeCFEbsUpSvMCaCyyMGL2wAU4z+i2252JW
+pz4JP0cFT1YMDeBOj1VysTrCTkUzQwa//a3JooO9PolsVvHYhuPTfPAu2UMn4u1
RbakTh/2ELZKxB6VcpkmbpNYLnA+M6+u1+HiDnNOQOq4sd65qmY=
=oQdC
-END PGP SIGNATURE-___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD proper behavior on fetch error

2021-01-17 Thread Stefan Claas via Gnupg-users
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

2021-01-17 Thread Stefan Claas via Gnupg-users
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

2021-01-17 Thread Erich Eckner via Gnupg-users

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all,

On Thu, 14 Jan 2021, Werner Koch via Gnupg-users wrote:


On Thu, 14 Jan 2021 01:47, Ángel said:


I understand this to mean it as "only use the direct method if the
required sub-domain does not exist", with the SHOULD meaning that the
direct method is not required (not sure why, I would have probably used


Right.  The subdomain is actually a workaround for SRV RR.  We can't
use the latter in browser based implementation and thus need to resort
to this hack.


Forgive my ignorance, but can someone explain, what "browser based 
implementation" of WKD exists (or might exist) and/or why this is 
desirable?


Shouldn't the WKD draft rather give the WKD implementation the 
responsibility to use a proper dns client library? I assume other 
protocols (which allow SRV records to redirect requests) do this (xmpp, 
irc, ...)?


regards, Erich

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAEB+IACgkQCu7JB1Xa
e1oQwg/9FXVLP3RCDVsSERDwF1LV/nDx9xRJZSWixyxG+v5huW/jxT1C4xdJ4M8P
6dB/4I1CQSNd4c9/MflG3wOjKR+lA1RmtiXYX2ocK2armjNf0nHoFNCqlDs87AdI
kQUm9YBwPsNeSmzZb1DnbV0oU2y0Yv7EcxJygByR7G1WSPjnxyiwXtuu5e6Lpw96
06kyEf0+jyg7x7mn0F3FseQCyBwC9pYbm57Irm+KpCAoLVtPenWdq87R1Ypp4Ez4
nJyrzaC/h2MVXGHZcGb5fBqBYJAKgY9pIQOJ005NLiPW4K2o7mrPOT/DGNOvom8H
+NjtoMKY+Iypp5OOd1juYk/p5yan65H9WWqaiLLhORd+1WENffpHwkClJqCr1Nj4
zxcyxUIuhe8EIWLqmPGW4h/40KmDzJJiFNTASV5ZlI6l2cZPeRLOLbre/yyBvRtB
EiF5lMV2iytepRntblEmFT4CVPdGNYchY8Um5PklGWp59n3zCvJ0hJyhqPwBTKNL
4WFG/raUgdTkQJZlAi+NLGt3oFzycKPqBkaXn5ArYgmgTsUKNqUp8+5OxStbKyG2
9ZEFwzrkpuK1LtuW8xf9RIlqhfnS0IuGkgKE/ZPZl3hI+sT30Isv++4PyNeNFQ9C
64LWYkEEgPNUB70Gv+PFjKku9fv8YIROiFkXJqZ/Iq7a5ngd/48=
=xq9S
-END PGP SIGNATURE-___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD proper behavior on fetch error

2021-01-17 Thread Stefan Claas via Gnupg-users
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