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

Joon Radley joon at radleys.co.za
Wed Aug 16 16:11:45 CEST 2006


Hi Martin,

So you propose a manual key management system. 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.

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

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.

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?

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.

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? The only answer I can think of is the reuse of the original symmetric
key and as anybody that did any work with encryption will tell you that the
reuse of symmetric keys is very bad security.

Best regards

Joon Radley
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joon at radleys.co.za
  

> -----Original Message-----
> From: kolab-format-bounces at kolab.org 
> [mailto:kolab-format-bounces at kolab.org] On Behalf Of Martin Konold
> Sent: Tuesday, August 15, 2006 8:54 PM
> To: kolab-format at kolab.org
> Subject: Re: enhanced XML Format for events (fixing 
> recurrances and allowforprivate events)
> 
> Am Dienstag, 15. August 2006 14:59 schrieb Joon Radley:
> 
> Hi Joon,
> 
> > > With the new enhanced format is can be more easily implemented.
> 
> > I have no problem with the introduced encryption format for 
> privacy, 
> > my issue is with the key management.
> 
> The basic idea is to introduce key management step by step.
> 
> 0. create the X509 certificate using an undefined tool like 
> openssl or windows tools. Mark this certificate exportable!
> 
> 1. store the key in the desktop certificate store. IIRC such 
> a certificate store is part of every windows installation. 
> Optionally you may choose to use your own store (e.g. the 
> filesystem). Using the windows OS certificate store will have 
> the advantage that stuff like smart cards will work out of 
> the box while using your own store will more easily allow to 
> share the certificate with everyone having access to the 
> cert. For access control Windows ACLs are well suited then.
> 
> 2. I propose to initially use the x509 certificate for 
> encryption/decryption only. The cert is initially only in the 
> certificate store and it is initially only used for 
> de-/encrypting private Kolab objects. The private object uses 
> the key id to uniquely define which key is required for decryption. 
> Potentially the eventlist might contain multiple copies of 
> the data encrypted with different keys.
> 
> 3. If the Kolab user wants to use several different clients 
> to access his private data it is initially the duty of the 
> user to export/import the certificate manually and to 
> transfer it by suitable means.
> 
> IMHO such a simple key management will already help many 
> people. The most paranoid want to use smartcards etc. while 
> the others might feel comfortable using a server and its ACLs 
> to store the certificates securely. As to which server 
> storage solutions are supported I am open for discussion.
> 
> a) use a fileserver with ACLs
> b) use https + ACLs on the Kolab server
> c) use imaps + ACLs on the Kolab server
> d) use ldaps + ACLs on the Kolab server
> d) use smartcards
> 
> > Another fun issue will be to write an update utility for 
> existing data 
> > stores and in my case it is not only for Kolab.
> 
> Please elaborate the issue as I fail to understand the problem.
> 
> > > > > > 4. recurrances
> >
> > What do you want to do with this event-list tag, extend 
> recurrence or 
> > create a single object to multiple object mapping?
> >
> > Please ignore the other issues just concentrate on one 
> issue at a time.
> > Lets evaluate the proposal from a recurrence view point.
> 
> With the eventlist tag I want to provide a wrapper in order 
> to be syntactically able to store multiple event(-like) data 
> sets. These events then describe the exceptions in more 
> detail so that we can represent everything which is possible 
> with OL2K3 and possible OL12.
> 
> Regards,
> -- martin
> 
> --
> http://www.erfrakon.com/
> Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format




More information about the format mailing list