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 <[email protected]> wrote:
On Mon, Aug 18, 2014 at 3:09 AM, Trevor Perrin <[email protected]> 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
_______________________________________________
Messaging mailing list
[email protected]
https://moderncrypto.org/mailman/listinfo/messaging
