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 item.
  2.  Generate or obtain the encryption key to be used. If the key is to be transported to the decryptor, obtain the algorithm/parameters and key-encryption key from the application. Use these to encrypt the key value and create an EncryptedKey structure to hold the encrypted key value. This will be encoded using the UTF-8 character set. Encryptors shall support the ability to return the EncryptedKey structure to the application or embed it the EncryptedData structure described in Step 5. If returned to the application, the application will typically supply a URI for the EncryptedKey which can be incorporated in the EncryptedData (using the RetrievalMethod element). Alternately the application may specify use an indirect method to identify the key such as a KeyName value.
  3.  Encrypting an [XML <> ] Element <http://www.w3.org/TR/2000/REC-xml-20001006> or [XML <> ] element Content <http://www.w3.org/TR/2000/REC-xml-20001006>
    1. The application is responsible serializing the Element or Content XML to produce a valid string-based XML serialization. This could be a simple "as-is" serialization (commonly referred to as the Outer- and Inner-XML for an element) or a canonicalized form such as defined in [XML-C14N]. It is assumed the application knows the appropriate format to insure the recipient can process the encrypted data.
    2. If the serialized XML string is not UTF-8 encoded, it must be converted to UTF-8 prior to passing it to the XML Encryptor. The application must also provide the Type of the data (Element or Content).
    3. The Encryptor accepts the UTF-8 encoded XML string and interprets it as an octet sequence for encryption. The Encryptor is not required to perform any validation on the application supplied string. The octet sequence is encrypted based on the algorithm/parameters and key value determined in steps 1 and 2 producing an encrypted octet sequence.
  4.  Encrypting other types of data
    1. The application is responsible for generating the octet sequence to be encrypted. This may represent any type of data. For example, it could be a serialization of an XML document, textual document, binary image data, or a serialized and compressed XML element representation. From the perspective of the XML Encryptor, this is an untyped octet sequence and no encoding is assumed. Unless the decryptor will implicitly know the type of the encrypted data, it is recommended the application provide an appropriate Type value to include with the encrypted data.
    2. The Encryptor encrypts the supplied octet sequence based on the algorithm/parameters and key value determined in steps 1 and 2 producing an encrypted octet sequence.
  5.  Building the EncryptedData structure
    1. An EncryptedData element is created encoding information about the algorithm, parameters, key value, Type of encrypted data, and so forth. The key value will typically be communicated using the EncryptedKey structure optionally generated in Step 2. The EncryptedData element will be encoded using the UTF-8 character set.
    2. If the encrypted octet sequence obtained in Step 3 or 4 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. If the encrypted octet sequence is to be stored externally to the EncryptedData structure, then the encrypted octet sequence is returned to the application. The application must supply a URI, and optional transforms, required for the decryptor to retrieve the encrypted octet sequence. The URI and transforms are encoded in a CipherReference element.
  6. EncryptedData Processing
    1. If the Type of the encrypted data is unspecified or is not Element or Content, compliant implementations shall provide a way to return the EncryptedData element to the application (REQUIRED). The application may use this as the top-level element in a new XML Document or insert it into another XML document. Encryption implementations may also support replacement of the unencrypted Element or Content with the EncryptedData element(RECOMMENDED). In the latter case, the application supplies the XML Document context and a reference to the Element, or parent Element of the Content, encrypted. The Encryptor will remove referenced XML and insert the EncryptedData element in its place. This may require re-encoding the UTF-8 EncryptedData into the character set encoding used in the XML Document.
    2. If the Type of the encrypted data is unspecified or is not Element or Content, then the 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.

4.2 Decryption

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

  1. Parse the application identified element to determine the algorithm, parameters and KeyInfo element to be used. If some information is omitted, the application must supply it.
  2. Locate the data encryption key according to the 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, de-base64 encoded to obtain the encrypted octet sequence, and decrypted using the algorithm/parameters and key value determined in steps 1 and 2 yielding the cleartext octet sequence.
    2. If a CipherReference child element is present, then the URI and optional transforms are used to retrieve the encrypted octet sequence. The encrypted octed sequence is decrypted using the algorithm/parameters and key value determined in steps 1 and 2 yielding the cleartext octet sequence.
    3. 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. Decrypting data whose Type is [XML <> ] Element or element Content
    1. The cleartext octet sequence obtained in step 3 is interpreted as a UTF-8 encoded string representing serialized XML.
    2. The Decryptor shall support the ability to return this UTF-8 XML string, and the Type value, to the application for further processing (REQUIRED)
    3. The Decryptor may support the ability to replace the EncryptedData element with the decrypted Element or Content XML represented by the UTF-8 encoded string (RECOMMENDED). The Decryptor is not required to perform validation on the serialized XML nor are they required to insure the result of this replacement operation results in a valid XML document.
  5.  Decrypting data when the Type is unspecified or is not Element or 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 Encrypted Data Semantics

Encryption and decryption operations are defined as transforms on binary data, hence the fundamental representation of data being operated on by Encryptors and Decryptors is an octet sequence. As noted in the preceding discussion, it is the responsibility of the using application to provide associated semantics for this octet sequence. It is also the application's responsibility to insure that data is encoded and typed in a manner useful to the intended recipient.

For instance, if the applications wishes to canonicalize (using [XML-C14N] or some other serialization) 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 a given type. Also, if the data is intended to be processed both before and after decryption (e.g., XML Signature [XMLDSIG]] validation or 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 <http://www.w3.org/2001/04/xmlenc> '

"[39] element <http://www.w3.org/TR/2000/REC-xml-20001006> ::= EmptyElemTag <http://www.w3.org/TR/2000/REC-xml-20001006> | STag <http://www.w3.org/TR/2000/REC-xml-20001006> content <http://www.w3.org/TR/2000/REC-xml-20001006> ETag <http://www.w3.org/TR/2000/REC-xml-20001006> " [XML <> ]

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

"[43] content <http://www.w3.org/TR/2000/REC-xml-20001006> ::= CharData <http://www.w3.org/TR/2000/REC-xml-20001006> ? ((element <http://www.w3.org/TR/2000/REC-xml-20001006> | Reference <http://www.w3.org/TR/2000/REC-xml-20001006> | CDSect <http://www.w3.org/TR/2000/REC-xml-20001006> | PI <http://www.w3.org/TR/2000/REC-xml-20001006> | Comment <http://www.w3.org/TR/2000/REC-xml-20001006> ) CharData <http://www.w3.org/TR/2000/REC-xml-20001006> ?)*" [XML <> ]

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

A user specified media type (e.g., text/xml <http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml> ). All such types are implemented as simple octet encryption.