[Standards-JIG] JEP-0136: Message Archiving
Michael.Long at cornerstone.net
Fri Jan 20 16:32:43 UTC 2006
Tomasz Sterna said:
> There are AFAIR two concerns with server autoarchive:
> 1. Privacy issues.
> 2. Archiving e2e encrypted messages.
> Solution 1:
> Provide server with a public key for use when archiving.
> Only private key holder can read messages retrieved from archive.
I agree with this solution to issue 1. I think I offered the same (or very similar) solution in a previous post, although I did not state it as clearly or concisely. :-/
> Solution 2:
> Store e2e decryption key along with the conversation.
> Client can encrypt the key-storing message with a public key (solution
> 1) before storing in archive, to protect the decryption key itself.
This is the same conclusion to which I came (again, in a previous post).
Not being familiar with e2e, I looked up e2e ( RFC 3923 - http://www.ietf.org/rfc/rfc3923.txt ). I can't see any way for server-side autoarchiving to work with e2e messages, due to the lack of information available to the server (i.e., non-encrypted portion of the message).
I determined that for server-side autoarchiving to work (using the start/stop method previously discussed), the client would have to send a start message with the following information:
- with - the JID of the other side of the conversation
- start - the start time of the conversation
- subject - the subject of the conversation
- thread - the thread ID of the conversation
- key1 - the key with which the messages were encrypted
- key2 - the public key the server should use to encrypt the messages
The server would then use the 'with' and 'thread' values to determine which messages should be autoarchived. However, 'thread' is not available in e2e messages. Therefore, the server would have no way to determine which messages should belong to which archive. This could be a problem if the client is having simultaneous conversations 'with' the same JID. The archives would be incorrect (intermixed messages) because the server would not be able to differentiate between conversations. I don't know how significant an issue this may be.
Michael J. Long
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3516 bytes
Desc: not available
More information about the Standards