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: Summary of evaluation discussion of Sander's scenario for One-Way Push with Intermediaries


Sanders reviewed his proposal. We then began to review Pim’s discussion questions on the scenario.

 

Sanders scenario uses at least two WS-RM sessions, sender to intermediary and intermediary to receiver.

The intermediary would need to maintain a routing table.

 

The first focus of discussion was on security.

 

It is not yet known what WS-I will require for operation with WSS and WS-RM because the WS-I profile is not released.

 

Pim pointed out that if the WS-RM headers were signed over, then the original WSS signature would not validate because of the changed WS-RM information.

 

Dale wondered how much interest there would be if the sender’s signature could not be checked over the soap envelope’s body.

 

Sanders pointed out that possibly two signatures could be included in the WSS header or perhaps two WSS headers could be included.

 

Dale recalled that WS-I BSP contained Requirements constraining WSS headers (because interleaving encryption and signing does not work when multiple WSS header blocks are present). The more precise BSP statements involved the targets/actors of the headers. Possibly multiple headers could be included if they were appropriately targeted. Possibly also multiple signatures could be included in a single header block and then be edited to allow the sender signature to be propagated. While there may be some way to allow intermediary resigning, and sender WSS header block editing, that results in an end to end signature, the procedure would be considerably more complicated than that envisioned in the Core profile. It was agreed that the scenario would probably involve some modification to the core profile for senders and receivers. Whether security could be maintained should be checked by an implementation also because the procedure could be quite complex.

 

The upshot is that while the scenario might be OK for WS-RM, the security situation becomes quite a bit more complicated. The advantage of transparency on intermediary is that it tends to make security less difficult.

 

 



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