Thanks for working on this! I'm just an Empathy user who would like e2e encryption, not an expert on anything. But I want to follow up on what Will said and throw some ideas out there that might have already been discussed out of band.
On 05/25/2011 02:24 PM, Will Thompson wrote: > I'm inclined to think the key storage should be outside the CMs. There > has to be UI for presenting keys to the user *anyway*. Plus, this allows > the cache to work across protocols, if the same key can be used by a > user for both their Jabber account and their MSN account, say. (Is this > done in OTR? Or maybe keys are tied to the account.) OTR keys can definitely be used between different accounts. I agree that the should be handled outside the CM. On a similar note, the proposed spec stores OTR policy in Connection.I.OTR, but I think it might make more sense to have the client specify an OTR policy when creating a channel. The policy can be stored at the channel level. Let me justify this more after I discuss policy. Your three policy flags are Enabled, AutoStart and AutoAccept. Why not directly support the policies from the OTR protocol [1]? These are currently: ALLOW_V1, ALLOW_V2, REQUIRE_ENCRYPTION, SEND_WHITESPACE_TAG, WHITESPACE_START_AKE, and ERROR_START_AKE. AutoStart could be implemented at channel creation time by setting the REQUIRE_ENCRYPTION flag on a channel if we have an OTR key stored for the handle we are connecting with. AutoAccept could be implemented by turning on ALLOW_V*, WHITESPACE_START_AKE, and ERROR_START_AKE. Your spec doesn't offer the functionality of SEND_WHITESPACE_TAG which is important to OTR. The advantage of implementing policy at the channel level is that a few things work more naturally: One of them is AutoStart. Another is that the user can click a lock icon to indicate that he wants his chat with Bob to be encrypted. This toggles the channel state to REQUIRE_ENCRYPTION but doesn't transmit any data to Bob. I have taken the spec from your previous email and updated it below to reflect this new way of implementing policy. I have also tried to expand on the methods and properties of the channel to include everything that I think the OTR protocol requires. Whereas your spec hides the details of OTR beneath the interface, the below draft takes the other extreme and reveals most of them. It's just a draft that appeals to me and might not reflect the wisdom of what you guys have come up with separately. I included support for the socialist millionaire protocol as present in OTR version 3 (everything labeled SMP). But this support can be taken out without damaging anything else. I've never worked with a D-bus before. Sorry for rookie mistakes. [1] http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html christian ==ofdT.Channel.Interface.OTR This interface is only applicable to channels of type Text. -Methods StartSession () -> nothing //Send an OTR query message on the channel EndSession () -> nothing HandleKey (b: Accept) -> nothing //Called in response to the KeyReceived signal //Lets the CM know if the key is accepted or rejected StartSMP () -> nothing AbortSMP () -> nothing -Signals MessageStateChanged (u: State, u: Reason) AuthenticationStateChanged (u: State, u: Reason) KeyReceived (o: Key) //Broadcast during AKE when we receive the public key SMPRequested () SMPConcluded (b: Success) -Properties Policy u(Policy_Flags) Read/Write Key o Read/Write //The key that we use to identify ourself on this channel. //Set by the client MessageState u(Message_State) Read only AuthenticationState u(Authentication_State) Read only SMPState u(SMP_State) Read only -Types Policy_Flags Flags u //ALLOW_V1, ALLOW_V2, REQUIRE_ENCRYPTION, //SEND_WHITESPACE_TAG, WHITESPACE_START_AKE, //ERROR_START_AKE Message_State Enum u //PLAINTEXT, ENCRYPTED, FINISHED Message_State_Reason Enum u Authentication_State Enum u //NONE, AWAITING_DHKEY, AWAITING_REVEALSIG //AWAITING_SIG, V1_SETUP Authentication_State_Reason Enum u SMP_State Enum u //EXPECT{1,2,3,4} _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
