[Telepathy] Fwd: GSoC Project: Add OTR support to Telepathy/Empathy for XMPP

[Will Thompson]

On 03/06/11 04:04, João Paulo Rechi Vita wrote:
> I haven't thought that the UI could handle it entirely, it would be
> pretty straightforward since it would need the code to trigger an
> accept anyway. But wouldn't be easier to automatically test
> (continuous integration) this feature in the CMs than in the clients?

With the current test infrastructure, certainly. :)

> Key verification is not a requirement for establishing the encrypted
> channel, it just adds peer authentication. So the CM doesn't even need
> to know if the user (not the client) don't recognize the key
> fingerprint as being owned by it's conversation peer. In that case,
> the may (or may not) just decide to terminate the OTR session, or the
> even the conversation entirely. So "rejecting" the key would be
> terminating the OTR session, and "accepting" it would be just
> continuing it normally. I agree on having a property to store the
> key's object path, and on that object we could store the key
> fingerprint, the account it's tied to (maybe the account name should
> be part of the object path), and it verification status. Key
> verification (and thus peer authentication) can optionally be done
> inside the encrypted channel using the Socialist Millionaire Protocol.

Ah, interesting. So the CM negotiates the encrypted session without
needing any input from the UI (except of course determining that it
should establish the session in the first place), and verification-wise
it's basically just relaying information between D-Bus and the network.

Relatedly, in another mail, Christian wrote:

> The only subtlety is ensuring that the user receives all the proper
> notifications before it is possible for him to send messages over the
> encrypted channel. i.e. while the CM is still in the "AUTHENTICATING"
> state.

So perhaps the CM should queue calls to SendMessage() while the
encrypted session is being established, but once it has been
established, it should allow messages to be sent even if the contact's
identity has not been identified. Based on the above, the CM doesn't
actually have to know about the verification state (correct me if I'm
wrong). So this can be purely UI policy, since the UI has to know about
this anyway.

> The OTR protocol description calls "authentication state" each of the
> steps of the AKE, which is the "handshake" of the OTR protocol. This
> is not a very good name since it can be confused with peer
> authentication, but it doesn't have nothing to do with peer
> authentication. I think the state Christian and I called
> "AUTHENTICATING" is the same you've called "in progress", which means
> AKE has been started but not finished yet, so we're in the process of
> establishing an OTR session.

Okay, that's what I thought. Thanks for the clarification!

-- 
Will