From bernhard at intevation.de Tue Aug 12 15:51:59 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 12 Aug 2008 15:51:59 +0200 Subject: "privat" Outlook objects Message-ID: <200808121552.03749.bernhard@intevation.de> Dear friends of the Kolab 2 Storage Format, recently I had a new idea about how to solve the problem of "privat" Outlook objects. My understanding of the problems is that it mainly exists with Outlook because the Outlook user interface shows a "private" setting. This setting will make a client not to show the contents of the object, though it recieves the full objects. Users are used to this behaviour. Outlook 2003 itself can also only fully deal with one main folder. For this main folder it maintains invitation emails, alarms and a four state freebusy information for local view. (Alarms can be activated on other folders by a special application.) A Kolab concept is it to have one ACL per folder, which I consider a good idea to keep ACL handling simple. In Kontact you just use two folders and use one to put the privat objects in. Kontact shows the "privat" setting as "sensitifity" which is comparable to a stamp on the paper envelope saying: "top secret", while placing the envelope in an iron safe would be access control. There have been several proposals on the list in the past how to solve this problem. Most had a few drawbacks to me. So here is my idea: If Outlook-plugins would be able to control the target folder of the sync depending on the flag's setting, we would invent folders with annotations like event.default.private or "event.defaultprivate". For each main folder there is only one "defaultprivate" folder, thus this is a fixed number. Outlook plugins could completly hide those folders from the tree view and place the objects into the corresponding main folder. So if an object has the private flag place it in the .defaultprivate folder and the other way round. The good side is that there is no change for Kontact or other clients: They can just display the *.defaultprivate folders and use their ACLs. If no X.defaultprivate folder exists, client MAY create one. The location is irrelevant, though I propose they SHALL use a subfolder of the mainfolder. INBOX - |-> Calendar - +> private What do you think? 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-format/attachments/20080812/7bde94ff/attachment.bin From martin.konold at erfrakon.de Tue Aug 19 12:13:29 2008 From: martin.konold at erfrakon.de (Martin Konold) Date: Tue, 19 Aug 2008 12:13:29 +0200 Subject: private Objects stored on a Kolab Server was: "privat" Outlook objects In-Reply-To: <200808121552.03749.bernhard@intevation.de> References: <200808121552.03749.bernhard@intevation.de> Message-ID: <200808191213.30100.martin.konold@erfrakon.de> Am Dienstag 12 August 2008 15:51:59 schrieb Bernhard Reiter: Hi Bernhard, I am back from vacations. > What do you think? We discussed this approach before. 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 - Inconsistency What about UI elements which act on a whole set of folders. E.g. allow access to a secretary e.g. - Security: private data is still available in plain text on the server. 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. Yours, -- martin P.S.: Please don't forget that private objects are not limited to calender entries. P.P.S.: With OL/Ex private objects can be seen only by the account owner, not by the delegates. -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstra?e 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/ From bernhard at intevation.de Tue Aug 26 10:45:07 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 26 Aug 2008 10:45:07 +0200 Subject: private Objects stored on a Kolab Server was: "privat" Outlook objects In-Reply-To: <200808191213.30100.martin.konold@erfrakon.de> References: <200808121552.03749.bernhard@intevation.de> <200808191213.30100.martin.konold@erfrakon.de> Message-ID: <200808261045.11627.bernhard@intevation.de> 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://kolab.org/pipermail/kolab-format/attachments/20080826/77bdfc59/smime.bin