Re: CipherData rationale

Joseph,

I'm sorry for confusing you.  In the following sentence:

>I'd like to make sure that
>transforms specified in a transform sequence are those applied before
>decrypting.

I used "transform" as a general process to convert one into another.  I
just made sure of the spec, and if my example is correct, I totally agree
on the spec.

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



From: "Joseph M. Reagle Jr." <reagle@w3.org> on 2001/06/05 06:39 AM

Please respond to "Joseph M. Reagle Jr." <reagle@w3.org>

To:   Takeshi Imamura/Japan/IBM@IBMJP
cc:   "Frederick J. Hirsch" <hirsch@zolera.com>, <xml-encryption@w3.org>
Subject:  Re: CipherData rationale



At 03:18 5/30/2001, Takeshi Imamura wrote:
> >Is the rationale that the first form makes for easier processing since
the
>types
> >are clearly distinguished via elements at the expense of slightly more
>verbose
> >XML? I gather the first form is also more extensible.
>
>I believe so.
>
>By the way, in your example, you specify C14N as a transform, but C14N is
>not reversible and cannot be specified.  And I'd like to make sure that
>transforms specified in a transform sequence are those applied before
>decrypting.

I'm a little confused. The spec says, "it is the reverse transforms that
are
applied before decrypting and it is the reverse transforms that are
specified in the CipherData element." which your text seems to disagree
with, but your example below:

><CipherReference URI="some-URI">
>   <ds:Transforms>
>     <ds:Transform Algorithm="decode"/>
>     <ds:Transform Algorithm="decompress"/>
>   </ds:Transforms>
></CipherReference>

agrees with!? Are the transforms specified as they should be done after
decryption, or as they were done before encryption?



--
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 Wednesday, 6 June 2001 02:12:55 UTC