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

Re: Questions on processing rules

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Thu, 2 Aug 2001 23:05:01 +0900
To: "Joseph M. Reagle Jr." <reagle@w3.org>
Cc: xml-encryption@w3.org
Message-ID: <OFDEB300FB.E27BCB1E-ON49256A9C.0041D088@LocalDomain>


I'm sorry for delay.

>Your assessment is correct. If the encoding is something other than a
>option (e.g., UTF-8), then we need a way of specifying it. Options
>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
>describes the encoding. This gives one more flexibility, but increases
>complexity (now we have a type and encoding) and potentially interop
>Are you recommending either of these options, or is there another

I like 1.  As you wrote, it could lead to less interoperability, but I
believe that it should be solved by the Type attribute.

>>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
>To correct myself, I really shouldn't be saying, "applications can encode
>the data as they wish", it's rather confusing. They can ?represent? it
>however they want, but the final encoding will be UTF-8...

Is that because the final form is always XML?  I think that it is a little
limiting to always force applications to pack data into XML.

>I don't understand. If, upon encryption, you are encrypted an "element' or
>'content', then the type attribute will reflect it, and the decryption
>proceed accordingly.

I'm sorry to confuse you.  I mean, when encrypting an element in the
following steps: (1) encoding an element using UTF-8 and (2) compressing it
using ZIP (and not packing it into XML), I will have an <EncryptedData>
element as:

<EncryptedData xmlns="..." Type="ZippedElement">

where it is noted that the value of the Type attribute is not "Element" but
"ZippedElement".  Then, the unencrypted element is replaced with the
<EncryptedData> element because I am encrypting an element.  However, when
decrypting the <EncryptedData> element, it will not be replaced
automatically because the value of its Type attribute is not "Element".
How do you feel?

>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

So do you mean, when canonicalizing an element using C14N, it is allowed to
use the value "Element" for the Type attribute?

Tokyo Research Laboratory
IBM Research
Received on Thursday, 2 August 2001 10:05:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:04 UTC