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: Nonrepudiation of receipt in CPA



Arvola,

I agree that we have a certificate problem with synchronous responses in
addition to the one with NonRepudiation. I  believe that both of these
should be within the scope of V 1.1.

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/07/2001 12:17:54 PM

To:   Martin W Sachs/Watson/IBM@IBMUS, <ebxml-cppa@lists.oasis-open.org>
cc:
Subject:  Re: Nonrepudiation of receipt in CPA



Marty:

In a previous discussion, you have agreed that we have another
serious inconsistency:

http://lists.oasis-open.org/archives/ebxml-cppa/200108/msg00124.html

When synchronous response is required over a delivery channel,
we need to know the certificates used both by the sender and the
receiver. The existing scheme is insufficient, even with clear
documentation,
because it can only accommodate one certificate reference, not two
as required for the synchronous response case.

Regards,
-Arvola

-----Original Message-----
From: Martin W Sachs <mwsachs@us.ibm.com>
To: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
Date: Thursday, September 06, 2001 5:00 PM
Subject: Nonrepudiation of receipt in CPA


>After today's conference call, I realized that I should emphasize a point
>that I made a few weeks ago with an additional matter that I overlooked at
>the time.
>
>NRR is expressed in the CPA by the NonRepudiation element under
>ebXMLBinding in the delivery channel.  The delivery channel describes a
>Party's receive properties.  Nonrepudiation requires action by both
>parties.  However signing is done by the From Party.  So having it NRR in
>the delivery channel (receive properties) is a bit peculiar.  The points
>that I don't think I made previously are these:
>
>   Although NonRepudiation is in the delivery channel (receive
properties),
>   the certificate which must be referenced is for signing the message.
>   This certificate belongs to the From party, not the To party.  If we
>   leave NonRepudiation where it is, the text must make it clear that the
>   certificate is one belonging to the other party, not the party that
owns
>   this delivery channel.
>
>    Because the certificate belongs to the other party, the certificate
>   reference is meaningless in the CPP.  The text should state that the
>   certificate referenced in the CPP must be replaced  by a reference to
>   the other party's certificate when the CPA is composed.
>
>A better solution is to provide "send" delivery channels along with the
>"receive" delivery channels though this is probably out of scope for V1.1.
>
>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
>
***************************************************************************
**********
>
>
>----------------------------------------------------------------
>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