Subject: CAP issue: CS does not preserve data integrity on multipart/signed

From: [email-masked] (Steve Mansour)
Date: Thu, 19 Jul 2001 10:31:29 -0700

- CS does not preserve data integrity on multipart/signed.

  Explanation/example:  someone can store a multipart/signed vEvent on
their
  own calendar via CAP but when the owner goes to read it back the sig
is
  gone (or its been 'resigned' by the CS).  For multipart/encrypted,
CS's may
  decrypt and later reencrypt data back but it data
security/preservation is
  not available.  A by-product of this is that when an invite arrives in
your
  calendar scheduling queue all you will be able to tell is that your
server
  says the data got there in some safe manner; no info as to the
original
  signature, etc.  As such anyone with a valid  signature can send the
  calendar owner  entries and the CAP server will say this was signed
and CAP
  verified it was".  In eMail you can see the senders signature
(somewhere in
  the UI); with CAP you have no visual way to see _WHO_ signed it.

  Another way to look at this is: you sign and save an entry.  Your AA
or
  someone else w/access to it comes in and modifies it. You later go
back and
  reopen the entry but you will  have no visual clue as to its been
changed
  by someone else since _I_ signed and saved it since my CAP server only
says
  "This was really signed when it was saved".  Is this OK?

At the risk of sounding like a broken record... again, I think it is a
good goal to try to solve this, but not for the first release of CAP.  I
think the lifetime of a VEVENT is very different from that of a mail
message. A when a mail message leaves the senders CUA, it arrives at a
recipient's inbox. Once there, the recipient may move it into different
folders or delete it or reply to it. But the sender never resends a mail
message that literally replaces the one they sent you earlier.  However,
when an Organizer sends you a VEVENT, it is very likely that it will
change over time -- it may get updated with Attendees partstat values,
the Organizer may change the time or location, etc. So it is common to
re-write and update a VEVENT.  For me, this fundamental difference makes
it much less clear how to store signed calendar events into a calstore
-- especially since the event will commonly be updated by admins and
potentially other people with write access to the vevent.

At the very least, I would say:

   * storing a vevent as a signed calendar, component, or parameter
     entity is going to be an edge case
   * to describe how this should be handled in CAP is going to very hard
     (at best) or next to impossible (my bet).

If someone has an enlightened idea on how to solve this problem --AND
you feel that it is something that MUST be done in the first version of
CAP, please speak up.

Otherwise, I propose that we acknowledge this is an issue with the first
version of CAP to be addressed at some point in the future, then move
on.

-Steve

---

From: John Stracke <[email-masked]>
Date: Fri, 20 Jul 2001 10:14:13 -0400

Steve Mansour wrote:

> Otherwise, I propose that we acknowledge this is an issue with the 
> first version of CAP to be addressed at some point in the future, then 
> move on.
>
I agree.

-- 
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"It takes a special kind of guy to rig an    |
[email-masked]|election and then lose." --Cecil Adams       |
\==============================================================/