John Stracke wrote: > > 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. > > 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 > 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. 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. > 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 #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. 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 > 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. Just as with email. Clients just ignore them.
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