[Fwd: Re: ebBP Implementation question - BPSS & CPA conflict regardingnon-repudiation]

["Monica J. Martin" <Monica.Martin@Sun.COM>]

This is part of the interchange that occurred last fall with Steve 
Capell of RedWahoo on the ebBP list.  Ian, given the discussion today, 
and armed with a more detailed summary from ebMS team, we can:

    * Discuss whether and issue exists, and
    * If an issue exists, decide how to address it, or
    * If a concern exists, decide what clarifying language would address.

Thanks.

--- Begin Message ---

• From: steve capell <steve.capell@redwahoo.com>
• To: 'Dale Moberg' <dmoberg@us.axway.com>,'OASIS ebXML CPPA TC' <ebxml-cppa@lists.oasis-open.org>
• Date: Thu, 24 Aug 2006 11:19:58 +1000

Hi Dale,

Thanks for your very detailed response.  An excellent analysis of NRR I
think. Should put it on a BLOG page :-)

In any case, I think the outcome is that there is a bit of uncertainty in
the interpretation of these QoS attributes.  However I don't think the
interpretation should be left only to the parties sharing a CPA so would
really like to see some clarification is future specs..

I can advise that these characteristics are still in the current version of
UMM from CEFACT and are, of course, in the ebBP specification.  To my mind,
this is where the meaning is defined.  The fact that they are in the CPA is
only a mechanism to allow party specific override - but the meaning and
interpretation of them is still from UMM and BPSS.  Therefore I really think
that the CPA specification should simply say that and not try to specify
message handler behaviour based on these attributes.  The CPA already has
the sender/receiverNonRepudiation elements in the DocExchange structure that
drives ebXML MSH behaviour.  If parties want signed ebXML MS technical
acknowledgements that that's where to specify it.  Not in the business
transaction characteristics.  

I do agree that IF the business transaction characteristics are set to
require the use of business signals then those signals should be explicitly
referenced in CPA CanSend/CanReceive elements and the corresponding
package/simple part elements.  

As you suggest, I will post this to the CPA comments list.

Thanks again for your response!

Kind Regards,

Steve Capell
Red Wahoo
www.redwahoo.com 
p: + 61 2 94383700
m:+ 61 410 437854
f:  + 61 2 94392738
 
This email message and any accompanying attachments may contain information
that is confidential and is subject to legal privilege. If you are not the
intended recipient, do not read, use, disseminate, distribute or copy this
message or attachments. If you have received this message in error, please
notify the sender immediately, and delete this message. Any views expressed
in this message are those of the individual sender, except where the sender
expressly, and with authority, states them to be the views of Red Wahoo Pty.
Ltd.
 
Before opening any attachments, please check them for viruses and defects.
We do not accept any liability for loss or damage which may arise from your
receipt of this e-mail.
 

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@us.axway.com] 
Sent: 24 August 2006 08:34
To: OASIS ebXML CPPA TC
Cc: ebXML BP; James Bryce Clark; Monica.Martin@Sun.COM; steve capell
Subject: RE: ebBP Implementation question - BPSS & CPA conflict regarding
non-repudiation

Here are some comments on the BSI and NRR issues raised by Steve Capell
over in the ebBP TC list.

First, here is how my IETF badgered brain understands NRR

Non-repudiation of receipt (NRR): A "legal event" that occurs when
            the original sender of an signed EDI/EC interchange has
            verified the signed receipt coming back from the receiver.
            The receipt contains data identifying the original message
            for which it is a receipt, including the message-ID and a
            cryptographic hash (MIC).  The original sender must retain
            suitable records providing evidence concerning the message
            content, its message-ID, and its hash value.  The original
            sender verifies that the retained hash value is the same as
            the digest of the original message, as reported in the
            signed receipt.  NRR is not considered a technical message,
            but instead is thought of as an outcome of possessing
            relevant evidence.

