[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. 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 ************************************************************************************* ---------------------- Forwarded by Martin W Sachs/Watson/IBM on 09/03/2001 01:56 AM --------------------------- Martin W Sachs 09/02/2001 01:46 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, 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