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

Re: CipherData rationale

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Mon, 11 Jun 2001 12:13:43 -0400
Message-Id: <200106111613.MAA0000050280@torque.pothole.com>
To: "Joseph M. Reagle Jr." <reagle@w3.org>
cc: <xml-encryption@w3.org>

Although I think the specification ends up being more or less correct,
I think its approach is unnecessarily confusing. I think that XML
Encryption elements (like XML DSIG element) are created for the
applications that will read and act on those element. Thus, the main
emphasis should be on what a decryptor (or verifyer) needs to do.  It
would appear (and I believe this is correct and strongly support it),
that in both decryption adn signature verification, the decyrption or
signature verifying applciation most likely executes the transforms as
written in the natural XML order. (In either case their might be a
cached copy or something so it is not necessarily always the case that
the transformas are actually executed.)

*Starting* will all this jazz about how signature and encyrption /
decyrption are totally different and one does the transforms
backwards, upside down, inside out, and inverted gives you the feeling
that you are going to have to do the opposite of which each transform
says and in bottom to top order.  But then you get further down in the
document and it looks like you just do the obvious thing if you are
reading and trying to execute based on Transforms. I suggest replacing
all the text in 3.2.1 The CipherReference Element with the following:

"The CipherReference element indicates the location of the cipher text
by a URI. CipherReference MAY also contain a series of Transform
operations to be applied to the result of dereferncing this URI to get
the actualy cipher text. For example, the cipher text might be
embedded inside an XML document, encoded in base64, etc., and as a
result would need to be extracted, decoded, or whatever."

"The data flow from the URI dereference though any Transform
operations to the decryption process is essentially the same as it is
for XMLDSIG signature verficiation. In both cases, the data given to
the final cryptographic decryption or vefication process is an octet
stream. However, there is a difference in the data model between
signature generation and plain text encryption. For signature
generation, the same source data and Transform operations could be
applied as in signature verfication. But for encryption, the source
would, of course, need to be the plain text, not the cipher text, and
any transformations done would be those that would be undone by the
Transform operations in the CipherReference element and in the
opposite order. The exact mechanics of prodcution of the data from
which the cipher text is extracted by a CipherReference is immaterial
as long as the given URI with any Transform operations present succeed
in recovering that cipher text."

The example is OK except that cipher text is generally imcompressible
so a decompress is not a plasible thing to do.

Thanks,
Donald

From:  "Joseph M. Reagle Jr." <reagle@w3.org>
Message-Id:  <4.3.2.7.2.20010604173812.02a2af08@localhost>
Date:  Mon, 04 Jun 2001 17:39:15 -0400
To:  "Takeshi Imamura" <IMAMU@jp.ibm.com>
Cc:  "Frederick J. Hirsch" <hirsch@zolera.com>, <xml-encryption@w3.org>
In-Reply-To:  <OF4A8D9A23.E01B22E7-ON49256A5C.0020387B@LocalDomain>

>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 Monday, 11 June 2001 12:14:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:19 GMT