This would be a good idea for applications such as content
control. The whole field is patented up the wazoo but the
basic idea of using encryption for content control is pretty
old.
One thing that might get a little encumbering is managing
a host of separate IVs for each of the pieces of content
that is controlled. Certainly some info needs to be wrapped
arround the encrypted object - but how much?
Would it be a bad idea to prefix the encrypted byte stream
itself with the initialization vector? After all the code
needs to know how to add and remove padding in any case.
If all the info required to do the decrypt is attached to
the encrypted blob the linking to multiple decrypt blobs
within the same document will be greatly simplified.
So the encrypted blobs would become:
Base64 ( IV ^ E[ Data ^ Padding ] )
Phill
> Hi,
>
> Something that I would be interested in is the ability to
> provide encryption information about an external non-XML
> entity:
>
> <EncryptedData xmlns="&xmlenc;"
> Location="foo"
> EncryptionInfo="#encryptionInfo23" />
>
> The rationale is that XML is being used in some situations
> to encode control information describing accompanying non
> XML data.
>
> Support in this document would allow the control data to
> express encryption information in a standard manner, and
> the keying information could also be shared with encrypted
> nodes within the control document.
>
> Embedding external data within base 64 nodes is not always
> practical or efficient.
>
> Merlin
>