Erwin, all, well, I didn't modify any code that is relevant for Signature. It may relevant for Signature if Signature code uses the XMLSerializer of Xerces (haven't checked that). However, I ran several test cases that also use Signature (I'm working on WSS4J that does Signature and encryption) and they showed no problems with the modified Xerces jar.
The modification inside Xerces only affect the serialization of DocumentFragment, other code parts are not touched and work as usual. If you use the current XMLCipher in Content mode then you can't encrypt arbitrary XML data, and there is _no_ Exception or any other indication that the data was not encrypted correctly. This is because currently only DocumentFragments consiting of Element and Text nodes are supported. The patch to XMLCipher no enables the full support of DocumentFragment, that is it can contain any Node type. But currently Xerces fails to serialize a Document Fragment. Xerces chokes on Comment, CDATA, PI (either ommits them completly or serialize them partially only) without any error indication. That's even worse as you now have corrupted encrypted data. How wrong? Good question :-). The encryption code as it stands now is not able to encrypt in Content mode as specified in XML Encryption, chapter 2.1.3. As stated in my previous posting, it is not possible to encrypt arbitrary content. The current code works ok for WSS4J that uses generated SOAP requests (at least for the test cases we have today), but it does not work for generic XML encryption according to XML Encryption specification. IMO, - the patch to Xerces is a real bug fix, it does not change any API or other behavior. - if we leave XMLCipher as it is now it can only be used in a restricted way (see above). However, we shall _not_ switch off content mode as this would render the encryption useless for e.g. WS Security. So, IMO we have two option: - leave it as it is now and state the restrictions - but this would cause question because, as you said, nobody reads this :-) - use the modified xerces, test the Signature with it to make sure its not broken and put a link (or the modified jar) into xmlsec distribution Another option would be to write an own serializer - but I'm not in favour to that. ----- Original Message ----- From: "Erwin van der Koogh" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 02, 2004 3:21 PM Subject: Re: XMLCipher - enhancement for content encryption > Hello Werner, > > > to test the content encryption of XMLCipher I modified the test case of > > XML encryption. The modifed test case showed some serious problems > > inside XMLCipher as well as in the Xerces XMLSerializer. > > Hmm.. not good. > > [snip..] > > link to bug report for lazy people: > > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25853> > > > The modified XMLCipher content encryption can be used only with > > the fixed Xerces code. > > Hmm.. ok. > > > The attachement contains the patch to the XMLCipher (that also > > contains some code cleanup). The relevant code that deals > > with DocumentFragment is near the end of the patch file. > > > > If necessary I can provide the a Xerces jar file that contains the > > fixed XMLSerializer. > > > > The questions is, how do we proceed here? > > I guess that depends on a few things.. > > - What are the Xerces guys planning on doing about it? > - How 'wrong' is what we are doing now. > - And how many people would be affected by this > - Would there be problems with the signature stuff with the new jar > - What happens if you use the API with a non-patched Xerces jar? > > My first priority is to the signature code. It's been solid for a while and > while it might not be the best API out there, it works. Encryption stuff is > beta and doesn't have nearly the same amount of users. > > What we have learned from the initial JDK1.4 stuff (when you had to put a > xerces.jar in endorsed) is that it is a support nightmare. No matter how > many times you put it in big bold all over the place, people would still > download the stuff, give it a shot without worrying about reading anything > and mailing "I get this and such exception, what's wrong". > > So if we can make a distribution which will do the same thing it does right > now and your patch only makes it work without breaking anything at the > moment I think that's pretty acceptable. If it breaks encryption only in > some way I think we should have to sit down and have a discussion. If it > breaks the signature stuff I think it would be wise to think about it long > and hard, wait what the Xerces guys come up with and then discuss it some > more :) > > If you have some more info, let me know, > > Erwin
