RE: nonrepudiation (signing messages)

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Chris,

What is the status of nonrepudiation of receipt?

Just before Vienna, I recall there being an issue
about how non-repudiation of receipt was to work,
and in particular, how 
the participants knew what hash value over the original
message (parts) would be returned to indicate what
the receipt was a receipt for. 

Normally we think of nonrepudiation of receipt as
something the original sender could use in a dispute
with the receiver-- to establish that the receiver
had really received it. But it is possible that the
original sender might dispute that it had received
(a contractually required) receipt, not by denying
that the signature was by the receiver, nor by denying
that a receipt message had been sent, but by denying
that the value in the receipt was for any message
that had been sent by the originator! To guard against
this case, the receiver needs to be able, in effect,
to go back and establish non repudiation of origin
for the original sender's message. It then makes sense
to link the hash value used in the receipt
to that hash value contained within a signature of the
original sender. Then both sides have to admit that
the receipt was for a message actually sent by the
original sender. 

In any case, operationally speaking, the original sender
needs to be able to reconcile a receipt with the
original message it is a receipt for. To do this
reconciliation, it is extremely helpful if both
sides agree on what hash value is saved on the
originator's side to check against the hash value
returned in the receipt. Any unclarity here makes
the reconciliation process fuzzy. 

So I can see why Marty might want to nail down what 
transform is used for calculating the hash value
that performs the role of binding the receipt to
the original message, and supports unambiguous
reconcilation. I think that if there is any choice here,
a CPA might be needed to tie down what convention
is being used.

Dale Moberg


-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Wednesday, June 13, 2001 8:08 AM
To: Martin W Sachs
Cc: ebxml-cppa@lists.oasis-open.org; ebxml-tp@lists.ebxml.org
Subject: Re: nonrepudiation (signing messages)


Marty,

My take on this is that this element could take the form
of a Signature "template" which effectively provided
all of the requisite binding information including
reference URI(s) with only the Digest and actual
signature omitted. The IBM Alphaworks XSS4J DSig
implementation provides for use of a template
to drive the signing behavior, which is a nice
feature of the tool (IMHO).

I have successfully used the SignatureAlgorithm, HashFunction
and Protocol. I haven't used Certificate yet mostly
for implementation reasons.

Presently, the ebXML MS specification prescribes the
Transform algorithm(s) that MUST be used, as well as
the Reference URIs necessary for the header, but not the
payload item(s) since that would depend upon the Content-ID
or Content-Location URI which might vary from message to
message even of the same type. Thus, presently this is
not an issue. However, to make this more flexible, it might
be useful to have the ability to fully describe the Transform
as well.

Another approach would be to leverage the Reference element
from the DSig specification, omitting the DigestValue (like the
Signature "template" but without describing the full Signature.

Cheers,

Chris


Martin W Sachs wrote:
> 
> The NonRepudiation element specifies signing of the messages using
XMLDSIG.
> Its child elements are Protocol, HashFunction,  SignatureAlgorithm,
and
> Certificate.  I have recently been asked whether NonRepudiation also
has to
> have a Transform(s) element. If XMLDSIG provides a choice of
Transform,
> then the choice should probably be expressed under NonRepudiation.
> Alternatively, we might prescribe a particular answer in the text and
not
> need an element.
> 
> If something about transforms is needed in the specification, let's
put it
> on the list for the maintenance release.
> 
> 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
>
************************************************************************
*************