Werner, did you see org.apache.xml.security.c14n.implementations.CanonicalizerBase?
-- dims --- Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Werner, > > my 2 cents, let's (make a copy of XMLSerializer) or (write an equivalent) that can > be maintained > as part of xml-security (just like we have DOM2Writer in axis). also, i grepped for > XMLSerializer > and it seems to be used only in cipher code and some junit tests. so should be easy > to get rid > of > that dependency. > > If you ask me, i'd say please submit a patch with changes to XMLCipher that enables > the full > support of DocumentFragment with a custom serializer :) > > thanks, > dims > > --- Werner Dittmann <[EMAIL PROTECTED]> wrote: > > 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 > > > > > ===== > Davanum Srinivas - http://webservices.apache.org/~dims/ ===== Davanum Srinivas - http://webservices.apache.org/~dims/