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 17:46:05 UTC