Re: nonrepudiation (signing messages)

[Christopher Ferris <chris.ferris@east.sun.com>]

Dale,

In the last round of edits, this was accomodated
by providing for inclusion of the Reference element(s)
from the original signed message in the Acknowledgment
element.

By including the whole Reference element(s) the issue
of what was digested is removed.

HTH,

Chris

Dale Moberg wrote:
> 
> 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
> >
> ************************************************************************
> *************
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;One Network Drive;Burlington;Ma;01803-0903;USA
version:2.1
email;internet:chris.ferris@east.sun.com
title:Senior Staff Engineer
fn:Christopher Ferris
end:vcard