OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[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