enhanced XML Format for events (fixing recurrances and allowforprivate events)

[Martin Konold]

Am Mittwoch, 16. August 2006 16:11 schrieb Joon Radley:

Hi Joon,

> So you propose a manual key management system.

My proposal seperates the key management system from the encryption and the 
xml-format issues. 

Actually I initially want to solve the xml-format issue and do the encryption 
and PKI issues later.

> This is not user friendly 
> and will really limit the scope of people that can use it. Very few people
> actually know how to generate and manage keys.

Yes, I am fully aware of this. Fortunately this can be solved in multiple 
compatible ways in the future. 

My goal is to enable the privacy feature soon to those users with an urgent 
need while delivering the key management later.

Actually I am considering to make it possible to leverage on existing 
enterprise public key management infrastructures. Due to the fact that there 
are many different PKIs it must be possible to integrate easily with them.

I can even imagine that we integrate an optional PKI implementation with the 
Kolab Server in the future.

> So how will the encryption now work of the message? This is something you
> have omitted from your mail.

The encryption is done on the client. The client encrypts the private xml 
subtree using the users x509 certificate. In the _future_ we can consider to 
additionally encrypt the private date with the public key of a list 
of "shared users". Currently I only want to offer a genuine privacy feature.

> Traditionally the data is encrypted with a symmetric key and algorithm like
> DES 256, then the symmetric key is encrypted with the senders private
> key(RSA/DSA) and the recipients public key (X509) and attached to the data
> so that the recipient can decrypt the symmetric key with the senders public
> key and the recipients private key, then the message with the decrypted
> symmetric key.

Yes, I want to use traditional public key encryption.

> The first problem is private key management. The key is kept in some kind
> of ring system and the user needs to do some authentication to access the
> raw private key. Now the original calendar user will have to do this to
> read his own calendar entries. Will the user have to do the authentication
> with every mail downloaded and uploaded or do you propose to keep the
> unencrypted private key in memory for an extended period of time, which in
> itself is a security risk? Or do you propose to use the USB key management
> dongle to manage the private keys?

I propose for your Outlook plugin to leverage the Windows Security 
Infrastructure. 

see also: 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cryptography_functions.asp

The Windows OS offers a very clean way to integrate the handling of 
certificates from the point of view of a CTO. Using the native Windows OS 
implementation automatically provides integration with existing security 
devices like smartcards etc. without additional efforts. 

> The second problem is the actual encryption of the symmetric key. The
> clients will need to maintain a list of each user that can has access to
> the private part and encrypt the symmetric key for each user. The problem
> comes in when adding a user to the list and removing him from the list.
> Than means that every object in the mailbox will have to be deleted and
> re-encrypted with the new modified list. To further complicate this is that
> any policy change to the private list can only be facilitated when the
> original user logs in to do the re-encryption.

This is imho a solvable issue and initially we only want to support really 
private objects (I guess this covers about 95% of the use cases already).

I propose a seperate thread in order to discuss the detail of the imho 
uncommon case of "shared users" with read/write access to _private_ data.

> The third problem is modifications by the shared user that has rights to
> read and write private message. How would the shared user re-encrypt the
> new symmetric key as it does not have the original users privacy list or
> private key?

Why would this "shared user" need the original users private key? 

In general I want to postpone the discussion about shared users with 
read/write access to private events.

Joon: Do you know how Exchange handles this case? (I guess Exchange does not 
handle this use case at all)

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker