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. 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
begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature