Re: CipherReference + Transforms meaning

Blair,

I thought the rules are the same, that is, when the type is Element or
Content, the decrypted XML structure replaces the EncryptedData element
whether the CipherData element contains the CipherValue or CipherReference
element, and so our implementation was done accordingly.  I feel it does
not make sense to distinguish both ...

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



From: "Blair Dillaway" <blaird@microsoft.com>@w3.org on 2001/06/13 08:21

Please respond to "Blair Dillaway" <blaird@microsoft.com>

Sent by:  xml-encryption-request@w3.org


To:   <edsimon@xmlsec.com>, <xml-encryption@w3.org>
cc:
Subject:  CipherReference + Transforms meaning



Changed the subject to reflect the discussions and trimmed the thread

I don't agree completely.  One of the reasons to use the reference +
transforms version of CipherData is to handle external, and possibly
non-XML, data.  The last sentence below implies it is an XML fragment.
It could just as easily be compressed video (an example you used in the
past).  In this case, the decrypted data would simply be handed to the
application.

This does raise an issue that should be resolved prior to finalizing
wording.  We have always agreed that the decrypted XML replaces the
EncryptedData element in the document when: 1)the CipherValue contains
the encrypted representation; and 2)the type is Element or
Element-Content.  Should the rules be the same when using the
CipherReference + Transforms if the type is given as Element or
Element-Content?  Or does use of the latter representation imply the
decrypted data is always treated as external to the document containing
the EncryptedData element?  Should we standardize on one interpretation
or provide a way to express both?

Comments

Blair

-----Original Message-----
From: edsimon@xmlsec.com [mailto:edsimon@xmlsec.com]
Sent: Tuesday, June 12, 2001 1:11 PM
To: xml-encryption@w3.org
Subject: RE: RE: Draft Minutes from 010611 Teleconf (changes)


In section 3.2.1 of the current draft, would you agree to replacing
everything from "The syntax of the URI and Transforms is similar to ..."
up to (but not including) the schema definition with this text:

--- start ---
Though the syntax of the Transforms is based on that in XML Signature
[XMLDSIG], the purpose for transforms in XML Encryption's
<CipherReference> element is unrelated to their purpose in XML
Signature's <Reference> element.  In XML Signature, transforms are used
to select or exclude data to be secured; in XML Encryption, transforms
are used solely to obtain the cipherdata that will be decrypted into an
XML string and inserted in place of the <EncryptedData> element.
--- end ---

Ed

-- Original Message --

>Ed,
>
>I must respectfully disagree with you on this.  I find this whole
>discussion of transform reversibility to be confusing and largely
>irrelevant and prefer Don's suggested wording.  Specifically, your
>statement
>
>    "Nevertheless, the concept of what you get after decryption
>     not being bit-for-bit or character-for-character the same
>     as what you had before encryption ..."
>
>is wrong in this context.  What you get after decrypting the cipher
>text is precisely bit-for-bit the octet sequence that was encrypted.
>The fact that the encryptor may have obtained the to-be-encrypted octet

>sequence based on some serialization of XML, that may differ from other

>possible serializations, doesn't matter.  All you're really saying is
>that there are multiple ways one may serialize XML and it is generally
>impossible to reverse the process to obtain some earlier serialized
>representation.  There is nothing encryption specific about this issue.
>
>Blair
>
<---------------  snip ------------------>

Received on Thursday, 14 June 2001 09:10:49 UTC