ESessions is pretty swanky, I must admit. I must have missed the email about it somehow. Has it been reviewed at all? What protocol is it based on?
The <encrypted> stanza was a bad example, it could be put in another stanza (probably of the same type as the original). I haven't even looked at libotr (which is why I said I was speaking out of turn). If it can't handle binary then I suppose it isn't much use. But the protocol itself is still probably useful if it is made more formal. All that I am saying is that instead of coming up with our own protocols etc. we should be concentrating on how existing ones could be made to fit into the current XMPP standards. For example, we didn't invent our own SASL mechanism, we used already defined ones and made it configurable. Maybe something like that is needed? For example: <iq type="result"> <query xmlns='jabber:iq:e2e2:protocols'> <protocol>esessions</protocol> <protocol>otr</protocol> </query> </iq> A lot like SASL mechanisms. I know it adds extra complexity, but if, for example, a bug is found in OTR a client user could simply refuse incoming OTR requests and require esessions. Plugins could be built. Hell, using that you could use PGP is you _really_ wanted. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Schleifer Sent: Tuesday, August 19, 2008 10:52 PM To: [email protected] Subject: Re: [Security] TLS Certificates Verification Jonathan Dickinson <[EMAIL PROTECTED]> wrote: > (compared to making > a new standard which would have no implementations). ESessions *HAS* implementations! That's the point I bring up again and again against reinventing the wheel and doing something with TLS now! > <encrypted from="[EMAIL PROTECTED]" to="[EMAIL PROTECTED]"> > 192376123abd078f123aasdjib123khnasd0u123== > </encrypted> Now you're even talk about breaking XMPP Core compatibility? And libotr can't handle arbitrary data, just messages. For which it will add HTML escapes if it's plaintext. > 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. libotr uses whitespaces to detect support. It's hardcoded. > As you can see it kinda works the kinks out itself. Doesn't look like that to me. -- Jonathan
