Re: reliable messaging - hop by hop

[Martin W Sachs <mwsachs@us.ibm.com>]

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
*************************************************************************************



Dan Weinreb <dlw@exceloncorp.com> on 08/29/2001 02:53:15 PM

Please respond to Dan Weinreb <dlw@exceloncorp.com>

To:   david@drummondgroup.com
cc:   chris.ferris@east.sun.com, ebxml-cppa@lists.oasis-open.org,
      ebxml-msg@lists.oasis-open.org
Subject:  Re: reliable messaging - hop by hop



   Date: Wed, 29 Aug 2001 10:51:43 -0500
   From: David Fischer <david@drummondgroup.com>

           If there is no change then the message arrived and did not
change.
   There is no application process here.  If this is application specific
then so
   is the signature process.

I think that's exactly what Chris was getting at.  The meaning of
"arrived" is that it got as far as the entity that has access to the
private key.  The question is whether the sender should interpret
that to mean "it got to the To Party MSH" or "it got to the To Party
application".

MWS:  This is another example of why we need to clearly articulate, in
the spec, what reliable messaging claims to do and what assumptions are
made on the implementation. In the above case, the statement means that
once an incoming message is placed in the persisting store, it is assumed
that the implementation guarantees to present the message to the
application.
Of course, see the next paragraph.

One concrete question: suppose the message is delivered to the To
Party MSH at time T1, and gets stored persistently in the To Party
MSH's queue of received messages.  Then, at a later time T2, the
message's time-to-live expires.  Then, at a later time T3, a To Party
application application requests an incoming message, and the MSH
replies that there isn't any message.  Under these circumstances,
is it right for the From Party to have a signed NRR?

MWS:  This is one of the really sticky points about time-to-live. One
possibility is that once the application is made aware of the presence
of a given message in the persistent store, that message shall not be
deleted except by the application.  If the signed NRR is returned only
when the To application is made aware of the message, that should take
care of this problem except that it then isn't clear what the value of
time-to-live is.

   NRR is analogous to pasting a PO Registered receipt on the outside of a
package
   and having the other end sign.  It is slightly better because it ensures
that
   the original contents have not changed.  This has nothing to do with
application
   processing.

In the analogy, the important question is: what good does it do the
sender to have the signed registered-mail receipt?  What can I, the
sender, do with that receipt?  What assertion about the real world am
I trying to prove when I brandish the receipt in front of the judge
during the trial?

Legally, "non-repudiation" traditionally refers to the signing of a
document: the alleged signer may want to repudiate the signature,
claiming that it is a forgery or was made under undue influence.  So
when the To Party performs the digital signature operation that
creates the NRR, what does that mean legally?  In particular, does it
mean "I promise that I took a look at this message"?  If so, is it
useful for a From Party to be able to assert that the To Party took a
look at his message, even though the To Party might not have done
anything about the message?

In 1998, the Australian Federal Government's Electronic Commerce
Expert Group adopted a technical meaning in its report to the
Australian Federal Attorney General, by defining "Non-repudiation" as
follows:

          Non-repudiation is a property achieved through cryptographic
methods which prevents an individual or entity
          from denying having performed a particular action related to data
(such as mechanisms for non-rejection or
          authority (origin); for proof of obligation, intent, or
commitment; or for proof of ownership).

RFC2459 uses this language:

     ...when the subject public key is used to verify digital
     signatures used to provide a non-repudiation service which
     protects against the signing entity falsely denying some action...

In both cases, what "action" are we talking about?  This is what
defines the real semantics of the NRR.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>