Berin, thanks for the info...it was not my intention to start another discussion on the CDATA matter :-).
Having looked at the XMLSerializer in Xerces and the underlying DOM Level 3 specifications I personally would prefer to go with the Xerces Serialization as the standard way: - it implements the latst DOM3 namespace normalization, that is it takes care of namespace inheritance and so on. That results in very good and compact serialized XML documents. Also it does not interfere with C14n (already tested to some degree). - it takes care to serialize CDATA sections as described in the DOM3 core document, e.g. XMLSerializer properly splits a CDATA if it contains a ]]> sequence. It also converts characters into an entity form (hex-presentation) if the are not part of the current encoding. The problem with the Xerces code is, that one internal method contained in BaseMarkupSerializer, doesn't treat DocumentFragment correctly. As stated, we may offer to use a C14n serialization too, but as an option. Regards, Werner ----- Original Message ----- From: "Berin Lautenbach" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, January 04, 2004 12:03 PM Subject: Re: XMLCipher - enhancement for content encryption > Werner, > > My understanding of a CDATA node is that there is no semantic difference > between it and any other form of character data (e.g. text node) - it is > purely a way of allowing authors of XML documents to easily write text > that would otherwise need to be escaped. > > However - all that aside, this is almost a mac vs. windows argument, and > has been carried out in many other places :>. > > If we head down the path of using the Xerces XMLSerialiser, we will need > to understand a bit more about its name space handling (not something I > have ever looked at). If it does anything strange with namespaces we > may have to implement a new serialiser or modifier the C14n serialisers > to handle this case. > > Cheers, > Berin > > Werner Dittmann wrote: > > > Erin, all, > > > > great that it is solved for Signature. But for Encryption I see another > > problem if CDATA is not serialized correctly. Consider the following > > DocumentFragment: > > > > <ns1:testNode xmlns:ns1="urn:uri:aNamespace"> > > > > Text inside node > > > > </ns1:testNode> > > > > <!-- This is a comment --> > > > > <![CDATA[Plain text with < and > ]]> > > > > It consists of an Element, a comment and a CDATA section > > (siblings). > > > > CDATA C14N for Signature works well because Signature does > > not modify the data exchanged between sender and receiver. The > > receiver gets the CDATA section. Only the verification converts it > > back (internally) into text to check the signature. > > > > If we serialize that fragment according to C14N > > we loose the information that "Plain text ..." was a CDATA > > section and not a simple Text node. When we now encrypt that, > > send it to somebody else and this somebody decrypts it we have > > lost this information even if the content of the CDATA section > > is maintained somehow. IMO, the receiver does not get the same > > data and semantic information that is contained in the source > > document. > > > > For generic Encryption we shall maintain the correct form of the > > source document as much as possible. Encryption shall not modify > > the data - just encrypt/decrypt it :-) > > > > It might happen that the receiver needs the information that some > > data was a CDATA section (we do not know what type of > > applications will use XML Encryption and how they deal > > with the XML documents). > > > > Only if the sender of the source document specifies C14N as the > > prefered method the we shall use that, because the usage of C14N is > > optional in the XML Encryption. > > > > Thus: > > - if nothing specified - serialize (including CDATA > > sections, comments, PI, ...) and encrypt > > - if some C14N is specified - use this serialization, then > > encrypt. > > > > To support this we have to enhance the XMLCipher API to > > support the specification of a serialization method > > > > Any thoughts, ideas? > > > > Regards, > > Werner > > > > > > ----- Original Message ----- > > From: "Berin Lautenbach" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, January 03, 2004 10:23 PM > > Subject: Re: XMLCipher - enhancement for content encryption > > > > > > > >>Werner Dittmann wrote: > >> > >> > >>>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? > >> > >>Having problems with network, and it distracted me. I meant to ask a > >>question on the first part. > >> > >>If we were to go down the canonicalisation path for serialisation, we > >>would loose CDATA sections as you quite rightly point out. This won't > >>be a problem for signatures, as they are removed anyway, but I'd be > >>interested in whether you see any other problems we might run into. > >> > >>Cheers, > >>Berin > >> > > > > > > > > >
