On 3/27/09 1:15 PM, Jonathan Schleifer wrote: > Am 27.03.2009 um 19:56 schrieb Peter Saint-Andre: > >> 2. Offline vs. Online >> >> Some folks didn't like the idea of XTLS because it is stream-based, not >> message-based. In particular, Pete Resnick [cc'd here because he's not >> on the list] noted that XTLS can't handle offline messages and so >> doesn't address all the use cases (as he put it, it seems silly to have >> one technology for encrypted communication when the other party is >> online and a different technology for encrypted communication when the >> other party is offline). Note that this objection applies only to >> end-to-end chat, not things like secure file transfer, since they go out >> of band. > > Wasn't this possible using ESessions? ESessions were message based as well.
I don't think it was. At least, Ian always told me that the extension of ESessions to offline messages was quite experimental (or, if you like, even more experimental than ESessions itself). You can find more here: http://xmpp.org/extensions/xep-0187.html It's been a while since I read all the ESessions specs... >> 5. JavaScript Clients >> >> More and more XMPP clients are being written in JavaScript. But there is >> no SSL/TLS stack for JavaScript. Furthermore, the dependency on X.509 is >> problematic because there is no ASN.1 support in JavaScript, either. (I >> also note that there is no OTR library for JavaScript.) If we can define >> something significantly simpler than XTLS or RFC 3923 or OTR, we would >> make it possible for JavaScript clients to play in this space. These >> considerations might lead us to favor something like (1) bare keys >> instead of self-signed X.509 certs [your key could in turn be signed by >> your X.509 cert or OpenPGP key if you have one], (2) TLS-like handshake >> instead of full TLS, (3) basic CMS [RFC 3852] instead of S/MIME, etc. > > Shouldn't this be possible with ESessions? Everything is possible with ESessions, no? > Anyway, I'm fine with either, be it ESessions or XTLS. But we need to > get it done. And we need to do that ASASP! In fact, it already should be > done and in use! We _NEED_ end-to-end-encryption, no matter which one! Agreed. That's why it is on the proposed charter for the XMPP WG. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
