<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 23, 2013 at 6:02 PM, Philip Whitehouse <span dir="ltr"><<a href="mailto:philip@whiuk.com" target="_blank">philip@whiuk.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"><div>Let me just see if I get where you're going:</div>
</blockquote><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"><div>
So essentially you've increased the number of CAs to the number of companies without really solving the PRISM problem. The sheer number mean it's impractical to do much more than a cursory check before approval.<br>
</div></blockquote><div><br></div><div>The number of CAs would not need to be very large, I would expect it to be in the hundreds in a global system but that is pretty much a function of their being hundreds of countries.</div>
<div><br></div><div>If <a href="http://example.com">example.com</a> wanted to run their own CA for their own email certs then the way to do it would be to issue them a cert signing cert that has name constraints to limit its use to just <a href="mailto:name@example.com">name@example.com</a>.</div>
<div><br></div><div><br></div><div>The idea is that there are multiple CAs but their actions are all vetted for transparency and they all check up on each other.<div><br></div><div>Any one CA can be served with an NSL, but if they issue a coerced certificate it will be immediately visible to the target. So a government can perform a DoS attack but not get away with an impersonation attack.</div>
</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"><div>
PRISM for email is bad because we don't even know who we can trust. I can't trust the provider because they could have been served an NSL. The provider has to see the metadata or they can't route the email. So I'm doomed. Best case is I can secure the contents and use an alternate name. At that point I need an organization I trust to act as my Omnibroker who for some reason I don't trust with the mail itself.<br>

<br>
One other question: PPE = Prism Proof Email?<br>
<br>
Nor do I think key chain length was the problem - initial key authentication and distribution is the first issue.<br>
<br>
Philip Whitehouse</div></blockquote><div><br></div><div><br></div><div>Well the way that was solved in practice for PGP was Brian LaMachia's PGP Key server :-) Which turned into a node of very high degree...</div><div>
 </div></div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>