<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 18, 2014 at 7:21 PM, elijah <span dir="ltr"><<a href="mailto:elijah@riseup.net" target="_blank">elijah@riseup.net</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>On 08/18/2014 07:32 AM, Nadim Kobeissi wrote:<br>
<br>
> I've read the overview for Nyms and I'm scratching my head as to why it<br>
> would be a good idea to bring what is effectively a CA-like system to<br>
> email. Effectively what Nyms seems to be proposing is establishing<br>
> key-signing authorities but for email, similar to how HTTPS/SSL works<br>
> right now with certificate authorities.<br>
<br>
</div>Nyms is radically different than CA infrastructure in several important<br>
ways:<br>
<br>
(1) the model is trust but verify, which is very very different than<br>
trust all authorities equally for everything.<br>
<br>
(2) although called "trusted notaries" they are not really trusted. They<br>
are just key endorsers. Unlike x.509, a key could be endorsed by<br>
multiple notaries and the notaries are continually audited.<br>
<br>
(3) the website authentication problem is very different than the email<br>
recipient authentication problem (see previous email).<br>
<br>
Mostly just rephrasing what Bruce wrote.<br></blockquote><div><br></div><div>Sure, I get that. There's no need to rehash the original explanation.</div><div><br></div><div>There's a lot of vague promises that are bundled with this model. For example that "the notaries are continually audited." Is this really the practical scenario?</div>

<div><br></div><div>There's undeniably an issue of centralizing authority here, and there is something fundamentally problematic with the assertion of centralizing key authentication in the hands of select authorities. Even with a m-of-n trust but verify approach, centralizing the network and then allowing it to be gamed while saying "oh, we'll just pick trustworthy people and make sure they get audited regularly" simply sounds like an idea that belongs better back when S/MIME was making rounds, and not today where we've had so many lessons to learn from the failures of centralized authorities.</div>

<div><br></div><div>Sticking to PGP is confusing. We have many protocols and projects out there (Axolotl, or miniLock) that are focusing on primitives that are newer, leaner and that offer new venues for key management. Matthew Green recently wrote an excellent piece on this [1]. I also saw this pretty comic comparison of PGP's primitives to Cure25519 today [2].</div>

<div><br></div><div>The fact that folks are resorting to such lengths to try and save PGP is just clear indication that it's time to move on.</div><div><br></div><div>[1] <a href="http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html">http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html</a></div>

<div>[2] <a href="https://twitter.com/dchest/status/501486980338024449">https://twitter.com/dchest/status/501486980338024449</a></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">


<br>
It is an open question how to deal with a notary that is known to be<br>
bad, and who decides. In many cases, the endorser will also be the mail<br>
provider, and users can punish a bad mail provider by leaving.<br>
<span><font color="#888888"><br>
-elijah<br>
</font></span><div><div>_______________________________________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a><br>
</div></div></blockquote></div><br></div></div>