WKD proper behavior on fetch error

[Juergen Bruckner]

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 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.
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

I fully agree!
nothing more to say!

-- 
/¯\   No  |
\ /  HTML |    Juergen Bruckner
  X    in  |    juergen at bruckner.email
/ \  Mail |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3894 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210118/8feaab5d/attachment-0001.bin>