Brilliant :-)
The only other modification of the library I am using at the moment is
to parse reference lists correctly (at all?) during decryption.
For my application (OASIS WS-Security implementation), what ends up
happening with encryption is that you have an encrypted key in the SOAP
header using a reference list to indicate the encrypted data in the body
(probably not a common pattern free form encryption, but pretty much the
usage described in the recommendation
http://www.w3.org/TR/xmlenc-core/#sec-ReferenceList )
The current implementation appears to attempt parsing validation of the
URI references; it is definitely broken for lists of more than one
element, and fails to handle relative URIs (since they cant be parsed
without a base URI).
My fix just gives up on parsing (and actually walks the list ;) I
haven't attempted to handle child elements, but then neither does the
current version.
For the patch its probably easiest to look at my original message (it's
against 1.34 but there aren't may changes):
http://mail-archives.apache.org/mod_mbox/xml-security-dev/200502.mbox/[EMAIL
PROTECTED]
C
Sean Mullan wrote:
This seems like a good change, so I have made your suggested change
and it will appear in the 1.3 RC jar.
Thanks,
Sean
Clive Brettingham-Moore wrote:
Um, not wanting to sound like a broken record, since I have mentioned
this before, but is there even a remote chance that
XMLCipher.encryptData(Document, Element, boolean)
could be made public (as opposed to private) in 1.3; AFAICS there
should be no problem and if you need the other content mode it would
be nice not to have to build a modified library with each release
just to change the interface.
C
