<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 18, 2014 at 3:09 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
In conclusion, there's a lot of ways to distribute keys.  We probably<br>
want more and better keyservers.  It's hard to say who should run<br>
these.  Maybe existing service providers will help, or can be<br>
leveraged regardless - that's worth discussing more.<br></blockquote><div><br></div><div>I'm currently working on an alternative to existing openpgp keyservers (and an alternative to trust models such as WoT) called Nyms which is structured as a collection of independently operated authorities where m-of-n authority endorsements are required for a key to be considered validly certified.  Association between public key and email address is confirmed by performing an email exchange protocol between the authorities and the user address.  For example, suppose that 5 authority servers are in operation and that the network is configured so that at least 3 (m=3) authority signatures are required.  To publish a key the verification protocol would need to be performed with any 3 of the 5 existing authorities to collect 3 valid endorsement signatures at which point the network would accept the new key for publication.  The endorsement requirements are also verified by clients obtaining keys published on the servers</div>
<div><br></div><div>This is all automated of course.  Users install a client agent which performs the initial registration protocol and maintains their keys on the network.   The agent is also responsible for retrieving keys to communicate with other users, as well as actually encrypting/signing email messages.   The agent can be integrated into any existing email client by implementing a local communication protocol (it's json-rpc) to the encryption service provided by the agent.</div>
<div><br></div><div>Some other properties of the system are:</div><div><br></div><div>  * Only requires changes to email clients, and does not depend at all on participation of email providers. </div><div>  * However, optionally allows providers to vouch for authenticity of keys, since they are in a privileged position to do so.</div>
<div>  * Completely automated and transparent from user's point of view.  In absence of attacks, user never expected to make trust decisions.</div><div>  * Local agent manages publication, renewal, retrieval of keys.  Designed for easy integration into any email client (or even browser extensions)</div>
<div>  * Published keys which are not renewed eventually expire, allowing users who lose keys to re-register with new keys without needing explicit revocation certificates.</div><div>  * Users are able to confirm expectations of key continuity by periodically (and anonymously) polling keyservers for updates to keys they already possess.  </div>
<div><br></div><div>A more detailed overview is available at <a href="http://nyms.io">http://nyms.io</a></div><div><br></div><div>Would love to hear comments on this plan!</div><div><br></div><div><br></div><div>--brl</div>
<div><br></div></div></div></div>