Sharon Boyen and I wrote this up as an RFC a while back:
The weakness as I see it is that it still lacks the data necessary to make the decision whether to use the key or not. In particular:
Alice@xxxxxxxxxxx sends a message to Bob@xxxxxxxxxxx
Forget the issue of trust for a moment, the infrastructure should deliver all the information that Alice's email client needs:
* Is encryption refused, optional or required?
* Which encryption protocols are supported (OpenPGP, S/MIME)?
* Which key(s) should be used?
Note that this is only the raw information, a client would also have to decide whether the information was trustworthy or not. Though if the email would be sent en-clair otherwise, that does not matter much.
For ubiquitous use of message level encryption, it is essential to take into account the fact that spam and malware filtering is actually a bigger concern than confidentiality:
END TO END ENCRYPTION IS NOT A PRIVILEGE I WILL EXTEND TO ANONYMOUS SENDERS
So encrypted mail is going to have to be signed by an authorized sender for end to end encryption to be permitted. Everything else goes through the filters as usual.
I am working on code right now: Prismproof.org
On Thu, Apr 20, 2017 at 10:36 AM, Yoav Nir <ynir.ietf@xxxxxxxxx> 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 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- and that gets your public key.pubkeys/paul And now my MUA can encrypt. And it all works, as long as we trust nohats.ca (and conversely gmail.com) and as long as you have a copy of your private key on every single MUA that you use.Small assumptions, no?Yoav