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 >Received on Thursday, 31 August 2000 10:45:56 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:17 GMT