Subject: Re: CAP: why do we need GENERATEUID?

From: [email-masked]
Date: Fri, 2 Nov 2001 11:38:07 -0500

John replied on 11/01/2001 05:36:53 PM:
> I believe we've been over this before (for example, in San Diego): you 
are 
> the only one who believes that the server will store the iCalendar 
objects 
> as opaque MIME blobs, which could be signed by the sender.

For the benefit of those that were not in the halls then (and for some who 
seem to misrecall details) I think I need to restate somethings for 
clarity sake:

CAP is NOT defining the internal architecture of the Calendar Store.  It 
defines how a CUA accesses the CS and saves/retrieves/modifys data in the 
CS. 
The data format is MIME (from the CUAs POV, NOT necessiarily the CS's POV!!). 
The CAP messages/commands/data/responses are in MIME streams.  As such, 
you need to consider MIME streams that are encrypted/signed.  (Unless you 
intend to prohibit signed/encrypted ATTACHments or richer DESCRIPTIONs, 
etc).

Just as IMAP and POP3 deal with MIME on-the-wire and they abstract out the 
'mail file'/'message store', we are doing the same in CAP.

>                                                            The rest of 
us 
> expect the data to be stored in a relational database.  The disconnect 
> reflects our respective implementation experience: Notes is a MIME 
store, 
> for flexibility; most other apps are built on databases, for 
performance.

Another correction: Notes is not a MIME store.  Notes is its own store 
that can also contain MIME data (preserving fidelity even).  The Notes dB 
architecture was designed and built back in 1984, predating the MIME RFCs 
by about 6 years. 

Back to the discussion: You can pick your own back end store but not all 
implementors (Lotus / IBM, Open Source projects, etc) will be using 
someone elses backend store for the data for assorted reasons (ie: $$$, 
flexibility, ROI, etc).  Just because the query language is SQL-like does 
not mean that the CS MUST be built on SQL... (or are you claiming that 
indirectly?)

Much like IMAP/POP3 can be implemented w/ANY backend (flatfile, Notes dB, 
Oracle, DB2, SQL, proprietary, etc), ALL implementations need to deal with 
data integrity (esp. in IMAP).  Perhaps Im just off base here but Ive yet 
to hear _why_??  It doesnt matter what backend choice you pick (Ill keep saying it 
untill I can grok otherwise).  What matters is that the CUA can reasonably 
expect to get back the equivalent data to what it put in.  If not, it will 
be impossible to have 'local CS' inside the CUA and keep it in sync w/the 
server CS data; the sync engine would just be thrashing.

> In any case, signing seems to have nothing to do with GENERATEUID; as 
far 
> as I can see, where the UIDs come from does not impact signing the 
> iCalendar objects.

Ok, Ill try to be as concise as I can w/o caffine yet.  If the CS 
automagically updates the entry that the CUA just put into the store (ie: 
to put a UID on the entry for the CUA) then it will blow any signatures on 
the entry.  Also, if the data is encrypted then the CS may not be able to 
decrypt and modify the data (signed or unsigned!). 

I firmly do expect users to encrypt their data and anyone who thinks otherwise is 
being an Ostrich about it.  The way that mail gets around this is that the 
only modifyable headers are the outer most ones and they are never 
encrypted/signed.  At one point (San Diego or Washington DC hall talk??) I 
think I finally convinced some folks that we needed to split out some 
modifyable info from the base iCalendar data and this is another good 
justification for that.  (Steve, you recall that talk??  You were going to 
revise CAP to reflect that last I read it...)

Taking a "Leave it for later" attitude towards signed/encrypted data is 
not an acceptable answer in this technical era.  Otherwise at CalConnect 7 
we will find 10 implementors doing 10 different things w/the data that 
prevent a heterogenous mixing of CUAs & CSs.  Then we will spend even more 
time trying to retro a fix on that wont be painless to those implementors 
that far along the development path.

Sigh, I dont like sounding like a broken record but I strongly think that 
some fundamental issues need to be addressed before the rest of the CAP 
house is built.  This GENERATEUID posting I found in the archives just 
triggered that impulse again. 

Bruce
Sidenote: I finally got my personal archive in sync w/the official archive 
and have copied in the missing postings from this past summer (about 16-17 
in all).  The updates should be available now for those that use it too.
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: "Graham Gilmore" <[email-masked]>
Date: Fri, 2 Nov 2001 12:04:49 -0500

----- Original Message -----
From: <[email-masked]>
To: "John Stracke" <[email-masked]>
Cc: <[email-masked]>
Sent: 02 November, 2001 11:38
Subject: Re: CAP: why do we need GENERATEUID?

> intend to prohibit signed/encrypted ATTACHments or richer
DESCRIPTIONs,

    If a CS must accept a signed/encrypted iCalendar that it can't read,
how can it reliably perform any CAP operations at all?  "I'd love to
retrieve that event for you, but you've encrypted all your data and I
can't find it.  Sorry."

> server CS data; the sync engine would just be thrashing.

    Mail services don't care about the content of messages; Calendaring
& Scheduling services most definitely DO.  How, otherwise, can a server
provide such features to users like searching a user's calendar for free
time, text-based searches, or even informing a user that they've been
invited by someone?

[the following quoted paragraphs have been re-ordered, for clarity of
argument]

> revise CAP to reflect that last I read it...)

    So you are saying you would want to move some data out of the
