RE: ebBP Implementation question - BPSS & CPA conflict regarding non-repudiation

["Dale Moberg" <dmoberg@us.axway.com>]

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]