Jonathan Schleifer wrote: > Am 20.08.2008 um 16:24 schrieb Remko Tronçon: > >> Upgrading a well-established secure >> standard to a new use case sounds slightly more fail-safe than >> creating a new one from the ground up. > > That has issues like: > * Only works with keys which is user unfriendly
Please read other posts. There are a) other options than keys and b) you can hide the complexity of keys somehow. > * Was designed for server to client connection and not client to > client connection. But with client-certification request it does what is needed. > I don't see why everyone wants to use TLS for it, it really wasn't > designed for that IMO! Several reasons: 1. Many many people looked at TLS and TLS implementations. It is a well understood protocol. ESessions lack support of many implementations and the long discussions providing us TLS as it is now. TLS (as protocol) is done, ESessions is not. 1. Easy to implement. Re-use code used for link-local messaging and normal client server communication. Most implementations do not have ESession support but they already support TLS. 3. Easy to implement. I just hook into any TLS lib and I'm done. If my application design does not work well together with openssl, I choose tlslite or m4crypto or whatever. One will fit. I don't care about the details. 4. Possible to use without XMPP server. Use Jingle to set up a new connection. This makes it possible to avoid the usage of base64. I don't see why you want to use ESessions when TLS is something that is working right now. We already have E2E TLS support in XMPP, we only need a way to verify the keys. Dirk -- Hidden DOS secret: add BUGS=OFF to your CONFIG.SYS
