Re: WKD proper behavior on fetch error

[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 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
behaviour after the certificate has been correctly rejected.

Yes I do understand that behavior, but that wasnt explained that way
by Stefan.

And I have understood it so far that Stefan claims Sequoia recognizes
 this certificate as valid and therefore continues to work.

To my understanding, Stefen has not yet spoken of a "fallback".

Stefan's understanding of the issue is incomplete; Neal's detailed
explanation of 13th Jan above explains exactly what is going on, and it
does not involve incorrectly accepting invalid certs.

He actually went so far, to urge Werner in a more than rude way to
add this (wrong) behavior into GnuPG.

I agree that GnuPG is under no obligation to emulate Sequoia's behaviour here, although it would of course be preferable if a consensus could be arrived at.

For me personally, this is still a major obstacle to using Sequoia productively or to recommend it to our customers. I still regard this

 behavior as a gross error that needs to be fixed.

I think this is unfair on Sequoia. They have deviated from a draft
standard, but they have made a prima-facie case for doing so. Was this

discovery mechanism, not a validation mechanism. It is far from
unreasonable to consider prioritising availability over correctness.



--
Andrew Gallagher

the correct decision? I don't know. Should this decision have been flagged more prominiently? Perhaps. But remember that WKD is a key Some things in security are absolutes, and some things are trade-offs. IMO this issue falls squarely in the "trade-off" category. Perhaps we could collectively take a breath before continuing.

OpenPGP_signature
Description: OpenPGP digital signature

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