Re: Encryption metadata

Goal: Associate meta data with encrypted content, encrypt with the content
and make available upon decryption
         Would like the meta data to travel with encrypted content to create
a portable package.

Examples: Time of encryption, Log record identifier, workflow information,
notes...

Not all applications of encryption will require meta data to be associated
with encrypted data, but an optional ds:Object element would allow those
that do to have a standard container, rather than ad hoc approaches or
requiring changes to document XML, and associated schema problems.

Alternatives:

1. Incorporate XML Signature ds:Object into EncryptedType, allowing both
EncryptedData and EncryptedKey elements to have meta data. Place after
CipherData as an optional element (0 or more)

ds:Object allows any meta data to be incorporated, and provides a standard
place to put it.

schema change:
<complexType name='EncryptedType' abstract='true'>
    <sequence>
      <element name='EncryptionMethod' type='xenc:EncryptionMethodType'
               minOccurs='0'/>
      <element ref='ds:KeyInfo' minOccurs='0'/>
      <element ref='xenc:CipherData'/>
++++      <element ref='ds:Object' minOccurs='0' maxOccurs='unbounded'/>
    </sequence>
    <attribute name='Id' type='ID' use='optional'/>
    <attribute name='Type' type='anyURI' use='optional'/>
   </complexType>

2. Incorporate encryption meta data as signature object in signature on
encrypted data.

Although a signature protects the integrity of meta data, this is not always
required - signing an entire encrypted element may require more processing
than desired. In addition, some encryption services may not include signing,
and still require meta information. Likewise, a signer may not wish to sign
what they cannot see, such as an encrypted element, even if to sign the
association of meta data with the encrypted data.

3. Modify XML document to included meta data as XML which is then encrypted

Modifying existing XML documents may not work with existing schemas for
subsequent validation, and document recipients may not expect modification.
This approach will also result in different non-standard approaches to
associating meta information (eg. different elements). In addition, some
encrypted data is not XML and may still have associated meta data.

Adding an optional ds:Object element to EncryptedType offers a means for
applications to place meta information in a known place, only as needed,
although it is up to applications to define what is contained in the Object
and to manage any associated potential security issues.

---
Frederick Hirsch
Zolera Systems, http://www.zolera.com/
Information Integrity, XML Security