Dims, all, just looked at CanonicalizerBase and did a quick test. Unfortunatly it also handles CDATA in a wrong way - it handles CDATA like standard Text nodes, i.e. C14nBase converts all special chars into Entities and serialize CDATA as standard text without the "[!CDATA[....]]" sequence. I don't know if this is by purpose or a bug.
I haven't looked into the C14n specs if they require CDATA to be converted into Text befor Signature, that is all special character like <, >, etc. converted into Entities like < , > . IMO, for encryption serialization CDATA shall be serialized as CDATA element without Entity conversion. Otherwise it may give problems when we first sign that element, then encrypt it. In addition CDATA implies a "preserve space" behavior. Is that true for standard Text nodes too? The XMLSerializer of Xerces also deals with DOM 3 enhancements, does quite some processing with namespace and so on (I didn't understood it in every detail). I can't find this namespace handling at C14nBase. At all it is a quite heavyweight method/Class. Maybe we can extract it and move it over. Regards, Werner ----- Original Message ----- From: "Davanum Srinivas" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 03, 2004 7:57 PM Subject: Re: XMLCipher - enhancement for content encryption > 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/
