<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 14, 2013 at 2:50 PM, Tony Arcieri <span dir="ltr"><<a href="mailto:bascule@gmail.com" target="_blank">bascule@gmail.com</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="gmail_quote"><div class="im">On Wed, Nov 13, 2013 at 9:46 PM, Greg <span dir="ltr"><<a href="mailto:greg@kinostudios.com" target="_blank">greg@kinostudios.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div style="word-wrap:break-word"><div><div>The basics would be to not use the CAs. Working on rest of details, they're mostly finished, just gotta make 'em nice 'n pretty. And some code would be good, too.</div>


</div></div></blockquote><div><br></div></div><div>And what of other solutions like CT or Tack?</div><div><br></div><div>Given Google's power to influence change via Chrome and its share of the browser market, I think we'll see CT as the the primary solution for what ails the existing PKI.</div>
</div></div></div></blockquote><div><br></div><div>How does CT prevent coding errors in browsers? in Adobe Flash? </div><div><br></div><div>How does CT prevent network managers losing their keys or exporting the private component and sending it to someone as an attachment?</div>
<div><br></div><div>How does CT shut down a party that legitimately obtains a certificate and then acts maliciously?</div><div><br></div><div><br></div><div>There are many issues with the Web PKI. The biggest one is actually the fact that most of the browsers make reducing connection latency a higher priority than processing certificate revocation properly.</div>
<div><br></div><div> </div></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>