[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Bundling expectations on error conditions
|
From: Pim van der Eijk
[mailto:pvde@sonnenglanz.net] 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 Pim From: 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]