Re: Questions on processing rules

Joseph,

I'm sorry for delay.

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

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
>><zip>ab234234</zip>.
>
>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
will
>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">
  <CipherData>
    <CipherValue>AbcDEfg...</CipherValue>
  </CipherData>
</EncryptedData>

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
>needs"

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

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com

Received on Thursday, 2 August 2001 10:05:08 UTC