You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by "David Valeri (JIRA)" <ji...@apache.org> on 2010/08/27 22:32:53 UTC
[jira] Updated: (WSS-242) Signing EncryptedData or EncryptedKey
elements creates duplicate ID elements
[ https://issues.apache.org/jira/browse/WSS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated WSS-242:
-----------------------------
Attachment: WSS-242-trunk.patch
Attaching the trunk patch.
With respect to the trunk:
Note that I patched the two instances of the setWsuId method that I know of. It is not clear if the one in SecBase is intended to become private or become deprecated. As this instance is still visible from subclasses, I made the change in both places to ensure any lingering usages got the update as well.
Moving the method to static as has been done in WSSecSignature does have the disadvantage that anyone wishing to override the default behavior cannot simply override the method as needed.
> Signing EncryptedData or EncryptedKey elements creates duplicate ID elements
> ----------------------------------------------------------------------------
>
> Key: WSS-242
> URL: https://issues.apache.org/jira/browse/WSS-242
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Core
> Affects Versions: 1.5.9
> Reporter: David Valeri
> Assignee: Ruchith Udayanga Fernando
> Fix For: 1.5.9, 1.6
>
> Attachments: WSS-242-trunk.patch
>
>
> If the action order on the outbound side is encrypt then sign and the signature parts include the XML Encryption elements by name and namespace, the signature action introduces a namespaced (wsu) Id attribute on the signed XML Encryption elements.
> <xenc:EncryptedData xmlns:xenc="..." Id="EncDataId-659" Type="http://www.w3.org/2001/04/xmlenc#Element">
> becomes
> <xenc:EncryptedData xmlns:wsu="..." xmlns:xenc="..." Id="EncDataId-659" Type="http://www.w3.org/2001/04/xmlenc#Element" wsu:Id="id-663">
> The signature is created with the reference to the wsu:Id attribute. The second attribute is not schema valid per the XML Encryption spec data structure [1]. As the XML Encryption spec already defines an Id attribute on the appropriate data structures, WSS4J should leverage this preexisting attribute when creating signatures that reference the primary structures from XML Encryption.
> As the XPointer definition requires that the attribute referenced is a schema defined ID [2], the preexisting Id attribute meets this requirement. While it could be considered a slippery slope to alter the signature code to accommodate the specific structure of arbitrary elements to be signed, the XML Encryption elements are well know structures and are deeply ingrained in WSS4J. Therefore, I feel that this change has a place in WSS4J. A more complete solution would include a pluggable strategy for allowing users to inject/reuse IDs on a per element basis; however, this issue and its patches are meant to resolve the immediate need related only to XML Encryption elements.
> [1] http://www.w3.org/TR/xmlenc-core/#sec-EncryptedType
> [2] http://www.w3.org/TR/2003/REC-xptr-framework-20030325/#shorthand
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org