On Thu, 20 Apr 2017, Yoav Nir wrote:
On 20 Apr 2017, at 17:22, Paul Wouters <paul@xxxxxxxxx> wrote: generate a key pair on registration, store those keys on the server (in an encrypted archive), and make the public key available. A little coding later and we've got key exchange and message confidentiality. SMTP servers could be key servers without having the private key of individuals? Sure. If they double as HTTPS servers.
I should drink coffee before posting... What I meant to say was the model where the mail server generates and/or has a copy of the private key seems dangerous. And I tried to say SMTP servers could be key servers with only having public keys, not private keys. Still, using (E)SMTP has all the problems I described earlier.
I want to send you an email, so I type “paul@xxxxxxxxx” 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. Paul