On Thu 2019-04-18 22:27:19 +0200, Wiktor Kwapisiewicz wrote:
Oh, I was not suggesting adding TXTs - believe me I'd like to have a
good Web compatibility too (that's why I asked about CORS previously,
and well... added support for WKD to OpenPGP.js :).
The interesting thing about MTA-STS's fix is not that it was a TXT
record, but rather that offers a gating mechanism for a domain to
explicitly opt into the protocol, rather than everyone being
automatically opted-in (and therefore potentially spoofed in the way
that Wiktor is concerned about).
Is there some analogous semantics that we can offer that would still be
accessible from the browser?
Or, if we decide to gate WKD by a TXT record, can a javascript
in-browser implementation use something like DoH to do the TXT lookup?
Got it, thank you for your remarks! I was thinking about using just the
bare domain lookup (without subdomain) that avoids the issue
altogether.
I'm pretty sure i don't like the bare domain lookup, and would prefer
that that fallback was removed from the draft. If i give you the
ability to place files on my website, i don't expect you to be able to
assert e-mail identity information for me or for my users.
And if someone wants to delegate hosting keys to someone else adding
permanent redirect in HTTP server is usually simple (Nginx example):
location ~ /.well-known/openpgpkey/(.*) {
return 301 https://example.com/.well-known/openpgpkey/$1;
}
The draft doesn't seem to mention whether clients should follow HTTP
redirects, or what the privacy/security/performance impacts of such a
practice are.
For example, should a WKD client follow an HTTP redirect to an http://
(not https://) site? If the other site redirects, how many layers of
redirection should be followed?
--dkg
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp