<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Patrick Brunschwig wrote on 18.05.18
08:32:<br>
</div>
<blockquote type="cite"
cite="mid:0f9f283a-b546-11ff-bd7c-80681f5bfe40@enigmail.net">
<pre class="moz-quote-pre" wrap="">On 17.05.18 20:26, Ben Bucksch wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Phillip Hallam-Baker wrote on 17.05.18 14:21:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
What I think we need is to work out what the complete set of
roadblocks for ubiquitous use of S/MIME is and form a comprehensive
strategy that addresses them all or at least enough to get somewhere.
This will likely lead to an S/MIME+ specification or specification
profile similar to what WiFi is to 802.11b.
I will certainly make sure Thunderbird gets an invite.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I think it would be nice for you, Patrick Brunschwig and me to get
together and talk about this, some time, after eDail is over. Patrick,
because he built the certificate creation dialog for enigmail (which is
completely local), and me, because I designed the account creation dialog.
My interest is to make this completely transparent without any further
input from the end users. Completely automatic. Similar to how
letsencrypt automatically configures the web server for https and
answers the challenge, we should do the same. For letsencrypt, the user
doesn't have to anything else than run the program, and it should be the
same for email.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
You're aiming into the same direction as Autocrypt
(<a class="moz-txt-link-freetext" href="https://autocrypt.org">https://autocrypt.org</a>) which I co-authored.</pre>
</blockquote>
<p><br>
</p>
<p>Am I reading that right that autocrypt makes the keys of my
correspondance partner (Bob) discoverable automatically? That is a
great idea, to put them into the email headers. That will be very
useful.<br>
</p>
<p>I was actually speaking about a different problem, the initial
setup of the key, without any user interaction whatsoever.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:0f9f283a-b546-11ff-bd7c-80681f5bfe40@enigmail.net">
<pre class="moz-quote-pre" wrap="">Khushil Mistry ("my" GSoC
student) is working on some of the grounds to make this happen in Enigmail.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">S/MIME has the advantage that we don't have to worry too much about lost
keys. SSL is build on that idea that you can just throw them away and
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Why do you think so? A lost key means lost access to old encrypted mails.</pre>
</blockquote>
<p><br>
</p>
<p>Ah, true.</p>
<p>But fact of life is that most users will lose keys and harddrives
and forget passwords.</p>
<p>That's been the major problem for all crypto deployment. Not
being able to read one's own mail is a major SNAFU that average
Janes won't forgive, and they'll just trash email entirely and use
WhatsApp.</p>
<p>That's why I like this sentence in the <a moz-do-not-send="true"
href="https://autocrypt.org/level1.html">Autocrypt spec</a>: "we
want to
avoid unreadable mail for users. Users may mix both
Autocrypt-capable
and traditional mail apps and they may lose devices or in other
ways
the ability to decrypt in unrecoverable ways. Reverting to
cleartext
when we suspect such situations is a key part of our aim to stay
out of
the way of users."</p>
<p>That's where PEP fails, namely when people uninstall PEP, or lose
their hardware device and keys. The users get encrypted mail that
they can't read.<br>
</p>
<p>Ben<br>
</p>
</body>
</html>