private Objects stored on a Kolab Server was: "privat" Outlook objects

[Bernhard Reiter]

Hi Martin,

On Tuesday 19 August 2008 12:13, Martin Konold wrote:
> We discussed this approach before.

as far as I remember we had discussed using two objects parts,
one being public and one privat, which would reside in different folders.

My new proposal is to use one object, and only with Outlook place
it in "X.default" and "X.default.private" folders. 
To consider is if we make the .private one be below 
the corresponding .default one.
In an attempt to move forward 
I think we should give this a new round of discussions.

> The problems are:
>
> - Fragility:
>   Storage fragmentation is hidden from a users perspective. This can easily
>   lead to unexpected results e.g. if a folder or a single message is moved
>   or ACLs are  manipulated. It can easily happen that the result is
>   incoherent

I think this statement did apply to the old idea, but not the new one.
As there is one object, there is no real storage fragmentation.
Of course on Outlook the user would see one folder for two,
so a problem might arise when the default folder is moved,
but not when an object is moved, because it is one object.
The case that the default folder is moved seems something that we
could try to forbid by policy and is probably rare anyway.
Even then nothing bad would happen as the folder would keep
their ACLs.

> - Inconsistency
>   What about UI elements which act on a whole set of folders. E.g. allow
>   access to a secretary e.g.

I only propose this for the limited set of default folders on Outlook.
Plugins there can easiy make the properties dialog work on both folders.
UI which work on a bunch of folders get no additional difficulty.

> - Security:
>   private data is still available in plain text on the server.

I consider this a different - less severe - problem.
It is less severe because in larger organisation the administration will
also have control about the client machines, so getting the credentials
from the user will be another wide attack vector. 

> I therefore remain proposing a solution based on encryption which allows to
> be extended to be embedded in other security infrastructures like
> Smartcards, Certificate authorities, PGP Keyrings,....
>
> If you want I can reiterate my proposal again.

I do not think it is necessary to repeat it. 
Speaking out of experience with implementing an advanced crypto solution,
I still believe that this is a step which is beyond what we would be able to 
currently achieve.

Attacking the private data problem, I would therefore also explore other 
approaches like making it easier to keep several accounts on different 
servers. Then you can just put your private data on your own server, which
helps a bit.

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1603 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20080826/77bdfc59/attachment.p7s>