[jira] Issue Comment Edited: (CXF-2656) WS-SP signed elements assertion cannot be applied to portions of the signature in outbound processing

["David Valeri (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CXF-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007326#comment-13007326 ] 

David Valeri edited comment on CXF-2656 at 3/16/11 3:00 AM:
------------------------------------------------------------

Before creating a test case, I reviewed the WS-Security 1.1 X509 token profile to determine the applicability of this issue to a specification compliant implementation.  The original driver behind this issue was the need to include X509 tokens in the message signature.  Since the X509 token profile requires that a wsse:SecurityTokenReference is used in ds:KeyInfo and also specifies a limited number of mechanisms by which the wsse:SecurityTokenReference may reference/include an X509 token, the situation where an embedded X509 certificate is present as a descendant of ds:KeyInfo cannot arise.  Since the available reference mechanisms in the specification all rely on a token that is not embedded as part of the actual XML digital signature, the token can always be protected using the STR Dereference Transform or directly referenced from a ds:Reference when a wsse:BinarySecurityToken is embedded in the WS-Security header of the message.

As such, the original use case for this issue is handled by existing capabilities now that CXF-2655 is resolved.

I'm resolving the issue as "Not A Problem".

      was (Author: davaleri):
    Before creating a test case, I reviewed the WS-Security 1.1 X509 token profile to determine the applicability of this issue to a specification compliant implementation.  The original driver behind this issue was the need to include X509 tokens in the message signature.  Since the X509 token profile requires that a wsse:SecurityTokenReference is used in ds:KeyInfo and also specifies a limited number of mechanisms by which the wsse:SecurityTokenReference may reference/include an X509 token, the situation where an embedded X509 certificate is present as a descendant of ds:KeyInfo cannot arise.  Since the available reference mechanisms in the specification all rely on a token that is not embedded as part of the actual XML digital signature, the token can always be protected using the STR Dereference Transform or directly referenced from a ds:Reference when a wsse:BinarySecurityToken is embedded in the WS-Security header of the message.

As such, the original use case for this issue is handled by existing capabilities now that CXF-2655 is resolved.

I'm resolving the issues as "Not A Problem".
  
> WS-SP signed elements assertion cannot be applied to portions of the signature in outbound processing
> -----------------------------------------------------------------------------------------------------
>
>                 Key: CXF-2656
>                 URL: https://issues.apache.org/jira/browse/CXF-2656
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>    Affects Versions: 2.3.0
>            Reporter: David Valeri
>            Assignee: David Valeri
>             Fix For: NeedMoreInfo
>
>
> AsymetricBinding can't sign parts created by the WSS4J signature processing code.  Because AsymetricBinding calculates signature covered parts before creating/embedding the constructs of the WS-S signature into the SAAJ DOM, it cannot find things like the ws:KeyInfo to sign.
> Changing the order of operations is necessary to resolve this issue.  It would appear that WSS4J supports this capability any time after prepare has been called as it can accomplish this feat when using the build convenience method.
> Test case is pending.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira