Indeed there are not too many implementations. Wouldn't the new standard break compatibility any way?
However, according to http://en.wikipedia.org/wiki/Off-the-Record_Messaging, there are ones for Miranda, MCabber and pidgin: which is a start (compared to making a new standard which would have no implementations). I don't think any client supports what has been suggested so far, such as the brilliant (no sarcasm) suggestion by Dave. Dirk also had a good idea with (what looks like) one time passwords, but this would break compatibility. > Break compatibility with clients that already use the current way. The new standard will do this anyway right? Maybe a new element on the initiator's iq for E2E could be added (that an unsupported client SHOULD, as per spec, ignore). Hence E2E and E2E2 <grin> would be easily negotiable. > Libotr thinks our stanzas are HTML and act strange. Libotr (I am speaking out of turn here) probably collates a bunch of other standards for which I am sure there are many implementations: libotr is (once again, out of turn) ready to port to your language of choice. If we were to use the enveloped encryption stanza (where all of the contents of the original stanza are just encrypted) we could just send the XML as an opaque binary stream to libotr, at which point it won't mess with our XML structure. This would then be b64 encoded and send as follows: <encrypted from="[EMAIL PROTECTED]" to="[EMAIL PROTECTED]"> 192376123abd078f123aasdjib123khnasd0u123== </encrypted> And once decrypted the contents would be the ORIGINAL (outer xml) of the encrypted element. As for the break compatibility argument, the following states would apply. Originator-Supported Add <e2e2/> tag to iq query. Receiver-Supported Recognise <e2e2/> tag and begin e2e2 negotiation. Originator-Unsupported No changes made. Receiver-Unsupported No changes to code made, new <e2e2/> tag simply ignored if present. Negotate e2e as normal. Receiver-Unsupported Originator-Supported When first IQ response it aquired, <e2e2>...</e2e2> tag is not present. Continue e2e negotiation. As you can see it kinda works the kinks out itself. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Schleifer Sent: Tuesday, August 19, 2008 10:24 PM To: XMPP Security Subject: Re: [Security] TLS Certificates Verification You seem to totally ignore that there is only one implementation of OTR: libotr. And this is the reference implementation as the documentation, well, I don't think it's good enough to write a new implementation from scratch from that. And here come the problems: * We will break compatibility with clients that already use the current way. * libotr thinks our stanzas are HTML and act strange. -- Jonathan
