Re: queries for unbounded recurring components

[John Stracke <francis@xxxxxxxx>]

Doug Royer wrote:

> Bruce_Kahn@iris.com wrote:
>
> > 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?
>
> 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.

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              |
|francis@ecal.com|indistinguishable from advanced technology.  |
\==============================================================/