"content" portion into some kind of "header" that isn't encrypted?  What
kinds of data?  Where does one draw the line between meta-data and
actual content that should be protected?

> decrypt and modify the data (signed or unsigned!).

    I don't think the UID is particularly important or valuable; why
would you want to encrypt the UID as part of the content of your message
(assuming some data was moved out into some kind of header)?

    Graham

---

From: Doug Royer <[email-masked]>
Date: Fri, 02 Nov 2001 14:43:12 -0700

[email-masked] wrote:
> > I believe we've been over this before (for example, in San Diego): you are
> 
> > objects as opaque MIME blobs, which could be signed by the sender.
> 
> seem to misrecall details) I think I need to restate somethings for clarity
> sake:
> 

Which does NOT include MIME blobs and the storage of encrypted blobs.
I agree with John - this is out of scope for CAP and it has been for years.
You brought this up in San Diego, LA, Oslo, Chicago, Dallas, and
perhaps in Montreal. If not in person - by email.  I also
agree with john that the rest of the WS does not agree that CAP
should address that method of storage.

How would your CS implementation meet the minimum requirements
for VQUERY if the data is only stored encrypted? I submit that
only the implementation that you have proposed would have this
limitation. If you want to do this, if you can figure out how
to read the inside of an encrypted blob by a CS in order to
meet the minimum VQUERY CAP requirements - great - but it is not
a CAP requirement.

> The CAP messages/commands/data/responses are in MIME streams. 
> As such, you need to consider MIME streams that are encrypted/signed.  >(Unless you intend to prohibit signed/encrypted ATTACHments or richer 
> DESCRIPTIONs, etc).

Your CUA needs to worry about these, not the CS. Your CUA would get
an encrypted MIME blob, ask you for your password, and store the
iCalendar object via CAP into your CS. You CS does not want and
should never have your private key. Thus it MUST NOT store
encrypted blobs or it can not meet minimum the VQUERY requirements.

From my point of view you are arguing both sides of the argument.
On one hand you want encrypted MIME blobs in the CS, on the other
you will never place your private key on the CS (you and I agree
on this point - never give out your private key). A CS could NEVER
function as anything except a file system if it had to handle
MIME blobs - if that is all you want - use secure NFS.

> 'mail file'/'message store', we are doing the same in CAP.

Not true - not the same issue. At no point 'MUST' a IMAP or POP
server crack open an encrypted email to determine if you are busy.

