[
https://issues.apache.org/jira/browse/WSS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910147#action_12910147
]
David Valeri commented on WSS-242:
----------------------------------
Yes. Good catch. That also means that the test case doesn't cover signing of
an encrypted key element. The resulting test case update is fairly trivial,
but let me know if you would like me to submit a new set of patches.
> Signing EncryptedData or EncryptedKey elements creates extraneous Id
> attributes
> -------------------------------------------------------------------------------
>
> 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: Colm O hEigeartaigh
> Fix For: 1.5.9, 1.6
>
> Attachments: WSS-242-1_5_x.patch, 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-unsubscr...@ws.apache.org
For additional commands, e-mail: wss4j-dev-h...@ws.apache.org
