Erin, all, just an additional note:
C14N requires a well formed XML document as input (according to the specs). Content as defined by XML Encryption (and the referenced XML base specs) is not required to be well formed as it can be a DocumentFragment. If this understanding is correct, then we cannot serialize a DoucmentFragment directly but the Encryption code must deal with it (loop over the siblings and call serializeNode correctly). Regards, Werner ----- Original Message ----- From: "Werner Dittmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, January 04, 2004 11:05 AM Subject: Re: XMLCipher - enhancement for content encryption > 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 > > >
