private groupware objects

Bernhard Reiter bernhard at intevation.de
Tue Sep 12 09:39:32 CEST 2006


Hi All,
On Wednesday 06 September 2006 11:04, Martin Konold wrote:
> Am Mittwoch, 16. August 2006 12:27 schrieb Joon Radley:

> > > can you explain in more detail why the suggestions of
> > > http://kolab.org/pipermail/kolab-format/2006-February/000649.html
> > > are not feasable?
> >
> > It is the worse possible hack.
>
> I agree, lets drop the original proposal using multiple server side objects
> for a single client side object.

it still was the best concept I have seen given the boundary conditions.

> IMHO using partly encrypted xml is the best proposal. Doing the security on
> the client for _private_ data is imho a good practice.

I agree that doing the security on the client is good, thus encryption
is an option. But I am skeptical about dropping the email compatibility
and the idea of one object = one email. The partly encrypted XML calls
for trouble.
During the Ägypten projects (www.gnupg.org/aegypten, www.gnupg.org/aegypten2/)
I have seen the difficulties in implementing so called standards for email,
and it is very hard. I think you might underestimate the difficulties of PKI,
especiall X509 and the resulting usability problems.
For x509 this is a good read to get you an idea of the difficulties:
http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt

Given that the server already does access control of more or less protected 
objects, I still consider this a good idea.
If encryption for extra security is used, it should be to encrypt a full email
with standard S/MIME or OpenPGP (PGP/MIME).

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1310 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20060912/13c4b7e1/attachment.p7s>


More information about the format mailing list