W3C home > Mailing lists > Public > xml-encryption@w3.org > July 2001

Questions on processing rules

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Wed, 25 Jul 2001 21:51:35 +0900
To: xml-encryption@w3.org
Message-ID: <OFBF87576C.CB17ED50-ON49256A94.003E9286@LocalDomain>

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 08:51:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:00 UTC