Re: Questions on processing rules

At 08:51 7/25/2001, Takeshi Imamura wrote:
>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.

Your assessment is correct. If the encoding is something other than a single 
option (e.g., UTF-8), then we need a way of specifying it. Options include:
1. We've stated that applications can encode the data as they wish as a 
separate step. For instance, you would UTF-8 encode and encrypt 
<zip>ab234234</zip>. Some consider this leads to less interoperability and 
complexity, but the spec supports this type of application behavior.
2. We permit arbitrary encodings and include an attribute in CipherData that 
describes the encoding. This gives one more flexibility, but increases 
complexity (now we have a type and encoding) and potentially interop issues.

Are you recommending either of these options, or is there another alternative?


>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.

I don't understand. If, upon encryption, you are encrypted an "element' or 
'content', then the type attribute will reflect it, and the decryption will 
proceed accordingly. (I'm notoriously bad and understanding 'former' and 
latter' scenarios <smile/>. What would you propose as a fix? Maybe that 
would help me understand.)

>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.

I think the text in the spec is misleading by representing that a c14n 
element is different than a normal element. I propose we strike change the 
first sentence to:

>"if the applications wishes to encode or compress (or perform some other 
>serialization) on the data in an XML packaging format, the application needs"



--
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Friday, 27 July 2001 16:28:11 UTC