[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]