<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 23, 2013 at 3:34 PM, Ben Laurie <span dir="ltr"><<a href="mailto:ben@links.org" target="_blank">ben@links.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="im"><br><div class="gmail_quote">On 22 August 2013 10:36, Phillip Hallam-Baker <span dir="ltr"><<a href="mailto:hallam@gmail.com" target="_blank">hallam@gmail.com</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">Preventing key substitution will require a combination of the CT ideas proposed by Ben Laurie (so catenate proof notaries etc) and some form of 'no key exists' demonstration.</blockquote>

</div><br></div>We have already outline how to make verifiable maps as well as verifiable logs, which I think is all you need. <a href="http://www.links.org/files/RevocationTransparency.pdf" target="_blank">http://www.links.org/files/RevocationTransparency.pdf</a>.</div>

</div>
</blockquote></div><br>Yeah, I think it is just a matter of being clear about the requirements and making sure that we fully justify the requirements for email rather than assume that email is the same.</div><div class="gmail_extra">
<br></div><div class="gmail_extra"><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>