private groupware objects
bernhard at intevation.de
Tue Sep 12 09:39:32 CEST 2006
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
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:
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1310 bytes
Desc: not available
More information about the format