ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ebxml-msg] a bi-partisan proposal
- From: "Durand, Jacques R." <JDurand@us.fujitsu.com>
- To: "Pim van der Eijk" <pvde@sonnenglanz.net>, <ebxml-msg@lists.oasis-open.org>
- Date: Fri, 15 Feb 2008 16:01:05 -0800
Pim:
inline <JD>
Hello Jacques,
Sorry I missed last night's call. Some comments
inline.
From: Durand, Jacques R.
[mailto:JDurand@us.fujitsu.com]
Sent: 13 February 2008
20:49
To: Pim van der Eijk;
ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] a bi-partisan
proposal
....
So
for (b1), there is a choice:
- use WS-RM but with an RM sequence bridging technique (no
end-to-end RM sequence, due to routing issues for RM
signals)
- use WS-Reliability with simply end-to-end RM sequences
(no routing problem). Advantage: the intermediary has nothing to do except
routing!
For (b2), WS-Reliability wouldn't help. Some RM sequence
bridging technique would be needed regardless of which RM spec is
used.
I thought it
could help if the group/sequence size is limited to one (i.e. effectively going
back to ebMS 2.0 style message acknowledgments).
<JD> ah right.
This is always an option with WS-Reliability. But in general, sequence numbers
are preferable: allow for better scalability, faster dup check, less persistence
overhead.</JD>
....
Wouldn't what you suggest (the outermost int-to-int
security layer) amount to using some transient security like SSL provides? Also
the ebMS header can't be encrypted all the way if you need it for
routing.
I was thinking of three levels of
security:
1: HTTP transport security between any pair of
nodes. SSL/TLS fits here.
2: SOAP message security across SOAP (non-ebMS
intermediary) nodes.
3: End-to-end security between "true" sender (ebMS
MSH) and ultimate recipient (ebMS MSH) across ebMS
intermediaries.
In an environment where there are no SOAP nodes other
than the ebMS nodes, you are right that (1) and (2) are the same and the ebMS
endpoint connects directly to either an ebMS intermediary or another endpoint.
But if there are SOAP nodes in between the ebMS endpoint and the ebMS
intermediary, then it makes sense to protect the WS-A and WS-RM/WS-R headers
too. At least, I guess that is the reason why a reliable secure profile
would want to protect those headers.
<JD> indeed when present the wsa headers must be
included in the signature, per RSP profile. An MSH that adds wsa headers (not
required, but not prohibited) must sign them as well. If such headers are added
later on the way by an intermediary, and the message is already signed,
then RSP requires that IF some additional security is needed, THEN it must
include these headers .
</JD>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]