Re: nonrepudiation (signing messages)

[christopher ferris <chris.ferris@east.sun.com>]

Dale,

Please see below.

Cheers,

Chris

Dale Moberg wrote:
> 
> I think that adding the Reference will take care of the ambiguity
> of the penultimate TRP MSH version on the issue of what had been
> signed. I am not certain, though, that it completely
> solves the questions of 1. an alleged sender rejecting
> a receipt by saying that no such message was
> sent in the first place nor 2. the practical problem of
> coordinating reconcilation (unless some other basis
> for coordination (like messageid ) can be trusted
> as much as the  hash on the message sent that was
> signed for non repudiation of origin).
> 
> I think both those issues
> point to recommending that the same
> Reference element is to be used both within
> the originating parties Signature and within the Receiving
> parties receipt.

I think (though to be honest, I haven't read this recently) that
this is what is recommended. It may not have been clearly 
expressed, but this was certainly the intent (that the
Reference in the Ack is extracted from the Signature of
the original message being ack'ed).

As to the issue of an alleged sender disclaiming
having sent a message, they can do so only to the extent 
that they can prove that their private, used to sign the
message, had been compromised before the message was
received by the original recipient. That I believe is clearly
outside the scope of the TR&P specification as it gets into areas
of law and PKI that aren't within our purview.

> 
> Dale
> 
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> Sent: Wednesday, June 13, 2001 8:35 AM
> To: Dale Moberg
> Cc: Martin W Sachs; ebxml-cppa@lists.oasis-open.org;
> ebxml-tp@lists.ebxml.org
> Subject: Re: nonrepudiation (signing messages)
> 
> 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:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard