WKD proper behavior on fetch error

[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 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 at colomb.de>

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