[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: reliable messaging - hop by hop
+1 Dan Weinreb wrote: > > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC