OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ebxml-msg] Bundling expectations on error conditions

The proposal states that security is applied based on the settings of the primary unit.  So if the configuration for that unit states that SOAP headers including the eb3:Messaging header, the Body and all attachments are to be signed (set via Pmode[1].Security.X509.Sign, if my understanding of the purpose of that parameter is correct), then those elements must be ds:referenced in the signature and the signature must be valid.  If the signature is not valid, then the entire message fails and no parts must be delivered.  If the hash for a particular MIME attachment with cid:id@suffix is not correct, then it is not relevant which eb3:UserMessage has a reference to that MIME part. No need to treat that case differently from an incorrect hash for the eb3:Messaging header. I don't think we are in disagreement here.
But if reliability and security pass, or are not present and not specified to be present, then the message may still have other errors (handled in the ebMS module, like the value of AgreementRef as an example) in some units and not in others.  In that case, the current draft says that the correct units should still be delivered, just as if the units were sent in separate messages, and that eb3:Errors are to be generated for the incorrect parts. 

From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: donderdag 17 september 2009 23:18
To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Bundling expectations on error conditions



From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Thursday, September 17, 2009 2:10 PM
To: Moberg Dale; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Bundling expectations on error conditions


The ebMS3 Core specification states the order or processing (incoming, reverse for outgoing):  Transport, then WSS module, Reliability Binding, ebMS packaging. Figure 7 of ebMS Core Spec.  During the ebMS 3 public review (two years ago) I asked about order of header processing and that figure was what I was referred to. Nothing new.


OK, forgot that we stated that.


An ebMS3 compliant message may already contain multiple payloads.  There was never any concern about which payload caused the error. This extension is just an extension to this concept, signing additional payloads using the security of the primary message, as if the primary message had included those parts. IMHO any errors in bundling do not need to satisy an additional detailed reporting requirements that are not in the core spec.


I don’t quite understand that. The principle you referred to said that each message was treated as if it were the only message. Now the principle is that there is a root message and subordinate ones.


The point is that with the signature over all of them, we cannot tell which one is problematic. Therefore, it would be a security violation to try to pass on any of them. So they should all fail. Please consider this point





From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: donderdag 17 september 2009 19:39
To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Bundling expectations on error conditions



This security header contains a single ds:Signature element containing multiple ds:Reference elements for all payload parts, if payload signing is specified, and any payload parts brought in via secondary message units will be treated in the same way as parts that came with the primary message unit.


Reliability processing and regular WS-Security processing are the same for a bundled message as for an message with just a single message unit. They succeed or fail atomically. Only if both succeed do we get to the ebMS module that knows about bundling. There we do have a question about what to do with multiple ebMS errors (errors in the ebMS module), e.g. one message unit references via AgreementRef an Agreement that has expired, and the other units have no problems.  The current version of the spec is based on the following assumption (3.5.1):


Comment: we cannot actually make any assumption about the order of header processing unless we want to specify something. (SOAP generally does not say much about header process ordering, but does I think allow header specifiers to say something.)


Another observation: The change to signature over all parts means that we won’t necessarily be able to say what part creates an error with signature. That is, the signature verification process produces a single hash value (16, 32 or some longer sequence of bytes), and this value is matched against what the signing party computed. That does not show which part fails. Now you might sometimes be able to guess, from a ds:Reference hash check mismatch, that the problem is with a specific part. But all the ds:References might match, but the overall signature check fail (because of some permutation of order of parts, for example).



Therefore, because of the signature being over all parts, it seems false that:


 For the Producer and Consumer layers, the semantics of bundling is equivalent to sending and receiving a sequence of distinct messages


I will stop there and wait for additional clarifications.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]