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

[João Paulo Rechi Vita]

On Thu, Jun 9, 2011 at 19:42, Christian Anderson <christian at avtok.com> wrote:
> Thanks for you clarifications! I will try to write a more in-depth reply
> later, but here are a few quick thoughts in case you're mulling over the
> spec as we speak.
>
> On 06/09/2011 06:18 PM, João Paulo Rechi Vita wrote:
>> On Wed, Jun 8, 2011 at 00:50, Christian Anderson <christian at avtok.com> wrote:
>>> On 06/04/2011 07:36 PM, João Paulo Rechi Vita wrote:

(...)

>>>
>>> Small questions:
>>> *Should PeerKeyReceived broadcast the type of the received key? Did you
>>> decide not to have d-bus objects corresponding to the keys?
>> The type of the key can be determined from the fingerprint. For now
>> I'm leaving key handling/storage entirely for the client, out of dbus.
>> When I get to the client coding part I'll check how to store it, but I
>> personally would like to have this stored in a common secure place,
>> like seahorse (for gnome), where different clients could share it. But
>> it's still something to be better analysed, since it should be
>> WM-independent and I don't know if freedesktop.org says something
>> about key storage.
>
> According to the OTR spec, a fingerprint is just a "SHA-1 hash of the
> byte-level representation of the public key". There's no way to figure
> out the original key type from a hash value.
>

All right, just got confused with part that states that when using DSA
the leading zeros are omitted from the hash. Added the type argument
to that signal.

(...)

>>> *What happens if I call RequestSession while in the REQUEST_RECEIVED
>>> state and then realize I want to accept my peer's session request
>> Yep, rethinking it would be better to just ignore this method call on
>> REQUEST_RECEIVED, or return an error to the client.
>
> I'm not sure about that. I should be able to send OTR queries regardless
> of whether I have received them in the recent past. For instance, I
> might want to request different versions than the ones advertised by my
> peer.
>

The protocol description is not very precise at this point, but taking
both points you raised into consideration, it seems to me both peers
can keep exchanging OTR query messages until one of them decides to
give and either accept or reject the request from the other. So the
original RequestSession description was correct then.

>>> *What happens when I receive a session request while in the FINISHED state?
>>>
>> As stated in the protocol description, the only way to leave this
>> state is through an user action. So we should not automatically start
>> the AKE despite which policy is set. So we should act exactly like
>> when receiving it in the PLAINTEXT state without AutoAccept enabled.
> Maybe I'm confused. I thought that when we received an OTR query while
> in the PLAINTEXT state we transitioned to AKE_STARTED or
> REQUEST_RECEIVED depending on the value of the AutoAccept flag. My point
> was that it is unsafe to transition to REQUEST_RECEIVED from FINISHED.
>

They only difference is that in the FINISHED state the CM will not
honor AutoAccept.

-- 
João Paulo Rechi Vita
http://jprvita.wordpress.com/