[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
David and Chris, David's characterization of NRR seems to be exclusively focused on non-repudiation of message receipt by an MSH. I wanted to suggest an alternative: non-repudiation of business payload receipt by a "business application". Giving the app access to the entire message is sufficient for that purpose, but I don't know that it's necessary. Tony ----- Original Message ----- From: "Christopher Ferris" <chris.ferris@sun.com> To: "David Fischer" <david@drummondgroup.com> Cc: "Tony Weida" <rweida@hotmail.com>; "CPPA" <ebxml-cppa@lists.oasis-open.org> Sent: Monday, October 22, 2001 9:39 AM Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001 > David, > > Again, you are making an assumption that the "application" > or more specifically the NRR function doesn't have access > to the unadulterated message contents. I think that this is > a false assumption. The specification makes no claims whatsoever > as to what the "application" gets, nor what form that should > take. > > You also say: > > > <<Not a problem! The Application may pass anything it wishes to the MSH.>> > > > I would respond that the MSH may pass anything to the "application" > that it wishes. We say nothing about the implementation of > the software stack that manifests itself as an MSH + "application" > nor should we, IMO. > > The MSH is an abstraction, not a technical specification for an > implementation. > > Cheers, > > Chris > David Fischer wrote: > > > Hi Tony, > > > > <<comments in-line>> > > > > Regards, > > > > David. > > > > -----Original Message----- > > From: Tony Weida [mailto:rweida@hotmail.com] > > Sent: Sunday, October 21, 2001 8:05 PM > > To: David Fischer; CPPA > > Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001 > > > > > > David, > > > > I've embedded a couple comments below, prefixed with my initials. > > > > Cheers, > > Tony > > > > ----- Original Message ----- > > From: David Fischer > > To: CPPA > > Sent: Sunday, October 21, 2001 6:32 PM > > Subject: RE: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001 > > > > > > Sorry I missed the meeting, it didn't make it onto my calendar. > > > > Comments: > > > > If end-to-end, signed Acknowledgment is requested, it provides NRR -- in the > > same way DeliveryReceipt does. NRR cannot be provided at the > > BPSS/Application level since MSH does not pass the entire message and thus > > the Application cannot generate the required Digest(s). > > > > TW: That seems like a strong statement. Signing the entire message is > > sufficient, but is it always necessary? I understand that messaging > > elements may convey information relevant for non-repudiation, e.g., a > > timestamp. Such information may also appear in a particular type of > > business payload. > > > > <<In order for NRR to work, it must EXACTLY match the original signature > > digests -- which includes the MSH headers. Since the Application doesn't have > > those headers, it cannot generate those digests. This does not mean that the > > Application might not do something similar with only the payload. Messaging > > does not stipulate what can be in the payload. If the Application wants to do > > something like sign/encrypt the payload prior to passing to the MSH, it can. > > However, this is not NRR. This is more like some subset of the original > > digests/ds:Signature, so the original signature will not match. In any case, > > the Application can do whatever it likes and the MSH will provide NRR, if a > > signed Acknowledgment is requested.>> > > > > > > Since the MSH does not do any application parsing, any Business Level > > receipts cannot be done at the MSH level. While the Application cannot do > > NRR, it can/must provide anything along the lines of "Message verified/being > > processed" (i.e. Delivery Receipt). The Application would pass this signal > > to the MSH with a flag which says "sign this". While it would not be > > illegal for the Application to send a signed/encrypted payload to the MSH > > (would this be S/MIME?), it is not within our model to do so. > > > > TW: I expect that some security-sensitive applications will call for > > transmitting encrypted content between authorized persons or applications, > > not just between their respective MSHs. The latter is more likely to > > compromise security, for example by exposing confidential information to > > unauthorized persons within an enterprise. > > > > <<Not a problem! The Application may pass anything it wishes to the MSH.>> > > > > An Acknowledgment can be requested separately from Reliable Messaging > > although the only difference is duplicateElimination. > > > > I think/agree that MSH signals should be returned synchronously for HTTP. > > This should be the default. Maybe we don't need a flag, just make this a > > requirement (Why would this ever be done asynchronously for HTTP?) I think > > I agree with Dale. This should match the transport method (sync for HTTP, > > async for SMTP) and should not change per message. > > > > Regards, > > > > David Fischer > > Drummond Group. > > > > -----Original Message----- > > From: Tony Weida [mailto:rweida@hotmail.com] > > Sent: Saturday, October 20, 2001 5:05 PM > > To: CPPA > > Subject: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001 > > > > > > Draft minutes of the October 18 teleconference are attached. Please send me > > any additions or corrections. > > > > Cheers, > > Tony Weida > > Independent CPPA Fan :-) > > > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC