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.
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.
Pim
From: Moberg Dale [mailto:]
Sent: donderdag 17 september 2009 19:39
To: Pim van der
Eijk;
Subject: RE: [ebxml-msg] Bundling
expectations on error conditions
New:
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.
