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:]
Sent: donderdag 17 september 2009 23:18
To: Pim van der
Eijk;
Subject: RE: [ebxml-msg] Bundling
expectations on error conditions
From: Pim van
der Eijk [mailto:]
Sent: Thursday, September 17, 2009 2:10
PM
To: Moberg Dale;
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
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.
