[messaging] Thoughts on keyservers

[Nadim Kobeissi]

I've read the overview for Nyms and I'm scratching my head as to why it  
would be a good idea to bring what is effectively a CA-like system to  
email. Effectively what Nyms seems to be proposing is establishing  
key-signing authorities but for email, similar to how HTTPS/SSL works  
right now with certificate authorities.

Considering the disaster that CAs have been and how desperately we've been  
attempting to escape them (Trevor's work on Tack being one of the best  
examples), why would you want to replace Web of Trust, which is  
effectively decentralized, for a model that centralizes authority in a way  
that makes it ripe for compromise by a few actors?

One thing that Nyms does better than the CA system seems to be asking for  
m-of-n certifications. But I'm having trouble seeing how Nyms would  
establish its certificate authorities without a top-down hierarchical  
process. Who decides who gets to be an authority? Who decides which  
authorities are telling the truth? Can I just game the system by having  
the most authorities on my side? Why is this secure?

I understand that the certificate authority model has usability gains but  
I'm really unsure this is the right direction.

On Mon, 18 Aug 2014 09:52:26 -0400, Bruce Leidl <bruce at subgraph.com> wrote:

> 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


-- 
Nadim Kobeissi
Web Systems Programming and Security
Shapeshape | shapeshape.co