<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 11, 2015 at 8:38 AM, Ralf Senderek <span dir="ltr"><<a href="mailto:crypto@senderek.ie" target="_blank">crypto@senderek.ie</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Sat, 11 Jul 2015 05:37:18 Phillip Hallam-Baker wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
A private PKI consists of [no] more than a dozen or so Certificate Signing Certs. When I read them into my cert collection, I can<span class=""><br>
construct all the cert chains etc. with little difficulty.<br>
I verify that each cert is valid according to the profile<br>
requirements etc, and check that it chains to the root of the<br>
personal PKI.<br>
</span></blockquote>
<br>
That raises the question how the decision to include any particular<br>
Signing Cert is reached. If for a frictionless use case the user<br>
has nothing to do with this decision, how should he gain any trust<br>
in the validity of his own personal PKI?</blockquote><div><br></div><div>Making trust decisions in a personal PKI is trivial. Either it chains up to the personal root of trust that has his personal fingerprint or it does not. The only way that a certificate can chain to her personal root is if </div><div><br></div><div>1) Alice signed it</div><div>2) Alice lost control of her key</div><div>3) The algorithm has been broken</div><div><br></div><div>I don't try to stop (2) beyond keeping the master keys offline and locking the online admin signing keys to specific devices, instead I provide a way to recover if there is a disaster. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In use, the entire system is completely frictionless.<br>
</blockquote>
<br></span>
That's your most important selling point.</blockquote><div><br></div><div>Yes and that goal comes before perfecting the security. This is pretty good security, not perfect.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The only time a user ever needs to be aware of using encrypted mail<br>
is when they want to force use of encryption or force use of encryption<br>
with a key they have a verified fingerprint of.<br>
</blockquote>
<br></span>
How did this verification happen? Why is it secure?<br></blockquote><div><br></div><div>Using strong email addresses, the fingerprint of the root of trust for the receiver is embedded in the email address. So if you send an email message to:</div><div><br></div><div><pre class="" style="font-size:13.3333330154419px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ?<a href="mailto:phb@hallambaker.com">phb@hallambaker.com</a></pre><pre class="" style="font-size:13.3333330154419px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"><br></pre></div><div>The email address is legal rfc822 and can be stored in a contacts directory but the username isn't legal on any operating system or sensible webmail system (injection error city).</div><div><br></div><div>If the message is sent through the <a href="http://prismproof.org">prismproof.org</a> email proxy, it will strip out the fingerprint, try to pull an email profile with the specified fingerprint from the mesh and extract an S/MIME key that chains to that root.</div><div><br></div><div>[OK so right now it is doing that without actually doing the path math to validate the chain but that is just a matter of coding]</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Again, I think the scheme does not answer the most important question of<br>
how a user can be sure he's using the correct correspondent's key, if<br>
all decisions regarding the validity of keys are done on his behalf by<br>
"the mesh" and "a tool".</blockquote><div><br></div><div>The mesh isn't a trust infrastructure. That is a separate problem. I have written a paper on the problem but before I can work on the trust problem I need to solve the distribution problem.</div><div><br></div><div>One layer of security is provided by having a CA issue a cert using an email loopback challenge.</div><div><br></div><div><br></div><div>I am also looking into doing a peer to peer loopback automation scheme. This is a consequence of working out how to automate S/MIME cert issue (same approach works for OpenPGP of course).</div><div><br></div><div>Alice sends an email to Carol (who may or may not be a CA). It contains headers:</div><div><br></div><div>ACME: <span style="color:rgb(0,0,0);font-size:13.3333330154419px">MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ?</span><a href="mailto:alice@example.com">alice@example.com</a>;</div><div>   challenge=VGhpcyB3YXMgb2J2aW91c2x5IGFuIGV4YW1wbGUu</div><div><br></div><div>Carol responds:</div><div> </div><div>ACME: <font color="#000000"><span style="font-size:13.3333330154419px">MOF3W-K23MN-BYWY2-3FNJT?carol</span></font>@<a href="http://example.com">example.com</a>;</div><div>   challenge=cXdsa2VrbHF3amhlZmxranFoZGZsa2poYWRsa2ZqaGFsc2Rsa2pobA0K<br></div><div>ACME-Response: <font color="#000000"><span style="font-size:13.3333330154419px">MOF3W-K23MN-BYWY2-3FNJT?carol</span></font>@<a href="http://example.com">example.com</a>;</div><div><span style="color:rgb(0,0,0);font-size:13.3333330154419px">   by=MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ?</span><a href="mailto:alice@example.com">alice@example.com</a>;</div><div>   challenge=VGhpcyB3YXMgb2J2aW91c2x5IGFuIGV4YW1wbGUu;</div><div>   nonce=d2xrZWpmaGFsa3NqZGZobGtzYWpoZGZsa2phaHN;</div><div>   result=kZmtsamhrbGFzZGtsZmtsYWpzZGhma2xqaAYUxLZXJ5M28<br></div><div><br></div><div>[Alice will now respond in like form in their next interaction]</div><div><br></div><div>So if the response is valid Carol has demonstrated:<br></div><div> 1) The ability to read email sent to <a href="mailto:carol@example.com">carol@example.com</a>.</div><div> 2) Control of a private key trusted in the personal pki with the root <span style="color:rgb(0,0,0);font-size:13.3333330154419px">MOF3W-K23MN-BYWY2-3FNJT that is authorized to respond to challenges.</span></div><div><br></div><div><br></div><div>This is a pretty good starting point for Alice and Carol to start exchanging messages that are encrypted by default.</div><div><br></div><div>Of course, it is really desirable for any mail exploder or the like to strip out the headers and responses should be ignored if there is an exploder header in the response. Otherwise some mailing lists will get lots of encrypted mail. But at this point there aren't many mailing lists that are that broken.</div></div></div></div>