On Fri 2021-01-22 22:59:36 +, Andrew Gallagher via Gnupg-users wrote:
> On 22/01/2021 17:29, Daniel Kahn Gillmor via Gnupg-users wrote:
>> this is a non-backward-compatible change to the format, so i think
>> that's probably not a great outcome.
>
> I can't help thinking that length
On Fri, 22 Jan 2021 23:59:36 +0100,
Andrew Gallagher via Gnupg-users wrote:
> On 22/01/2021 17:29, Daniel Kahn Gillmor via Gnupg-users wrote:
> > this is a non-backward-compatible change to the format, so i think
> > that's probably not a great outcome.
>
> I can't help thinking that length
On Tue 2021-01-19 13:08:19 +0100, Werner Koch via Gnupg-users wrote:
> On Tue, 19 Jan 2021 09:28, Neal H. Walfield said:
>
>> When you look up the openpgpkey.example.org domain, you are revealing
>> to anyone snooping DNS traffic that you are using OpenPGP and are
>> looking for a key related to
On 22/01/2021 17:29, Daniel Kahn Gillmor via Gnupg-users wrote:
> this is a non-backward-compatible change to the format, so i think
> that's probably not a great outcome.
I can't help thinking that length fingerprinting and padding oracles are
a general concern, and therefore more appropriately
On Thu 2021-01-21 18:49:19 +0100, Neal H. Walfield wrote:
> Please don't do this. This is the format of a TPK:
>
> https://tools.ietf.org/html/rfc4880#section-11.1
>
> It doesn't allow arbitrary packets to follow it, as far as I can see.
fair enough. It also doesn't allow arbitrary trailing
On 2021-01-21 at 18:49 +0100, Neal H. Walfield wrote:
> On Thu, 21 Jan 2021 17:10:31 +0100,
> Daniel Kahn Gillmor wrote:
> > For WKD services which cannot control their webserver to disable
> > compression, and automate padding, a better approach would be to
> > pad
> > each published key with an
On Thu, 21 Jan 2021 17:10:31 +0100,
Daniel Kahn Gillmor wrote:
> For WKD services which cannot control their webserver to disable
> compression, and automate padding, a better approach would be to pad
> each published key with an OpenPGP literal data packet, whose content is
> filled with a
(my messages might not be arriving at @gnupg.org addresses right now
because their mailserver appears to be rejecting my mailserver claiming
(incorrectly, afaict) that the reverse DNS is not configured --
hopefully it will be resolved soon; feel free to re-forward this message
to the list if it
On Wed, Jan 20, 2021 at 12:41 AM Ángel wrote:
> A list of all (well, most) openpgpkey subdomains can be easily created.
Yes and I believe that what Neal and you (in your new posting) have explained
makes it only worthwhile for Mallory to start his work, because he has such an
openpgpkey list
Hello all
First, I agree with Neal in considering there is a privacy leak in
using WKD (with no analysis/mitigations).
dkg has already provided an excelent explanation about this, and seems
material directly usable into the Security Considerations section.
As noted, the openpgpkey server
On 2021-01-19 at 19:29 +0100, Stefan Claas wrote:
> Example: Mallory sitting in the United States likes to prepare
> a list (without my consent) and published on a U.S. site,
> so that like SKS key server dumps the whole world can
> obtain a list of all openpgpkey subdomains. So far so good.
>
>
On Tue, Jan 19, 2021 at 7:06 PM Stefan Claas
wrote:
>
> On Tue, Jan 19, 2021 at 1:14 PM Werner Koch via Gnupg-users
> wrote:
> >
> > On Tue, 19 Jan 2021 09:28, Neal H. Walfield said:
> >
> > > When you look up the openpgpkey.example.org domain, you are revealing
> > > to anyone snooping DNS
On Tue, Jan 19, 2021 at 1:14 PM Werner Koch via Gnupg-users
wrote:
>
> On Tue, 19 Jan 2021 09:28, Neal H. Walfield said:
>
> > When you look up the openpgpkey.example.org domain, you are revealing
> > to anyone snooping DNS traffic that you are using OpenPGP and are
> > looking for a key related
On Tue, Jan 19, 2021 at 5:16 PM Stefan Claas
wrote:
>
> On Tue, Jan 19, 2021 at 5:05 PM Stefan Claas
> wrote:
>
> > A policy file could look like this, with remark lines at the
> > beginning:
> >
> > # WKD policy for sac001.github.io (WRONG)
> # WKD policy file for https://sac001.github.io
> > #
On Tue, Jan 19, 2021 at 5:05 PM Stefan Claas
wrote:
> A policy file could look like this, with remark lines at the
> beginning:
>
> # WKD policy for sac001.github.io (WRONG)
# WKD policy file for https://sac001.github.io
> # Maintainer: Stefan Claas, ste...@sac001.github.io
> # Updated: current
On Tue, Jan 19, 2021 at 2:36 AM Ángel wrote:
>
> On 2021-01-17 at 23:43 +, Stefan Claas via Gnupg-users wrote:
> > I encountered only one MITM attack a couple of years ago so far, from an
> > SKS user. He was a retired police officer from Austria, who contacted me.
> > But what you say I was
On Tue, 19 Jan 2021 09:28, Neal H. Walfield said:
> When you look up the openpgpkey.example.org domain, you are revealing
> to anyone snooping DNS traffic that you are using OpenPGP and are
> looking for a key related to example.org. That's a privacy issue.
No, it isn't. The next thing you do
On Mon, 18 Jan 2021 16:47:38 +0100,
Ángel wrote:
> So, while in the first case a bad certificate would be a critical
> failure, in the second the right thing would be to fetch the key
> *even if the certificate was invalid*, as it is used purely for
> discovery.
When you look up the
On Tue, 19 Jan 2021 10:11, raf said:
> And it's discovery that begins with an email address. I
> still can't work out what functionality WKD provides in
> a situation that isn't email-related.
The Web Key Directory maps mail addresses to a key. Mail addresses are
universal identifiers and thus
On 2021-01-17 at 23:43 +, Stefan Claas via Gnupg-users wrote:
> I encountered only one MITM attack a couple of years ago so far, from an
> SKS user. He was a retired police officer from Austria, who contacted me.
> But what you say I was thinking about as well. My proposal was to include
> in
On Mon, Jan 18, 2021 at 01:42:52PM +0100, André Colomb wrote:
> We need to remember that WKD is only a convenience mechanism for
> discovery, not any kind of authentication.
>
> Kind regards
> André
And it's discovery that begins with an email address. I
still can't work out what functionality
@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
On 2021-01-18 at 10:14 +0100, Neal H. Walfield wrote:
> I've given this issue some more thought.
>
> First, I don't think WKD is a strong authentication method. It is
> sufficient for doing key discovery for opportunistic encryption (i.e.,
> it's a reasonable guess), but I wouldn't want someone
On Mon, 18 Jan 2021 13:42:52 +0100,
André Colomb wrote:
> On 18/01/2021 10.14, Neal H. Walfield wrote:
> > In short: I understand the motivation for the subdomain. I understand
> > why one should first check there. But, I think we do our users a
> > disservice by not falling back to the direct
Hi Neal,
On 18/01/2021 10.14, Neal H. Walfield wrote:
> First, I don't think WKD is a strong authentication method. It is
> sufficient for doing key discovery for opportunistic encryption (i.e.,
> it's a reasonable guess), but I wouldn't want someone to rely on it to
> protect them from an
Hello Andrew,
Am 18.01.21 um 13:17 schrieb Andrew Gallagher via Gnupg-users:
On 18/01/2021 11:33, Juergen Bruckner via Gnupg-users wrote:
Hello Andrew,
Am 18.01.21 um 12:17 schrieb Andrew Gallagher via Gnupg-users:
On 18/01/2021 11:07, Juergen Bruckner via Gnupg-users wrote:
Sequoia accepts
On 18/01/2021 11:33, Juergen Bruckner via Gnupg-users wrote:
Hello Andrew,
Am 18.01.21 um 12:17 schrieb Andrew Gallagher via Gnupg-users:
On 18/01/2021 11:07, Juergen Bruckner via Gnupg-users wrote:
Sequoia accepts an *invalid* certificate for the host
'foo.abc.github.io' and that is "failure
Hello André,
Am 18.01.21 um 00:03 schrieb 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
Hello Andrew,
Am 18.01.21 um 12:17 schrieb Andrew Gallagher via Gnupg-users:
On 18/01/2021 11:07, Juergen Bruckner via Gnupg-users wrote:
Sequoia accepts an *invalid* certificate for the host
'foo.abc.github.io' and that is "failure by design".
This is incorrect. Sequoia *does not* accept
On 18/01/2021 11:07, Juergen Bruckner via Gnupg-users wrote:
Sequoia accepts an *invalid* certificate for the host
'foo.abc.github.io' and that is "failure by design".
This is incorrect. Sequoia *does not* accept this invalid certificate.
Sequoia and gnupg only differ in their fallback
Hello again Stefan
Am 17.01.21 um 22:27 schrieb Stefan Claas:
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
Hi Angel,
On Thu, 14 Jan 2021 01:47:12 +0100,
Ángel wrote:
> On 2021-01-13 at 10:12 +0100, Neal H. Walfield wrote:
> As such, I do think sequoia is non-conformant, although I'm
> more interested in determining the proper behaviour of a WKD client.
>
> ...
> I think it would be good that sq
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
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
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
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
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
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
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
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.
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
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.
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
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
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
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
>
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
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,
-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
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
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
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
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
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.
>
>
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
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-
> >>
-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
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
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
-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
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
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
On Sun, Jan 17, 2021 at 12:09 AM raf via Gnupg-users
wrote:
>
> On Sat, Jan 16, 2021 at 02:20:17AM +0100, Stefan Claas
> wrote:
>
> > On Sat, Jan 16, 2021 at 1:45 AM raf via Gnupg-users
> > wrote:
> >
> > > But there is no certificate that covers that sub-sub-domain.
> > > That's why browsers
On Sat, Jan 16, 2021 at 11:07 PM Ángel wrote:
> You don't need a wildcard entry. You could simply request a certificate
> with the right name that will be needed.
Yes, for me as little nobody that is correct. But I guess we should not
forget the real host masters dealing with a couple (of
On Sat, Jan 16, 2021 at 02:20:17AM +0100, Stefan Claas
wrote:
> On Sat, Jan 16, 2021 at 1:45 AM raf via Gnupg-users
> wrote:
>
> > But there is no certificate that covers that sub-sub-domain.
> > That's why browsers complain if you go to
> > https://openpgpkey.sac001.github.io/.
>
> A quick
On 2021-01-16 at 02:20 +0100, Stefan Claas wrote:
> On Sat, Jan 16, 2021 at 1:45 AM raf wrote:
>
> > But there is no certificate that covers that sub-sub-domain.
> > That's why browsers complain if you go to
> > https://openpgpkey.sac001.github.io/.
>
> A quick question, if you don't mind. Why
On 2021-01-16 at 02:32 +0100, Stefan Claas via Gnupg-users wrote:
> Do I understand you correctly that if one uses now a subdomain
> like https://keys.300baud.de/.well-known/etc ... this would work
No. keys.300baud.de would work only for em...@keys.300baud.de
However, for em...@300baud.de, you
On Sat, Jan 16, 2021 at 2:25 AM Ángel wrote:
>
> On 2021-01-15 at 20:34 +0100, Stefan Claas via Gnupg-users wrote:
> > If you or someone else set's up a web server, for a big organisation
> > or for yourself, you simple put in the .well-known folder some
> > content which would look most likely
On 2021-01-15 at 20:34 +0100, Stefan Claas via Gnupg-users wrote:
> If you or someone else set's up a web server, for a big organisation
> or for yourself, you simple put in the .well-known folder some
> content which would look most likely then like this:
>
> http://domain.tld/.well-known/etc...
On Sat, Jan 16, 2021 at 1:45 AM raf via Gnupg-users
wrote:
> But there is no certificate that covers that sub-sub-domain.
> That's why browsers complain if you go to
> https://openpgpkey.sac001.github.io/.
A quick question, if you don't mind. Why do people here on this ML
insist on a sub-sub
On Fri, Jan 15, 2021 at 07:56:26AM +0100, André Colomb wrote:
> Am 15. Januar 2021 01:56:04 MEZ schrieb raf via Gnupg-users
> :
> >But of course, you're not asking for that. You're just
> >asking for something to work. There must be other ways.
> >Accepting invalid certificates might just have
On Fri, Jan 15, 2021 at 07:56:16AM +0100, Stefan Claas
wrote:
> On Fri, Jan 15, 2021 at 2:04 AM raf via Gnupg-users
> wrote:
>
> [...]
>
> > I'm really not an expert, and the above might not make
> > any sense. I'm just thinking aloud.
>
> Me neither ... :-) For me, the questions I had is
On Fri, Jan 15, 2021 at 7:39 PM Ángel wrote:
>
> On 2021-01-15 at 07:56 +0100, Stefan Claas via Gnupg-users wrote:
> > Don't you think when GitHub, a major player, would have an invalid
> > SSL cert, that maybe one of the millions programmers there would not
> > have contacted GitHub, like I did,
On 2021-01-15 at 07:56 +0100, Stefan Claas via Gnupg-users wrote:
> Don't you think when GitHub, a major player, would have an invalid
> SSL cert, that maybe one of the millions programmers there would not
> have contacted GitHub, like I did, and say hey GithHub you serve
> the global community
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
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
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
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
> >
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
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
>
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
On Thu, Jan 14, 2021 at 1:50 AM Ángel wrote:
> PPS: Another benefit would be that we could have avoided this long
> thread. :-)
The greatest benefit would have been if the author of WKD, namly Werner Koch,
had been so kind to explain to us why WKD needs two methods and what
security
On 2021-01-13 at 10:12 +0100, Neal H. Walfield wrote:
> I'd like to clarify what Sequoia is doing (wrong).
> (...)
Hello Neal
Thanks for chiming in and explaining the steps taken by sequoia.
I'll try to re-focus this subthread back on the initial topic of your
email.
> The I-D says "Only if
83 matches
Mail list logo
