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] 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
> 
> -----Original Message-----
> From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com] 
> Sent: Wednesday, March 17, 2004 6:39 AM
> To: ebxml-msg@lists.oasis-open.org
> Subject: [ebxml-msg] WSI signatures propsal & impact on ebXML Messaging
> Importance: Low
> 
> 
> TC members,
> 
>  
> 
>            I have been forwarded the following from people attending the
> WSI meeting this week about using detached signatures as part of their
> profile.   As the current version 2 specification uses enveloped
> signatures I would appreciate any comments from those of you that
> understand the issue better than I.  This decision will obviously affect
> any version 3 work that relates to security and WSI profile(s) these are
> items under consideration for inclusion.
> 
>  
> 
>           Please forward to any parties that may have a view on this
> issue.
> 
>  
> 
> From WSI meeting:
>  
> This is the relevant part from our Draft Profile
>  
> 
> 8.1 General Constraints on XML Signature
> 
> 
> 8.1.1 Use Detached Signatures
> 
> 
> Due to the nature of the SOAP processing model, which is based on
> recognising the elements that are children of soap:Header and/or
> soap:Body use of enveloping signatures, where the signed XML is
> encapsulated in a ds:Signature element, is inappropriate. Similarly, the
> definition of SOAP headers and body content will typically not
> anticipate the presence of ds:Signature as a child element, so enveloped
> signatures are also inappropriate. Consequently this profile mandates
> use of detached signatures.
> 
> R3102 XML Signatures in a MESSAGE MUST be Detached Signatures as defined
> by the XML Signature specification. 
> 
> Neither enveloping nor enveloped signatures are supported.
> 
>  
> 
>  
> 
> Ian Jones
> Chair OASIS ebXML Messaging Services TC
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/members/leave_workgroup.php.
> 


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