There are several ways in which messages have been defined to meet the
previous evidentiary requirements, including the signed MDNs of EDIINT,
the ESS message structures defined the IETF Security group, and RN and
BPSS signal messages containing a hash value of the original message.
Beyond syntactical differences, there has been a long history of
discussion of just what is required to "cryptographically bind the
receipt to the original". Security experts tend to insist on a hash
value (or perhaps the signed hash value) from the original message.
Other folks are more lax and just want "sufficient" identifying
information so that the receipt signer is saying definitely what message
has been received. 

The QOS attributes of BPSS referred to have a schema annotation of

<xsd:attribute 
name="isNonRepudiationReceiptRequired"
<xsd:documentation>Both parties agree to mutually verify receipt of a
Requesting Business Document and that the receipt is non-repudiable.
</xsd:documentation>

I believe these QOS attributes also are found in at least early versions
of the UMM. The CPA repeats these to allow an agreement modifying the
values in a BPSS instance, perhaps strengthening them or (more
controversially) weakening them to allow operation.

The intended target consumer of the CPA is at least the ebMS MSH.
However, a BSH (Sacha Schlegel's term) might also be an interested
consumer. 

As far as what the CPA says from the 2.0 edition,

The isNonRepudiationReceiptRequired attribute is a Boolean with possible
values of "true" and "false". If the value is "true" then the delivery
channel MUST specify that the Message is to be acknowledged by a
digitally signed Receipt Acknowledgment signal Message, signed using the
certificate of the Party that received the Message, that includes the
digest(s) of the payload(s) of the Message being acknowledged. The
SenderNonRepudiation element under DocExchange/ebXMLSenderBinding (see
Section 8.4.43) and the ReceiverNonRepudiation element under
DocExchange/ebXMLReceiverBinding (see Section 0) further describe
various parameters related to the implementation of non-repudiation of
receipt.

As far as ebMS 2.0 goes, we have:

4.1.4.2 Persistent Signed Receipt
An ebXML Message that has been digitally signed MAY be acknowledged with
an Acknowledgment Message that itself is digitally signed in the manner
described in the previous section. The Acknowledgment Message MUST
contain a [XMLDSIG] Reference element list consistent with those
contained in the [XMLDSIG] Signature element of the original message.

Note that the topic of non-repudiation is omitted here (and apparently
elsewhere in ebMS)

So when does an agreement specify to use a BSI style signal for NRR
evidentiary support?

The QOS attribute should be true and there should be an action binding
in the CPA for that message (especially if the syncReplyMode is "none"
"mshSignalsOnly" "signalsOnly" or "responseOnly"). If the mode is
"signalsAndResponse" I think that it would be reasonable to include the
BSI signal along with the response document. But a BSI signal for the
Response would need a separate entry and should probably be mentioned
somehow in the packaging description. Probably an interop profile for
all these combinations would be useful to nail down the issue of
commitments or lack of them. Originally we wanted the QOS parameters to
be potentially multiply implementable in CPA details...

When signals are agreed to, then the agreement to have a QOS of NRR
would be approximated by having a signed receipt. That of course would
be separately specified in
MessagingCharacteristics/@ackSignatureRequested.
Since the ack identifies (weakly) the message that is acked, the signed
ack (weakly) provides evidence for NRR. An explicit signed document
(such as EDIINT's MDN, ESS, or a RN or BPPS signal with a signal would
provide better evidence.)

So, the situation is that many users of MSH do not employ BSH signals at
all. Users checking NRR QOS get something from a signed ack. If BSH
signals are to be used, they should be explicitly agreed to in a CPA or
in a private configuration agreement.

Going forward, it might be advisable to add something to the CPA as a
warning on NRR support. I am gradually working up CPA enhancements and
fixes for a 3.0 committee draft; please post your preferences to the CPA
comment list for 3.0, and the TC will take up the issue. 

[I just noticed that the ebbp signal element provides the cryptographic
binding by providing (roughly) a sequence of ds:References that compose
the message. No overall hash value is provided so that a subparts
reordering could be done on the message and that reordered object would
still fit the ds:References information. But the situation is quite a
bit improved the the RNIF 2.0 NRR evidence and the binding is probably
better than the signed ack of ebMS 2.0]

--- End Message ---