[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: Re: ebBP Implementation question - BPSS & CPA conflict regardingnon-repudiation]
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 ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]