This section describes the operations to be performed as part of encryption
and decryption processing.
For each data item to be encrypted:
or [XML <> ] element Content <http://www.w3.org/TR/2000/REC-xml-20001006>
- Select the algorithm (and parameters) to be used in encrypting this
- 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.
- Encrypting an [XML <> ] Element <
Encrypting other types of data
- 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.
- 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).
- 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.
Building the EncryptedData structure
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
For each item to be decrypted (either an EncryptedData or EncryptedKey
- 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.
- 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.
- Decrypt the data contained in the CipherData element.
- 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.
- 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.
- 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
- Decrypting data whose Type is [XML <> ] Element or element Content
- The cleartext octet sequence obtained in step 3 is interpreted as a
UTF-8 encoded string representing serialized XML.
- The Decryptor shall support the ability to return this UTF-8 XML string,
and the Type value, to the application for further processing (REQUIRED)
- 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.
- Decrypting data when the Type is unspecified or is not Element or
- The cleartext octet sequence obtained in step 3 is always returned to the
application for further processing along with the Type attribute value when
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/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>
" [XML <> ]
" 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 <> ]
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.