GNOME Bugzilla – Bug 142358
XML decryption : Support namespace in deciphered content
Last modified: 2004-12-22 21:47:04 UTC
Problem : With xmlsec, decrypting content of type 'http://www.w3.org/2001/04/xmlenc#Content' or 'http://www.w3.org/2001/04/xmlenc#Element' does not work if the encrypted node uses any namespace that is not defined locally. Encrypting : <doc xmlns:ns="#mynamespace"> <ns:content/> </doc> to <doc xmlns:ns="#mynamespace"> <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element"> [....] </EncryptedData> </doc> can be done, but the decryption will always fail. The only current work-around is to redefine "ns" locally like this before encryting : <doc xmlns:ns="#mynamespace"> <ns:content xmlns:ns="#mynamespace"/> </doc> Desired behavior : No contraint should be present on the form of the encrypted content. It's very possible the document was signed before encryption, and the modification to include add the namespace would break the signature. A clean solution to this problem might be dependent on adding support in libxml to parse a string within the inherited context of a node. Some investigation could also be done to check if the support for namespace is enough, or if it is actually required to inherit entities (and/or other elements) to be able to interpret the fragment correctly.
Creating a related bug in libxml2 to be able to parse a string within a node context, and marking this blocked by this bug. If another solution can be found to do it, the dependance may go away.
Created attachment 31529 [details] [review] New function xmlParseInNodeContext might be used for patching this issue Libxml2 seens to have fixed this issue with version 2.6.12. The new fuction that could be use is called xmlParseInNodeContext. As a proof of concept I have rewritten xmlSecReplaceNodeBuffer using this new libxml function. Decryption of a simple example document works fine now. See the attached changes to xmltree.cc in the attachment. (I can also provide this as patch file if desired)
Nice looking simple patch. I hope Aleksey can review it ...
Yes, I have seen the patch, thanks! I am planning to integrate it but one of the users have problems with xmlParseInNodeContext() and I want to solve this issue first: http://www.aleksey.com/pipermail/xmlsec/2004/002167.html
Fixed: Checking in config.h.in; /cvs/gnome/xmlsec/config.h.in,v <-- config.h.in new revision: 1.19; previous revision: 1.18 done Checking in configure.in; /cvs/gnome/xmlsec/configure.in,v <-- configure.in new revision: 1.115; previous revision: 1.114 done Checking in include/xmlsec/private.h; /cvs/gnome/xmlsec/include/xmlsec/private.h,v <-- private.h new revision: 1.8; previous revision: 1.7 done Checking in src/xmltree.c; /cvs/gnome/xmlsec/src/xmltree.c,v <-- xmltree.c new revision: 1.39; previous revision: 1.38 done