Re: CipherReference + Transforms meaning

Ed,

XSS4J will return an InputStream object from which the decrypted GIF file
is read.  XSS4J returns such InputStream object when a type is not provided
by the Type attribute or a decryptor or a provided type is not recognized.

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



From: edsimon@xmlsec.com@w3.org on 2001/06/14 11:24 PM

Please respond to edsimon@xmlsec.com

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


To:   xml-encryption@w3.org
cc:
Subject:  Re: CipherReference + Transforms meaning



Takeshi,
What does XSS4J do when the <CipherValue> contains or <CipherReference>
points to, say, an encrypted GIF file?

Regards, Ed

-- Original Message --

>
>
>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 Friday, 15 June 2001 04:00:11 UTC