Mailing List Archive

On Sun, Jan 17, 2021 at 10:51 AM Erich Eckner via Gnupg-users
<gnupg-users@gnupg.org> 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

On Sun, Jan 17, 2021 at 11:18 AM Stefan Claas
<spam.trap.mailing.lists@gmail.com> 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

-----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
> <gnupg-users@gnupg.org> 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-----

On Sun, Jan 17, 2021 at 12:33 PM Erich Eckner via Gnupg-users
<gnupg-users@gnupg.org> 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
> > <gnupg-users@gnupg.org> 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

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

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

On Sun, Jan 17, 2021 at 3:49 PM Ángel <angel@pgp.16bits.net> 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

On Sun, Jan 17, 2021 at 4:28 PM Stefan Claas
<spam.trap.mailing.lists@gmail.com> wrote:
>
> On Sun, Jan 17, 2021 at 3:49 PM Ángel <angel@pgp.16bits.net> 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

On Sun, Jan 17, 2021 at 9:14 AM Stefan Claas
<spam.trap.mailing.lists@gmail.com> 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

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

-----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-----

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

On Sun, Jan 17, 2021 at 7:30 PM Ángel <angel@pgp.16bits.net> 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

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 <andre@colomb.de>

On Sun, Jan 17, 2021 at 9:21 PM André Colomb <andre@colomb.de> 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

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
X in | juergen@bruckner.email
/ \ Mail |

On Sun, Jan 17, 2021 at 9:40 PM Juergen Bruckner via Gnupg-users
<gnupg-users@gnupg.org> 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

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/

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
> <gnupg-users@gnupg.org> 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
X in | juergen@bruckner.email
/ \ Mail |

On Sun, Jan 17, 2021 at 10:16 PM Juergen Bruckner via Gnupg-users
<gnupg-users@gnupg.org> 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

On Sun, Jan 17, 2021 at 10:27:24PM +0100, Stefan wrote in
<CAC6FiZ4uHas_Qz3UC-ixfe3hhGeBj5isp6OZ5Yvs=RrWLvM2vQ@mail.gmail.com>:
>On Sun, Jan 17, 2021 at 10:16 PM Juergen Bruckner via Gnupg-users
><gnupg-users@gnupg.org> 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

On Sun, Jan 17, 2021 at 11:02 PM Remco R?nders <remco@webconquest.com> wrote:
>
> On Sun, Jan 17, 2021 at 10:27:24PM +0100, Stefan wrote in
> <CAC6FiZ4uHas_Qz3UC-ixfe3hhGeBj5isp6OZ5Yvs=RrWLvM2vQ@mail.gmail.com>:
> >On Sun, Jan 17, 2021 at 10:16 PM Juergen Bruckner via Gnupg-users
> ><gnupg-users@gnupg.org> 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

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 <andre@colomb.de>

@Stefan, are you aware that in your scheme involving sac001.github.io,whoever convinces GitHub to give them control over that subdomain, cansilently replace those public keys and start a man-in-the-middle attack?You could not even rely on the TLS layer, because GitHub probably willnot revoke their wildcard certificate just for you. Hijacking a GitHubPages user name seems more likely than taking over a well secured domainhosting account.I encountered only one MITM attack a couple of years ago so far, from anSKS user. He was a retired police officer from Austria, who contacted me.But what you say I was thinking about as well. My proposal was to includein the policy file fingerprint(s) of key(s) and generate an .ots file, fromopentimestamps.org, from the policy file and put that .ots file somewhere.In the old days it was common, prior starting encrypted comms to comparefingerprints over other channels.And regarding secure domains, would you consider VPS servers securetoo for WKD?I must say good night now.?BTW. I did not received yet your reply for my two other accounts, hence thelate reply.Best regardsStefan

On Sun, Jan 17, 2021 at 09:14:37AM +0100, Stefan Claas <spam.trap.mailing.lists@gmail.com> 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