WKD proper behavior on fetch error

[Andrew Gallagher]

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
the correct decision? I don't know. Should this decision have been 
flagged more prominiently? Perhaps. But remember that WKD is a key
discovery mechanism, not a validation mechanism. It is far from
unreasonable to consider prioritising availability over correctness.

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.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210118/6da352b8/attachment.sig>