Subject: RE: queries for unbounded recurring components

From: [email-masked]
Date: Wed, 27 Oct 1999 13:35:45 -0400

Lisa wrote:
>It may be reasonable to limit the amount of expansion the server has to 
do, though. 
>It could be interesting to allow the client to request recurrance 
expansion for a range
>of dates, and for the server to be able to respond "no".  (Then the 
client just has to
>download the recurring items).  That flexibility on the server allows it 
to tune for the
>best performance, both CPU and on the wire.

Before I espouse my KISS mantra again, Id like to note that one monkey 
wrench that has not yet been considered in this discussion is the return 
of signed and/or encrypted data.  So far we have agreed that we have some 
design issues dealing with signed/encrypted data but we have not directly 
addressed 'em.  Not sure if that is because we expect our borrowed 
security types to do this for us or if we are being a collective 
ostrich...

Back to the wrench: If the data is signed then this could be blown if the 
CS returns only partial data (either because the client asked for only a 
partial set or becuase the CS restricted it for some reason like 
restricted expansion).  Also, since recurrance instances may not be 
explicitly signed (ie: "RRULE:FREQ=WEEKLY;BYDAY=MO") then extracting the 
full snapshot of the instance for 01-Nov-1999 would result in either 
incorrect or missing signatures.  This could be an argument for where 
signatures and encryption may not be usable in our C&S world as we 
currently expect it to be...

If the data is encrypted, then unless the CS has the key to crack open the 
data and return the expected chunks we have to deal with another serious 
architecture issue.  The same issues applies to the extracting a single 
instance from an encrypted chunk and then reencrypting it for the CU; just 
what do we expect the CS to realistically do?

Im tapped out now but I promise to get some free cycles before DC to 
devote to this.  Whatever solution we collectively come to, I hope it 
follows the KISS principle so that we dont build something big, obtuse and 
very unwieldy that we have to code up and live with for several years! The 
simplest designs usually last better than very complex ones (very 
paraphrased form Sir Arthur Conan Doyle).

Bruce
===========================================================================
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: Doug Royer <[email-masked]>
Date: Wed, 27 Oct 1999 11:41:40 -0700

> what do we expect the CS to realistically do?

If the CS does not have the key, it could not have returned ANY of the data.
And the CS would not know how to return any date ranges. So that will not
work.

It is against IETF policy (as I understand it) to hold a users key
on a server. So unless I misunderstand - that can not be an issue to
us (perhaps someone could implement a CS that did, but that is going
to be out of scope to CALSCH).

With that, we then must depend (IN CAP) on a secure line (TLS).

While transporting the object with iMIP, S/MIME would be used
and the model would have to be:

	sending CUA -> receiving MTA -> receiving MUA -> <move to> CUA -> CS.

Where the receiving MUA or perhaps the CUA did the S/MIME stuff
and put the clear text iCalendar object into the CS using CAP and TLS.
Then secure the heck out of your server.

-Doug

---

From: John Stracke <[email-masked]>
Date: Sat, 30 Oct 1999 11:06:55 -0400

> And the CS would not know how to return any date ranges. So that will not

For encrypted data, this is indeed a problem.  But, for *signed* data, Bruce's
objection still stands.  It ought to be possible for someone to submit an S/MIME
message with a text/calendar body, and have the CS store the whole message.  The
CS may or may not check the signature itself, but it can then send the signed
message down in response to queries, so that clients can check the signature if
they want--that way they can do end-to-end authentication, and not have to trust
the CS not to make things up.

If we do this, it raises a couple of further questions:

  1. Should the CS, instead of having to store the whole message, be allowed to
     strip out the text/calendar from the S/MIME, discarding the signature?
  2. If so, should the CS be able to tell the sending CUA not to bother sending
     S/MIME?
  3. Should the receiving CUA be able to specify that it doesn't want the
     signature?

On #1, I think the answer is yes; otherwise it'll be impossible to fit a CAP
server on top of an existing backend.  On #2, again, I think the answer is yes,
since it saves the CUA from wasting bandwidth and CPU time, and also tell the
user that the server can't store signed data.  On #3...probably yes, but I'm not
as sure about it; the savings are less (a CUA that doesn't verify signatures
doesn't spend much CPU time on ignoring them), and the complexity may not be
worth it.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Any sufficiently rigged demo is              |
[email-masked]|indistinguishable from advanced technology.  |
\==============================================================/

---

From: Doug Royer <[email-masked]>
Date: Sun, 31 Oct 1999 11:11:42 -0800

John Stracke wrote:
> But, for *signed* data, Bruce's
> objection still stands. 

Had he made it :-)

> It ought to be possible for someone to submit an S/MIME

True - assumes the CS does not change anything in the object- and it can
depending on the application.  So as long as it can strip out the
signature (your #1 below). 

If an ATTENDEE sends a RSVP yes, and the CUA or a bot updates the status
information - then the signature of the original object would have to
be tossed.

> ...
> On #2, again, I think the answer is yes,
> user that the server can't store signed data.

If the message arrived into an MUA (iMIP) and then dropped into a CUA - 
what good would it do, you have a signature anyway?

A CUA is responsible for formatting the object before sending it down
to a CS. If it does not like the bandwidth or speed of the connection
then that is a CUA issue - not a CAP issue as the CUA does not have
to send one down.

There is also no requirement that a CS support encryption or
digital signatures. So instead on saying you can't do it, maybe
there needs to be a capability saying a CS does sore signatures.
And if the capability is not present, then there is no way to tell.

> On #3...probably yes, but I'm not

Just as with email. Clients just ignore them.