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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] Issues 121 - 124 RM + SP Assertions


Marc,
 
thanks for the policy examples - they help a lot in understanding how WS-SP can be used to support RM to configure security. However, I think they also demonstrate that the current proposal requires an update in some key areas:
 
- Use of SSL/TLS: Although the current proposal refers to WS-SP which can be used to configure HTTPS for an RMD, I believe that it is necessary to add a dedicated section that provides (normative) advice how SSL/TLS should be used in the context of RM. Things to mention here are for example the relationship and proper management of SSL/TLS session lifetime and RM sequence lifetime (according to Gil's comments in http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00069.html), CreateSequence message format (I believe without and STR in the SSL/TLS case), need for two SSL connections in an asynchronous scenario etc.
 
- Composititon of WS-SP and RM policy assertions: The examples are a good starting point and should be used to include a more normative section on this issue, may be based on a (new) structure that separates transport and message security throughout the proposal in a more obvious way.
 
- Clarification of the requirement to add the STR in the body of the message: While rereading the proposal(s) again, I was wondering why the STR is actually defined as a child element of the CreateSequence instead of using it in the security header of the CreateSequence message. I believe the reason is that RM cannot rely on WSS (which probably does processing of the SOAP message first and then passes the data to the RM protocol) to understand the semantics of a sequence. In other words, WSS can only verify that the signature (using whatever token is referenced by the STR) is valid on a message-by-message basis, but cannot guarantee that message a (e.g. CreateSequence) used the same token than message B (using the sequence) to sign the body. If this is the reason (and may be there are more to mention), I think some language to explain this more explicitly in the proposal should be added as well.
 
- Faulting behaviour: The proposal should clarify how the RMD responds when it supports the STR but is not able to understand the (semantics of the) security token referenced by the STR (see http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00063.html)
 
A more general problem is the maturity of the current WS-SP spec draft since most discussion in SX is around WS-SP issues. To mitigate this issue, I recommend that the proposal specifies the referenced version of SP. I am wondering how other members in this TC feel on that? 
 
-- Martin
 
Martin Raepple
Platform Ecosystem Industry Standards
SAP AG
Dietmar-Hopp-Allee 16
69190 Walldorf, Germany
T  +49/6227/7-60365
F  +49/6227/78-44724
mailto: martin.raepple@sap.com
http://www.sap.com

From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Dienstag, 13. Juni 2006 01:28
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] Issues 121 - 124 RM + SP Assertions

All,

 

I’ve attached three examples of combining the RM assertion, including the proposed SequenceSTR assertion, with SP.

·         RMSC.xml – This shows the RM and SequenceSTR assertions with the SP assertions indicating that SecureConversation is to be used.

·         RMX509.xml - This shows the RM and SequenceSTR assertions with the SP assertions indicating that X.509 is to be used.

·         RMHttps.xml  - This shows the RM assertion with the SP assertion indicating HTTPS is to be used. Note there is no SequenceSTR assertion in this example as the STR would not be used. Also I included in the comments here an alternate HTTPS binding showing additional options that are currently being considered in the SX TC. I believe this supports Gil’s current proposal for issue 121.

 

Regards,

Marc g

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]