4 Processing Rules

This section describes the operations to be performed as part of encryption and decryption processing.

4.1 Encryption

For each data item to be encrypted:

1. Select the algorithm (and parameters) to be used in encrypting this data.
2. Obtain and (optionally) represent the key.
   1. If the key is to be identified (via naming, URI, or included in a child element), construct the ds:KeyInfo as approriate (e.g., ds:KeyName, ds:KeyValue, ds:KeyRetrievalMethod, etc.)
   2. If the key itself is to be encrypted, construct an EncryptedKey element. This may be then be a child of ds:KeyInfo, or it may exist elsewhere and may be identified in the previous step.
3.  Encrypt the data
   1. If the data is an [XML] Element or [XML] Element Content, obtain the octets resulting from their serialization in UTF-8 as specified in [XML].
   2. If the data is of any other type, its is treated solely as an octet sequence. For example, the data might be a serialization of an XML document, textual document, binary image data, or a compressed XML element. Unless the Decryptor will implicitly know the type (or encoding) of the encrypted data, the encryptor SHOULD specify the type value with the EncryptedData Type attribute.
   3. Encrypt the octets using the algorithm and key from steps 1 and 2.
4. Build the EncryptedData structure. An EncryptedData element represents all of the information previously discussed including the encryption algorithm, parameters, key, type of the encrypted data, etc.
   1. If the encrypted octet sequence obtained in Step 3 is to be stored in the CipherData element within the EncryptedData, then the encrypted octet sequence is base64 encoded and inserted as the text value of a CipherValue element.
   2. If the encrypted octet sequence is to be stored externally to the EncryptedData structure, then represent the URI, and optional transforms, required for the Decryptor to retrieve the encrypted octet sequence within a CipherReference element.
5. EncryptedData Processing
   1. If the Type of the encrypted data is Element or Element Content, implementations MUST be able to return the UTF-8 encoding of the EncryptedData element to the application. The application may use this as the top-level element in a new XML Document or insert it into another XML document.

      Encryption applications MUST be able to replace the unencrypted Element or Content with the EncryptedData element.. The application supplies the XML Document context and identifies the Element or Content being replaced. The Encryptor must remove the identified XML and insert the EncryptedData element in its place.

   2. If the Type of the encrypted data is not Element or Element Content, then the UTF-8 encoded EncryptedData element is always returned to the application. The application may use this as the top-level element in a new XML Document or insert it into another XML document (which may require a re-encoding).

4.2 Decryption

For each EncryptedType item to be decrypted (either an EncryptedData or EncryptedKey element):

1. Parse the application identified EncryptedType element to determine the algorithm, parameters and ds:KeyInfo element to be used. If some information is omitted, the application must supply it.
2. Locate the data encryption key according to the ds:KeyInfo element, which may contain one or more key attributes.  These attributes have no implied processing order. If the data encryption key is encrypted, locate the corresponding key to decrypt it. (This may be a recursive step as the key-encryption key may itself be encrypted.) Or, one might retrieve the data encryption key from a local store using the provided attributes or implicit binding.
3. Decrypt the data contained in the CipherData element.
   1. If a CipherValue child element is present, then the associated text value is retrieved and base64 decoded so as to obtain the encrypted octet sequence.
   2. If a CipherReference child element is present, the URI and optional transforms are used to retrieve the encrypted octet sequence.
   3. The encrypted octed sequence obtained is decrypted using the algorithm/parameters and key value already determined from Steps 1 and 2.
   4. If the cleartext octet sequence represents a key value, it is saved for use in decrypting the associated EncryptedData element(s). The Decryptor should support passing this key value to the application for persistent storage. If it represents encrypted data then processing as described below is required.
4. Decrypt data of Type Element or Element Content.
   1. The cleartext octet sequence obtained in step 3 is interpreted as UTF-8 encoded character data.
   2. The Decryptor MUST be able to return the type value and the UTF-8 encode XML character data.
   3. The Decryptor MUST support the ability to replace the EncryptedData element with the decrypted Element or Element Content represented by the UTF-8 encoded characters. The Decryptor is not required to perform validation on the serialized XML nor are they required to ensure the result of this replacement operation results in a valid XML document.
5. Decrypt data when the Type is unspecified or is not Element or Element Content
   1. The cleartext octet sequence obtained in step 3 is always returned to the application for further processing along with the Type attribute value when specified.

4.3 XML Encryption

Encryption and decryption operations are transforms on octets. As noted in the preceding discussion, the encrypting application is responsible for the serialization of XML into an octet sequence, and that octets' semantics, such that the decrypted data is useful to the decrypting application.

For example, if the applications wishes to canonicalize its data or encode/compress the data in an XML packaging format, the application needs to marshal the XML accordingly and identify the resulting type, which will encoded in the optional EncryptedData Type attribute. The likelihood of successful decryption and subsequent processing will be dependent on the recipient's support for the given type. Also, if the data is intended to be processed both before and after decryption (e.g., XML Signature [XMLDSIG] validation or an XSLT transform) the encrypting application must be careful to preserve information necessary for that process's success.

For interoperability purposes, the following types MUST be implemented.

Element 'http://www.w3.org/2001/04/xmlenc#Element'

"[39]  element ::= EmptyElemTag | STag content ETag" [XML]

Content 'http://www.w3.org/2001/04/xmlenc#Content'

"[43] content ::= CharData? ((element | Reference | CDSect | PI | Comment) CharData?)*" [XML]

MediaType 'http://www.isi.edu/in-notes/iana/assignments/media-types/*/*'

A user specified media type (e.g., text/xml). All such types are implemented as simple octet encryption.