On Thu, Apr 20, 2017 at 11:08:20AM -0400, Paul Wouters wrote:
I want to send you an email, so I type “paul(_at_)nohats(_dot_)ca” in the
To: field, and my MUA goes to
https://mail-public-keys.nohats.ca/.well-known/mail-pubkeys/paul and that
gets your public key.
But any MUA can already get my key using RFC-7929 at
sha256("paul")[1:28]._openpgpkey.nohats.ca
eg:
dig openpgpkey
0357513deb903a056e74a7e475247fc1ffe31d8be4c1d4a31f58dd47._openpgpkey.nohats.ca.
So using another HTTP(S) server that is not the SMTP server itself does
not seem to make much sense to me? An SMTP server relaying the
OPENPGPKEY or SMIMEA or other source of pubkey could be useful,
if we think DNS transport is bigger problem than ESMTP transport.
But I think it is harder for people to contact mx.nohats.ca on port
25 from a random ISP compared to use DNS against 8.8.8.8 on an ISP
network.
This was all covered in the discussion of draft-moore-email-addrquery.
(Perhaps on the UTA rather than DANE list? I don't recall)
My take at the time was (and remains) that queries for the recipient's
public key can be tunneled through the user's MSA, thereby avoiding
the issue of inability to reach port 25 from consumer end-device
IP space. That discussion unfortunately appears to have worn-out
the draft author.
I still think that draft is worth pursuing, if one is willing to
not set the bar too high. The reason we have so little security
is sometimes (often?) because we're unwilling to accept less than
"perfect" security. It is not unreasonable to trust the MSA to be
a trusted proxy for remote keys. After all, in that model the same
MSA/MTA operator is trusted to vend your keys to others.
--
Viktor.