RE: Processing <CipherData> (was "RE: CipherReference + Transforms meaning")

Ed,

>One solution is to have a Type media type for XML elements that doesn't
>imply "decrypt AND replace".  Another option, is to say the Type attribute
>simply says what the encrypted content was and not have a processing
semantic
>behind it; another attribute or parent element would indicate what to do.

I prefer the second one, but I think that another attribute or something is
not needed in order to indicate what to do.  This is because each
application must know what to do according to the Type attribute (e.g., a
decryptor compliant to the XML Encryption spec must know that an
EncryptedData element with a Type attribute "Element" (which may be
contained directly or be specified by a user) is decrypted and replaced).

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



From: edsimon@xmlsec.com@w3.org on 2001/06/16 09:47 AM

Please respond to edsimon@xmlsec.com

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


To:   xml-encryption@w3.org
cc:
Subject:  RE: Processing <CipherData> (was "RE: CipherReference +
      Transforms meaning")



Blair,
I like the gist of your text but I have a scenario I'd like to present.

Say, I have a application that synchronizes the content of replicated XML
files existing behind firewalls.  Because only a few of the elements in
a file change between updates, I don't want to encrypt and redistribute
the entire file.  So my application looks for changes to certain XML
elements,
and, for each changed element, grabs it, encrypts it, packages it into an
<EncryptedData> element.  Once it has reviewed all the elements, it stores
the corresponding <EncryptedData> elements a StuffToBeSynchronized.xml file
and distributes it.

Though StuffToBeSynchronized.xml has <EncryptedData> elements containing
XML elements, my goal isn't to expand inine its <EncryptedData> elements
into plaintext XML elements.  But I still would like to use the Type
attribute
to indicate the contained encrypted data is an XML element.

One solution is to have a Type media type for XML elements that doesn't
imply "decrypt AND replace".  Another option, is to say the Type attribute
simply says what the encrypted content was and not have a processing
semantic
behind it; another attribute or parent element would indicate what to do.

Is this a realistic scenario? If so, what would the Type attribute be set
to?

Regards, Ed

-- Original Message --

>Thank you Ed.  Your suggested additions to Section 4.2 look good.
>
>Didn't think I'd get to this today, but here is additional text I would
>like inserted in the other relevant sections.
>
>Section 3.3.  Replace the last sentence with:
>
>Type is an optional attribute identifying type information about the
>decrypted content.  This type information plays a key role in the
>behavior of compliant decryptors as decribed in Section 4.2.  If the
>EncryptedData element contains data of type element or element content,
>and replaces that data in an XML Document context, it is strongly
>recommended the type attribute be provided.  Without this information,
>the decryptor will be unable to automatically restore the XML Document
>to its original clear-text form.
>
>
>Section 4.1.  Under step 4.1, add the sentence:
>
>It is strongly recommended compliant encryptors  insert the optional
>Type attribute into EncryptedData with a value of 'Element' or
>'ElementContent' respectively to allow automated document restoration
>processing as described in Section 4.2.
>
>
>-----Original Message-----
>From: edsimon@xmlsec.com [mailto:edsimon@xmlsec.com]
>Sent: Friday, June 15, 2001 2:42 PM
>To: Blair Dillaway; Takeshi Imamura
>Cc: xml-encryption@w3.org
>Subject: Processing <CipherData> (was "RE: CipherReference + Transforms
>meaning")
>
>
>Blair wrote
>
>>Perhaps I am being unnecessarily concerned about this.  I don't have a

>>problem with the language you cite, what I have a problem with is the

>>lack of discussion about the linkage between the OPTIONAL type
>>attribute on EncryptedData and the assumed processing.  I am concerned

>>about confusion as to what is supposed to happen with various
>>combinations of specifying/not specifying the type and using
>>CipherValue vs CipherReference.
>
>I strongly agree with Blair.
>
>To review, there has been some discussion suggesting that if an
><CipherReference> is being used, there should be an assumption the data
>is not an element or element content, and if <CipherValue> is being
>used, then it is an element or element content.
>
>I would prefer NOT to second guess how applications want to do things.

>There may indeed be apps that prefer to keep encrypted inline XML remote
>(perhaps for authorization/performance reasons), and there may be some
>that would rather not have to keep encrypted arbitrary data remote from
><EncryptedData> elements.
>
>Here's the way I look at it...
>
>The result of processing a <CipherData> element is simply an octet
>stream to be sent to the decryption engine, no semantics are implied.
>If <CipherData> contains a <CipherValue> element, obtain the octet
>stream by de-base64ing its content.  If <CipherData> contains a
><CipherReference> element, dereference the value of the URI attribute
>and applies the specified transforms (if
>any) to obtain the octet stream.
>
>Once the octet stream has been decrypted, process it based on the Type
>attribute of the <EncryptedData> element.  If the Type attribute
>indicates an element or element content, replace <EncryptedData> with
>the decrypted element or element content; otherwise, hand the
>application a reference to the octet stream.
>
>[I submit the preceding two paragraphs for inclusion into the spec.]
>
>Ed
>
>
>
>
>
>
>

Received on Monday, 18 June 2001 03:16:48 UTC