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 <[email protected]> wrote: >> On 06/04/2011 07:36 PM, João Paulo Rechi Vita wrote: >>> When writing down the whole API I've realized that "in progress" >>> should actually be broke down into tree states: REQUEST_SENT, >>> REQUEST_RECEIVED, and AKE_STARTED. >>> >>> After finding my way through telepathy-spec XML syntax, I've managed >>> to write down whole API proposal and uploaded it at >>> >>> http://www.las.ic.unicamp.br/~jprvita/telepathy-spec-otr/spec/Connection_Interface_OTR.html >>> http://www.las.ic.unicamp.br/~jprvita/telepathy-spec-otr/spec/Channel_Interface_OTR.html >>> >>> I left key storage and peer authentication information storage >>> completely for the UI, that's why it doesn't appear on the proposal >>> above. >>> >>> I've also uploaded my sketch of the state machine, since it may help >>> following the spec: >>> http://www.las.ic.unicamp.br/~jprvita/telepathy-spec-otr/state_machine.jpg >>> >> Thanks for the concrete proposal! >> >> 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. >> *Why are Versions and RequireEncryption duplicated on the Connection and >> the Channel but the other properties are not? > These are the only properties I think should be allowed to have > different values for different channels on the same connection. OK, I'm not sure I understand the choice of these two properties in particular, but it's not a correctness issue. >> *I think you should specify the meaning of the boolean in the >> PeerAuthenticationConcluded signal. >> > Yes, I missed it. > >> I also have a number of questions related to handling "OTR overtures". >> There are 5 ways that a peer, implementing the OTR spec, might initiate >> communication with us: >> 1. A whitespace-tagged message. >> 2. An OTR error message. >> 3. An OTR query message. >> 4. A DH-commit message. >> 5. Version 1 key exchange message >> >> You have introduced the states REQUEST_SENT and REQUEST_RECEIVED to give >> the client the freedom of accepting and rejecting sessions on the fly. >> Is it worth the extra complexity? Why not just handle each of the 5 >> queries based on our channel's policies? As it stands, there are some >> issues arising from these two states. For instance: >> > This are only the states exposed to the client, so it knows what to do > when receiving a signal. I think it's necessary to add this ability to > the client to be able to honor the FINISHED state, as explained > bellow. > >> *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. >> *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. >> I think these states add unneeded complexity. I think they are logically >> problematic because it is quite possible for me to have both "SENT" and >> "RECEIVED" a request. >> > I think all of this situations can be worked out during the implementation. > >> What I imagine as an alternative is handling each of the 5 overtures >> based on the policy flags that are set in the associated connection. I >> am still not sure how each of the 5 overtures is handled depending on >> the 4 possibles values of (AutoStart | AutoAccept). Could you specify >> exactly what those two flags mean? >> > 1. A whitespace-tagged message. > > If AutoStart, starts the AKE and transition to AKE_STARTED. Otherwise > do nothing and stay on PLAINTEXT. > > 2. An OTR error message. > > If there is any version allowed (Versions is not empty), starts the > AKE. This is not explicitly exposed to the client. > > 3. An OTR query message. > > If AutoAccept, starts the AKE and transition to AKE_STARTED. Otherwise > do nothing unless instructed by the client to do so (calling > AcceptSession). > > 4. A DH-commit message. > 5. Version 1 key exchange message > > Usually the peer wouldn't start the AKE without requesting it first > (but IIRC is not prohibited by the protocol). In these cases the CM > should react as stated on the protocol description, depending on its > AKE state (since internally, there will be all the states from the > protocol description). All corner cases that could arise in this phase > are previewed there. > > Thanks for the feedback, I've updated the API description and will > upload to the same links. > christian _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
