[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment
re-sending due to addressing error. ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* ---------------------- Forwarded by Martin W Sachs/Watson/IBM on 09/05/2001 02:40 AM --------------------------- Martin W Sachs 09/05/2001 02:05 AM To: "Arvola Chan" <arvola@tibco.com> cc: "christopher ferris" <chris.ferris@east.sun.com>, "Duane Nickull" <duane@xmlglobal.com>, <ebxml-msg@oasis-open.org>, <ebxml-cppa@oasis-open.org>, <ebtwg@lists.ebtwg.org> From: Martin W Sachs/Watson/IBM@IBMUS Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment (Document link: Martin W. Sachs) Arvola, Some comments below. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* "Arvola Chan" <arvola@tibco.com> on 09/04/2001 12:36:53 PM To: Martin W Sachs/Watson/IBM@IBMUS cc: "christopher ferris" <chris.ferris@east.sun.com>, "Duane Nickull" <duane@xmlglobal.com>, <ebxml-msg@oasis-open.org>, <ebxml-cppa@oasis-open.org>, <ebtwg@lists.ebtwg.org> Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment Marty: I agree with you that if the CPA template is missing communication endpoint information, then the missing information may have to be filled in by the parties through other configuration means before B2B exchange can take place. The sender must know the receiver's URL in order to send a message. The receiver, on the other hand, may not necessarily have to know the sender's return URL ahead of time. An implementation may want to provide this level of flexibility to improve scalability. For example, the ebXML registry grants read access to all clients. Why is it important for it to know a priori the communication URL of every client? MWS: I agree that if the Registry's (or any application's) interface requirement is that in a request, the client must provide a URL for the response message, then the client does not have to supply a return URL ahead of time. The existing Messaging Service spec allows for supplementing endpoint information that is missing from the CPA. Consider the Sender element (under TraceHeader) described in section 8.5.2.1 (line 990): 8.5.2.1.2 Location element 1001 This element contains the URL of the Sender's Message Service Handler. Unless there is another URL 1002 identified within the CPA or in MessageHeader (section 8.4.2), the recipient of the message uses the 1003 URL to send a message, when required that: 1004 · responds to an earlier message 1005 · acknowledges an earlier message 1006 · reports an error in an earlier message. 1007 This element seems usable by the sender to inform the receiver of its return URL, when the CPA installed at the receiver does not spell out the sender's communication URL. MWS: I believe that the element in question is intended for MSH to MSH communication. I don't see why it would not be able to be used in an application-level message to specify a destination application-level response message. However I would want to see that explicitly stated in the MS spec. I have made a similar suggestion regarding refToMessageId in application-level messages but I don't sense acceptance of this suggestion thus far. I am not advocating adding new elements to the message header at this point solely to enable a CPA template to be substituted for a complete CPA. However, I don't think we should remove mechanisms that are already in place in the message header (either in the PartyID under the From element, or in the Location under Sender in the TraceHeader element) to supplement information that may be missing from the CPA. MWS: I could accept this point but I would not want to see the practice used as a catch-all for eliminating information from the CPA that should be there. Regards, -Arvola -----Original Message----- From: Martin W Sachs <mwsachs@us.ibm.com> To: Arvola Chan <arvola@tibco.com> Cc: christopher ferris <chris.ferris@east.sun.com>; Duane Nickull <duane@xmlglobal.com>; ebxml-msg@oasis-open.org <ebxml-msg@oasis-open.org>; ebxml-cppa@oasis-open.org <ebxml-cppa@oasis-open.org>; ebtwg@lists.ebtwg.org <ebtwg@lists.ebtwg.org> Date: Sunday, September 02, 2001 10:12 PM Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment > >Arvola, > >As you state, a CPA template is missing information. Therefore it shall >not be used as the sole configuration information for a pair of trading >partners. If a CPA template is installed as configuration information, the >missing information must be filled in by each party (per agreement with the >other party) before B2B exchanges can begin. > >We must not add elements to the message header solely to enable a CPA >template to be substituted for a complete CPA. > >Regards, >Marty > > *************************************************************************** ********** > >Martin W. Sachs >IBM T. J. Watson Research Center >P. O. B. 704 >Yorktown Hts, NY 10598 >914-784-7287; IBM tie line 863-7287 >Notes address: Martin W Sachs/Watson/IBM >Internet address: mwsachs @ us.ibm.com > *************************************************************************** ********** > > > >Arvola Chan <arvola@tibco.com> on 08/30/2001 03:06:51 PM > >To: christopher ferris <chris.ferris@east.sun.com>, Duane Nickull > <duane@xmlglobal.com> >cc: ebxml-msg@oasis-open.org, ebxml-cppa@oasis-open.org, > ebtwg@lists.ebtwg.org >Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment > > > >Chris: > >When the Messaging Service is used in conjunction with some >CPA template, rather than a bilateral CPA, then endpoint >information may not be available and has to be explicitly >supplied in the message header. > >I would recommend that the To Party MSH not be obligated >to report security errors back to the From Party MSH. The >former should have the option of just logging the securty >error internally and then silently dropping the message. > >-Arvola > >-----Original Message----- >From: christopher ferris <chris.ferris@east.sun.com> >To: Duane Nickull <duane@xmlglobal.com> >Cc: Arvola Chan <arvola@tibco.com>; ebxml-msg@oasis-open.org ><ebxml-msg@oasis-open.org>; ebxml-cppa@oasis-open.org ><ebxml-cppa@oasis-open.org>; ebtwg@lists.ebtwg.org <ebtwg@lists.ebtwg.org> >Date: Thursday, August 30, 2001 11:48 AM >Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment > > >>Yes, I raised this issue in Brussels when we were considering >>inclusion of a responseTo and/or errorsTo URL in the message >>header. An attacker could potentially send a message that had >>an intentional error forcing the receiving MSH to respond to the >>URL in the errorsTo element. >> >>One of the reasons that a CPA (or an equivalent set of information) >>is so valuable is that the return address(es) are established by >>agreement. The return addresses can be vetted by both parties. >> >>Cheers, >> >>Chris >> >>Duane Nickull wrote: >>> >>> Arvola Chan wrote: >>> >>> > The BPSS spec says that nonRepudiationOfReceipt (NRR) is tied to the >>> > ReceiptAcknowledgement signal. NRR and reliable messaging are >orthogonal. A >>> > business process may specify the non repudiation of receipt for the >>> > requesting business activity business message and/or the repudiation >of >>> > receipt for the responding business activity business message, without >>> > requiring that reliable messaging be used. I think the Messaging >Service >>> > should not tie NRR to the DeliveryReceipt element if the latter is >used >>> > exclusively in reliable messaging.<SNIP> >>> >>> >>>>>>>> >>> >>> I want to bring up a security concern that came to mind reading all of >>> this. Is there any possibility that someone could place a cleverly >>> composed message with a ReceiptAcknowledgement signal required in return >>> to a multiple parties thereby starting a "Smurf" campaign. Many of you >>> who have been in the industry long enough probably remember the chaos >>> caused by smurf attacks back in the 90's. >>> >>> Just a thought to muse over ;-) >>> >>> Duane Nickull >>> >>> ---------------------------------------------------------------- >>> To subscribe or unsubscribe from this elist use the subscription >>> manager: <http://lists.ebtwg.org/ob/adm.pl> > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.ebtwg.org/ob/adm.pl> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC