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/

Reply via email to