RE: [ebxml-msg] a bi-partisan proposal

Pim:

 

inline <JD>

From: Pim van der Eijk 
[mailto:] 
Sent: Wednesday, February 13, 2008 
11:46 PM
To: Durand, Jacques R.; 

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:] 
Sent: 13 February 2008 
20:49
To: Pim van der Eijk; 

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>