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

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 Friday, 15 June 2001 19:23:26 UTC