Hi there: The way merkle-trees are used in Certificate Transparency is trustworthy, but at the same convenient, in a way that preserves the client<>server architecture. This can have many applications in other protocols and places, that we are only starting to see. It would probably be quite good in general to try to facilitate the usage this kind of security architecture design and tools to other projects.
Regards, On Thu, Aug 28, 2014 at 5:16 PM, Paul Wouters <[email protected]> wrote: > > > ---------- Forwarded message ---------- > Date: Thu, 28 Aug 2014 11:15:38 > From: Paul Wouters <[email protected]> > To: Trans <[email protected]> > Subject: end to end email encryption using CT gossip protocol > > > FYI > > https://code.google.com/p/end-to-end/wiki/KeyDistribution > > For End-To-End, our current approach to key distribution, is to use > a > model similar to Certificate Transparency, and use the email > messages > themselves as a gossip protocol, which allow the users themselves to > keep the centralized authorities honest. This approach allows users > to > not have to know about keys, but at the same time, be able to make > sure > that the servers involved aren't doing anything malicious behind the > users' back. > > To allow the system to be easily distributed (across multiple > identity > providers), key servers can authenticate the user via existing > federated > identity protocols (with OpenID Connect for example). The model of a > key > server with a transparency backend is based on the premise that a > user > is willing to trust the security of a centralized service, as long > as it > is subject to public scrutiny, and that can be easily discovered if > it's > compromised (so it is still possible to compromise the user's > account, > but the user will be able to know that as soon as possible). > > It's worth noting that End-to-End is still under active development, > and > we might change our approach to key distribution if we find > weaknesses > in this model, or if we find something else that is as easy to use, > and > as likely to work. Part of the reason we release this document is to > seek early feedback from the community, and adapt as needed. > > We also want to point out we will do our very best to continue to > support existing OpenPGP users who want to manually manage and > verify > keys and fingerprints manually, as we understand that system has > been > around for a long time, and has been more battle tested than what we > are > proposing. > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans -- Eduardo Robles Elvira @edulix skype: edulix2 http://agoravoting.org @agoravoting +34 634 571 634 _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
