[messaging] Thoughts on keyservers

Bruce Leidl bruce at subgraph.com
Mon Aug 18 06:52:26 PDT 2014


On Mon, Aug 18, 2014 at 3:09 AM, Trevor Perrin <trevp at trevp.net> wrote:

>
> In conclusion, there's a lot of ways to distribute keys.  We probably
> want more and better keyservers.  It's hard to say who should run
> these.  Maybe existing service providers will help, or can be
> leveraged regardless - that's worth discussing more.
>

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

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.

Some other properties of the system are:

  * Only requires changes to email clients, and does not depend at all on
participation of email providers.
  * However, optionally allows providers to vouch for authenticity of keys,
since they are in a privileged position to do so.
  * Completely automated and transparent from user's point of view.  In
absence of attacks, user never expected to make trust decisions.
  * Local agent manages publication, renewal, retrieval of keys.  Designed
for easy integration into any email client (or even browser extensions)
  * Published keys which are not renewed eventually expire, allowing users
who lose keys to re-register with new keys without needing explicit
revocation certificates.
  * Users are able to confirm expectations of key continuity by
periodically (and anonymously) polling keyservers for updates to keys they
already possess.

A more detailed overview is available at http://nyms.io

Would love to hear comments on this plan!


--brl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140818/b526e260/attachment.html>


More information about the Messaging mailing list