RE: reliable messaging - hop by hop

[David Fischer <david@drummondgroup.com>]

Dan,

This is all Non-Repudiation of Receipt (NRR) means -- that the receiving party
received the message and that it did not change.  NRR does not mean anything
else.  NRR is created by calculating a hash over the received bytes in exactly
the way the hash was calculated over the sent bytes when the Sender created a
signature.  NRR is effectively a reverse signature except that the hash is over
the original message, not the receipt.  When the Receiver signs a Receipt they
first create a hash over the orinal message creating a MIC putting it in the
receipt.  Then create and sign a hash over the receipt, including the MIC.  When
the original Sender receives this receipt, they check the MIC against thier own
calculation.  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.

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.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Wednesday, August 29, 2001 10:25 AM
To: chris.ferris@east.sun.com
Cc: ebxml-cppa@lists.oasis-open.org; ebxml-msg@lists.oasis-open.org
Subject: Re: reliable messaging - hop by hop


   Date: Wed, 29 Aug 2001 09:54:15 -0400
   From: christopher ferris <chris.ferris@east.sun.com>

   A NRR *may* not be meaningful in a legal sense unless it is
   signed by an authorized signer. The private key for the certificate
   that is authorized *may* not be available to the MSH for security
   reasons.

   This is why it is my strong belief that NRR is an "application"
   function.

I agree with you, but I think there is an additional argument that NRR
must be an "application" function, independent of the question of the
handling of the private keys.

If an NRR is not application-level, then presumably the NRR merely
means that the message reached the MSH of the To Party, i.e. that the
message was delivered into a persistent queue at the To Party, or
something like that.

If that's all that the NRR means, it seems to me that it's not
terribly useful.  Suppose party F sends a message to party T, and gets
back such an NRR.  Later there is a dispute, and F wants to "prove"
(introduce evidence that) T really did "receive" the message, and so
it introduces the signed NRR as evidence.  T replies that, well, yes,
the message did get into its MSH, but T never actually processed the
incoming message; it was just sitting there on the disk somewhere and
nobody ever actually looked at it.  In this way T can effectively
repudiate the message in spite of the existence of a signed NRR.
So the signed NRR really doesn't help F; he might as well not have
it at all.

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