[
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
