Those two (decribed in the previous messages, diff as linked) are
basically the only mods we are using now - the encryptData method to
encrypt the body (content only, which was the problem), and the data
refs to point to the body element (just to make the decryption code a
little more general).
It's a very basic implementation, although for the messages are pretty
good WSSE our encoding end is only capable of the operations we actually
use (encrypt body & sign body) and the decoding end has hardwired key
resolution (well, delegated to host application).
Getting to the point; it's a bit of a hack so our coverage of the full
capabilites of the xmlsec library is incomplete, and I've mainly used
low level operations; but apart from the points mentioned the library
has been uniformly good (of course there was some fun related to
canonicalisation of newly created nodes for signing - namespace
declarations are normally created only on tree serialisation - but I
solved that by working around rather than patching - since it is a
tricky interplay between the document serialisation history and the DOM
implementation).
C
Werner Dittmann wrote:
Clive,
you just mentioned some enhancement you made for WS Security. Because
we use xml-sec libraryr in our Apache projetc WSS4J (WS Security for
Java) I would like to check if we can use you enhancmenets. Can
you provide some details about the mods you did?
Thanks.
Regards,
Werner
Clive Brettingham-Moore wrote:
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
