RE: Questions on processing rules

Regarding point 2, at the meeting it was agreed that replacement is not
mandatory when encrypting XML nodes or decrypting ciphertext containing
XML nodes.  This would mean an application could compress the string representation
of a node list before encryption and decompress just before decryption.
 As to how the Type attribute should be handled in this case, I'll ponder
that for a while.

Ed
-- Original Message --

>
>Hello,
>
>As I mentioned in my talk at the FTF meeting, I have a few questions on
the
>processing rules.  Let me ask them again.
>
>1. At Step 3.1 in Section 4.1 it is said, "If the data to be encrypted
is
>an [XML] element or [XML] element content, the octet sequence is an UTF-8
>encoded string representation of the element or its content respectively."
>It seems that this sentence means an XML element or XML element content
has
>to be always encoded using UTF-8.  If so, it is not allowed, for example,
>to encode an XML element using UTF-8 and then compress it using ZIP.
>However, I think it is very limiting.
>
>2. At Step 4.1 in Section 4.1 it is said, "If the data being encrypted
is
>an [XML] element or [XML] element content, the unencrypted data is removed
>and replaced with the new XML structure using the same encoding as its
>parent XML document."  Also at Step 4 in Section 4.2 it is said, "If it
is
>an EncryptedData structure and the Type is "Element" or "Content", then
>place the resulting characters in place of the EncryptedData element with
>the encoding of the parent XML document if necessary. "  According to these
>sentences, in the above encode-then-compress case, the former replacement
>is done because the data is an XML element while the latter one is not
done
>because the EncryptedData element never has the Type attribute with
>"Element" or "Content".  This shows operations in encryption and decryption
>are asymmetric, and I feel it is weird.
>
>3. In Section 4.3 it is said, "if the applications wishes to canonicalize
>(using [XML-C14N] or some other serialization) or encode/compress the data
>in an XML packaging format, the application needs to marshal the XML
>accordingly and identify the resulting type with optional the EncryptedData
>Type attribute."  It seems that this sentence means, for example, when
>canonicalizing an XML element using C14N, another type than "Element" has
>to be identified.  In this case, however, any problem will not occur even
>if the type "Element" is identified because the resulting octet sequence
>is
>also an XML element.  This shows that what the type "Element" (or
>"Content") represents is not clear.
>
>How do you feel?
>
>Thanks,
>Takeshi IMAMURA
>Tokyo Research Laboratory
>IBM Research
>imamu@jp.ibm.com
>
>
>

Received on Wednesday, 25 July 2001 10:52:12 UTC