[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Bundling expectations on error conditions
|
We propose that even in the final case you
mention, that the message as a whole should fail and that no parts be
delivered. If, as you say, bundling is a mode of behavior of the bundling MSH,
then it can always fall back to sending each part to get the job done. From: Pim van der Eijk
[mailto:pvde@sonnenglanz.net] 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: 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]