<div dir="ltr"><div class="gmail_default" style="font-size:small">I really don't want to appear to be running the proposal down. I think that putting fingerprints of keys in email headers is a really good idea. I proposed it at a SAAG three years ago.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I am not wanting to say 'my idea' here but some of you know I have been working on this area. I might not have the answer but I do have a map with bits labelled 'there be dragons'.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Modifying email clients is one approach. Redirect through a mail server proxy with SMTP/IMAP support is another. In the short term a proxy is the approach I have been looking at as it can support any client. I have a very primitive prototype for SMTP.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The problem I came up with in trying to make it work is that people want to be able to read their email on more than one device. So solving the trust issue alone isn't enough. It is also necessary to solve the key distribution problem which is what I have been working on the past two years.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small">The other thing I came up with as a refinement of the idea is 'strong email addresses'. The scheme I proposed at SAAG is not ideal. In response to objections from DNS folk, Paul Hoffman and others, I now have a DNS address format that contains a fingerprint:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">alice@example.com.mm-MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ</span></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small">Try to send email to that address through an unaware email server and it will simply bounce back. So this is an email address that you can use to force the use of encryption and get 'send secure or not at all' semantics.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One lesson I learned from TimBL and the Web is that 404 not found is genius. That fingerprint might or might not map to a security policy you can resolve. And that is OK. If you can't resolve the security policy, you can't use the address properly. You can guess but you will probably fail. And that is OK because you might not have the security policy because the address isn't meant for you.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The reason that I designed the UDF fingerprint format the way I did was so that I can support different security policy semantics. So for example we might have the fingerprint of a DNS root key and key through DANE or we might have a PKIX rood and do S/MIME.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For email, there are cases where I want to use disposable addresses and other cases where I want the fingerprint to be permanent.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The other relevant technical capability I came across while doing this work is proxy re-encryption which is very powerful. I am currently working on end-to-end encrypted Web. As in, the pages on the Web server are encrypted and even though there is a key server, you can put Robert Snowden in charge of both and he can't decrypt anything.</div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small">All my code is MIT license. (Some) Details are at</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><a href="http://prismproof.org/">http://prismproof.org/</a></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small">I am currently developing in C# but the protocol compiler I am using can also target C.</div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 22, 2016 at 6:04 PM, holger krekel <span dir="ltr"><<a href="mailto:holger@merlinux.eu" target="_blank">holger@merlinux.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Since last Sunday there is a new e-mail encryption effort called<br>
Autocrypt. It is an evolving project, with the general aim to replace<br>
cleartext mail with encrypted mail. The effort focuses on opportunistic<br>
approaches, convenience, incremental deployability, interoperability,<br>
and well-thought-out (and minimal) user experience.<br>
<br>
The project was born during the Automatic Mail Encryption meetup last<br>
week in Berlin. Around 20 people (MUA developers, researchers and<br>
encryption enthusiasts) worked for 5 days in several sessions, hacking<br>
activities and plenaries and happily agreed to continue the effort. Here<br>
is a list of features which distinguish it from previous efforts:<br>
<br>
<a href="https://autocrypt.readthedocs.io/en/latest/features.html" rel="noreferrer" target="_blank">https://autocrypt.readthedocs.<wbr>io/en/latest/features.html</a><br>
<br>
You'll see that early 2017 we'd like to settle on what we call "Level 0"<br>
support, i.e. support for mail encryption on a single app. There is<br>
active development in Enigmail, K-9 Mail, Mailpile, Bitmask and a<br>
reference bot implementation to get to a first fully Level 0 compliant<br>
implementation.<br>
<br>
Autocrypt "Level 1" will include, among other things, multi-device<br>
support; we made good progress on that during the meeting, but decided<br>
incremental adoption will be easier if we start simpler. And you don't<br>
even want to know what crazy things people have proposed for "Level 2" :P<br>
<br>
The overall index of docs (some very drafty still) can be found here:<br>
<br>
<a href="https://autocrypt.readthedocs.io/en/latest/index.html" rel="noreferrer" target="_blank">https://autocrypt.readthedocs.<wbr>io/en/latest/index.html</a><br>
<br>
If you'd like to help, have questions or comments you<br>
don't need to tweet about it but rather join us here:<br>
<br>
<a href="https://lists.mayfirst.org/mailman/listinfo/autocrypt" rel="noreferrer" target="_blank">https://lists.mayfirst.org/<wbr>mailman/listinfo/autocrypt</a><br>
#autocrypt on freenode or #autocrypt:<a href="http://matrix.org" rel="noreferrer" target="_blank">matrix.org</a>[1]<br>
<br>
As to meetings and further sessions, likely something will<br>
happen at: 33c3, RWC, IFF and lastly we plan for another<br>
fun multi-day meetup April/May 2017.<br>
<br>
so much, enjoy the rest of the year!<br>
holger, dkg and Vincent<br>
<br>
<br>
[1]: <a href="https://riot.im/app/#/room/#autocrypt:matrix.org" rel="noreferrer" target="_blank">https://riot.im/app/#/room/#<wbr>autocrypt:matrix.org</a><br>
______________________________<wbr>_________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" rel="noreferrer" target="_blank">https://moderncrypto.org/<wbr>mailman/listinfo/messaging</a><br>
</blockquote></div><br></div></div>