Re: XMLCipher - enhancement for content encryption

[Berin Lautenbach]

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