RE: Persistent Signed Receipt - spec inconsistent

["Burdett, David" <david.burdett@commerceone.com>]

Dale

You said ...

>>Rather than slap a patch on what is here, it might be more
accurate to admit that a mechanism for non-repudiation 
of receipt is not specified in version 1.0, and leave
it at that.<<

I am inclined to agree with you. All I was trying to do was resolve two
things:
1. The suggestion that a digest value be included in the header for
non-repudiation purposes
2. The spec on Persistent Signed Receipt (section 12.3.2, lines 1768-73)
states: "The acknowledgment message MUST contain the set of ds:DigestValue
elements contained in the ds:Signature element of the original message
within the Acknowledgment element." If we don't do non-repudiation, then we
need to change this part of the spec as it is inconsistent.

What do other people think.

David

-----Original Message-----
From: Moberg, Dale [mailto:Dale_Moberg@stercomm.com]
Sent: Wednesday, April 11, 2001 9:27 AM
To: Burdett, David; ebXML Transport (E-mail)
Cc: 'dmoberg@columbus.rr.com'
Subject: RE: Persistent Signed Receipt - spec inconsistent


David

I am assuming that the goal here is to specify
how to implement something that might constitute
evidence for non-repudiation of receipt. The
generally agreed upon requirements are that:
1. the receiver sign the receipt.
2. the receipt contains some information that
allows both parties to determine what the receipt
is a receipt to. This is more fancily described
by saying the receipt contains some information
that cryptographically binds the receipt to the
message for which it is a receipt.

In EDIINT, RosettaNet, and ESS, a hash value over
the original "message" (or specified parts) has
been used to bind the receipt to the message.
Other describing information may also be supplied,
like a message-id. There
are a lot of complications, however, that arise for
how to specify precisely, for all cases, what is
the stream of bytes to be hashed over.

It is even worse when we try to do this for ebXML
TRP style messages because multiple signers over
differing parts of data need to be supported. Just
what are we supposed to be provided non-repudiation
of receipt for-- the SOAP envelope tree (suitably
transformed to factor out the changeable stuff),
the multipart/related body, one or more of the payloads,
or something else? The BP level concern will be for a receipt
for the payload, and it is problematic whether signing
with a private key of a MSH will suffice, for example.
The MSH to MSH handshake level could get by using
just the hash for the (transformed) SOAP envelope (and
descendants). None of these cases are distinguished
and treated yet.

I think, then, that the situation is worse than you
describe and at present we have not specified anything
that provides a suitable mechanism for non-repudiation
of receipt that could be expected to work interoperably.

Rather than slap a patch on what is here, it might be more
accurate to admit that a mechanism for non-repudiation 
of receipt is not specified in version 1.0, and leave
it at that. 

Dale Moberg

> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Tuesday, April 10, 2001 10:29 PM
> To: Moberg, Dale
> Cc: 'dmoberg@columbus.rr.com'; ebXML Transport (E-mail)
> Subject: RE: Persistent Signed Receipt - spec inconsistent
> 
> 
> Dale
> 
> See comments inline.
> 
> David
> PS I've copied the response to the transport list
> 
> -----Original Message-----
> From: Moberg, Dale [mailto:Dale_Moberg@stercomm.com]
> Sent: Tuesday, April 10, 2001 6:43 AM
> To: Burdett, David
> Cc: 'dmoberg@columbus.rr.com'
> Subject: RE: Persistent Signed Receipt - spec inconsistent
> 
> 
> Hi David,
> 
> I would like to comment on the question you raise
> here, but am uncertain about requirements. Could
> you clarify the following points:
> 
> 1. Is the mechanism in the Delivery Receipt to support
> only XMLDsig signatures? Or is it to apply to any
> style of signature?
> >>Right now there is a place holder in the spec changes I 
> wrote, that would
> allow one digest value to be carried and a description that 
> the content was
> defined by the Business Process Designer. This really needs 
> to be made more
> interoperable but we don't have time in this release.<<
> 
> 2. Has the principle been adopted that whatever digests
> are returned (in some form or other) must have been
> computed "on the other side(s)"?
> >>This is currently undefined<<
> 
> 3. Does "signing the message" have an agreed upon
> meaning in terms of the bits that must be hashed over
> or is the choice of Reference up to the sender
> completely as far as carrying out an operation of
> "signing the message"?
> >>I think we need to be precisely prescriptive about what is 
> signed in order
> to get ineroperability (this is what we did in IOTP). But 
> there is not the
> time to do this for this release.<<<
> 
> Thanks 
> Dale Moberg
> 
> 
> 
> 
> > -----Original Message-----
> > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > Sent: Sunday, April 08, 2001 3:21 PM
> > To: ebXML Transport (E-mail)
> > Subject: Persistent Signed Receipt - spec inconsistent
> > 
> > 
> > I've been working on including a DigestValue into a 
> > DeliveryReceipt and
> > spotted an inconsistency. In the security section (lines 
> > 1769-73) it says
> > ...
> > 
> > >>>An ebXML Message that has been digitally signed MAY be 
> > acknowledged with
> > a DeliveryReceipt acknowledgment message that itself is 
> > digitally signed in
> > the manner described in the previous section. The 
> > acknowledgment message
> > MUST contain the **set**t of ds:DigestValue elements 
> contained in the
> > ds:Signature element of the original message within the 
> Acknowledgment
> > element.<<
> > 
> > Including just the digest values doesn't work I think since 
> > a) there may be
> > multiple signatures, and b) you won't be able to work out 
> > which digest value
> > belongs to which references as the references aren't 
> > included. I propose
> > that either:
> > *	we include the complete signature (or list of 
> > signatures) from the
> > for the message for which a persistent signed receipt is 
> > being given, or
> > *	simplify this to a simple digest.
> > 
> > I propose we go for the latter and change lines 1769-73 as we 
> > do not have
> > time to do the former and the spec is currently inconsistent.
> > 
> > Thoughts?
> > 
> > David
> > 
> > Solution Strategy, Commerce One
> > 4400 Rosewood Drive, Pleasanton, CA 94588, USA
> > Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704; Pager: 
> > +1 (888) 936
> > 9599 
> > mailto:david.burdett@commerceone.com; Web: 
http://www.commerceone.com
> 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
>