OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


Pim:
 
inline <JD>


From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Wednesday, February 13, 2008 11:46 PM
To: Durand, Jacques R.; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] a bi-partisan proposal

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]