> implementors (Lotus / IBM, Open Source projects, etc) will be using someone
> elses backend store for the data for assorted reasons (ie: $$$, flexibility,
> ROI, etc).  Just because the query language is SQL-like does not mean that
> the CS MUST be built on SQL... (or are you claiming that indirectly?)

That is true. However in order to meet SQL-MIN, the CS MUST BE able
to crack open the iCalendar object on the store. That was agreed
to by all parties (you included at the time).

> to  hear _why_??  It doesnt matter what backend choice you pick (Ill keep
> saying it untill I can grok otherwise).  What matters is that the CUA can
> reasonably expect to get back the equivalent data to what it put in.  If
> not, it will be impossible to have 'local CS' inside the CUA and keep it in
> sync w/the server CS data; the sync engine would just be thrashing.

We agree, and as storing of encrypted data on the CS is not a CAP
requirement, you can't expect to operate with other CS's if your
CUA expects to be able to do that.

> > In any case, signing seems to have nothing to do with GENERATEUID; as far
> automagically updates the entry that the CUA just put into the store
>(ie: to
> put a UID on the entry for the CUA) then it will blow any signatures on the
> entry.  Also, if the data is encrypted then the CS may not be able to

First, WRONG - the the UID must be in place PRIOR to the CUA
depositing the entry into the CAP server, otherwise it is an
invalid object.

Second, if that entry represents a VEVENT, and the UPDATE is
an RSVP reply, and you want your CS to interoperate with anyone else's,
CUA then the CS MUST BE able to allow ANY conforming CUA TO
modify the ATTENDEE entry in the CS to show their status- so much
for your stored sig. Which is why the rest of us are saying that's
not CAP.

> I firmly do expect users to encrypt their data and anyone who thinks
> otherwise is being an Ostrich about it. 

Yes - a CUA issue, not a CUA<->CS (CAP) issue. Feel free to decrypt,
verify, validate, authenticate, authorize any MIME object blob. But
as soon as you want to be able to issue CAP commands on that blob, 
you have to:
	(1) store it de-crypted.
    or  (2) store you private key on the CS. (never!).

So, copy, drag-n-drop, whatever the MIME blob to your CUA, it can
crack it open - then store the results in the CS.

> The way that mail gets around this
> is that the only modifyable headers are the outer most ones and they are
> never encrypted/signed. 

Yes, but in vCalendar - almost everything is up for change, that's
what the (at least) year long debate that resulted in iTIP REQUEST/REPLY
was all about. --> vCalendar objects change. Are you proposing
that we eliminate all changes to an entry once the ORGANIZER
submits the initial request? EVERYTHING could be changed, including
the ORGANIZER, SUBJECT, DTSTART, DTEND, ... <everything EXCEPT the UID>.

> At one point (San Diego or Washington DC hall
> talk??) I think I finally convinced some folks that we needed to split out
> some modifyable info from the base iCalendar data and this is another good

In DC we agreed that the transport method that we chose at that
time needed to be updated as it disallowed encrypted MIME objects
completely. We did not agree that CAP must allow for the storage
of encrypted objects. 

I recall this was a meeting in the hall with You, me, and Paul, with
Pat and Frank coming and going. It was never agreed on the WG list.
We mentioned in session that we had to re-do the transport and
separate the transport from the objects.

> Taking a "Leave it for later" attitude towards signed/encrypted data is not
> an acceptable answer in this technical era.  Otherwise at CalConnect 7 we
> will find 10 implementors doing 10 different things w/the data that prevent
> a heterogenous mixing of CUAs & CSs.  Then we will spend even more time
> trying to retro a fix on that wont be painless to those implementors that
> far along the development path.

iMIP supports encrypted MIME objects. CAP uses a secure TLS connection
to transport the information. It is a CUA implementation detail, not
a CAP issue. You can have a functional CS unless the CS can crack
open the object.

-Doug