MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ebxml-msg] WSI signatures propsal & impact on ebXML Messaging
My general question is about allowing intermediaries to add additional SOAP
headers intended for the ultimate destination without violating the
signature. ebXML Messaging 2.0 implementations would encounter an
immediate 'signature invalid' error in this case. We chose our specific
"sign everything but the signature itself and portions intended for
intermediaries" approach specifically to ensure such an error.
How would we ensure a 3.0 implementation does not silently ignore a similar
insertion? We can talk about somehow telling the application layers to
ignore unsigned sections but that involves a granularity of little interest
in general.
thanx,
doug
On 17-Mar-04 16:53, Dale Moberg wrote:
> First, the WSI BSP is not ratified yet.
>
> Second, if WSI were to prohibit WSS signatures using xmldsig enveloped
> signatures, ebXML users could fall back to the ebMS 2.0 signature
> mechanisms if they wanted to have enveloped signatures (that also
> included the current xpath filtering that allows intermediary added
> signatures). I think ensuring that this option is available depends on
> what we do in creating the ebMS 3.0 header definition.
>
> ebMS 3.0 users wishing to use _only_ the wsse:security header blocks in
> a wsi conforming manner may therefore not have precisely the same
> functionality as had existed in ebMS 2.0.
>
> But, theoretically, an ebMS 2.0 signature in an ebXML header could be
> combined with a future ebMS 3.0 approach that uses wsse:security header
> blocks (supposing someone invents a use case for that combination!) In
> other words, ebMS 3.0 could use wsse:security header blocks in a wsi
> conformant way, but also allow the ebMS 2.0 signature mode in its header
> when that functionality was desired. I think that an ebMS 2.0 style
> signature mode would typically fail for some cases where the
> wsse:security detached signature succeeds. So I suspect that users would
> opt for one rather than the other mechanism. But because ebMS header
> blocks containing signatures would fall under a wsi extension point, I
> don't think they would count as breaking any wsi conformance
> requirement.
>
> I think that whatever wsi consensus gets established for use of
> wsse:security header blocks can be satisfied by ebMS v 3.0. So it may
> not be possible to get all the requirements that are currently satisfied
> when using the ebMS 2.0 security approach also satisfied when using a
> wsi-conforming, wsse:security-using message. But I am not clear that I
> see why that would necessarily has to be a problem.
>
> Dale Moberg
>
>