The Decryption Transform makes it easier to verify XML signatures over data when some of the data has been encrypted before and some after the signature was applied. The signature verifier needs to know which parts to decrypt and which parts to leave encrypted when trying to verify the signature. (This section is based on a W3C Working Draft [Decrypt] but subsequent recommendations will likely have similar characteristics and limitations.)
16.2.1 Introduction to the Decryption Transform
The Decryption Transform works as follows: A Transform is added to appropriate Reference elements in a SignedInfo or Manifest element (see Chapter 10). The Transform takes a list of encrypted parts of the data as parameters. When validating the signature, any other encrypted data encountered within the digested data are decrypted; those listed in the Transform are left encrypted. The concept is simple, but to precisely describe the processing and limitations becomes more complicated.
In protocol applications (see Appendix E), the protocol syntax typically specifies how, in what order, and over which parts of the protocol message signature and/or encryption operations are applied. Therefore, the general mechanism of the Decryption Transform is not essential, although it could be used in certain circumstances. Even in cases where the protocol is very flexible, it would normally be designed to be self-documenting. That is, some indicators would be securely included that enable recipients participating in the protocol to know which decryptions and signature verifications they should perform in what order. Where data of an unknown security structure are forwarded within a protocol message, the data can normally be treated as opaque without further analysis.
For document applications (see Appendix E), the data is usually more free form, and it is desirable for the status of data to be apparent outside of any protocol context. Furthermore, later, independent processes might choose to encrypt parts of the signed data so that the signature no longer verifies. Thus the Decryption Transform is clearly applicable in some document cases.
16.2.2 Decryption Transform Syntax
The algorithm identifier for the Decryption Transform is
which is also the namespace for parameter elements to the Transform. This identifier serves as the value of the Algorithm attribute of a Transform element. It takes, as explicit parameters, an arbitrary number of Except elements, each of which has a URI attribute that points to data that were encrypted during calculation of the signature. These URIs are limited to same-document URIs that point at EncryptedData elements. Example 16-1 shows a Reference element with a Decryption Transform.
Example 16-1 Decryption Transform
<Reference URI="" xmlns="http://www.w3.org/2000/09/xmldsig#"> <Transforms> <Transform Algorithm= "http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/2001/04/decrypt#" xmlns:dct="http://www.w3.org/2001/04/decrypt#"> <dct:Except URI="#foo"><dct:Except URI="#bar"> </Transform> </Transforms> <DigestMethod Algorithm= "http://www.w3.org/2001/04/xmldsig-more#md5"/> <DigestValue>qZk+NkcGgWq6PiVxeFDCbJ==</DigestValue> </ds:Reference>
Following is the schema for the Except element of the Decryption Transform:
Schema Definition: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN" "http://www.w3.org/2001/XMLSchema.dtd" [ <!ENTITY % p ''> <!ENTITY % s ''> ]> <schema xmlns='http://www.w3.org/2001/XMLSchema' version='0.1' xmlns:dt='http://www.w3.org/2001/04/decrypt#' targetNamespace='http://www.w3.org/2001/04/decrypt#' elementFormDefault='qualified'> <element name="Except" type="dt:ExceptType"/> <complexType name='ExceptType'> <attribute name='Id' type='ID' use='optional'/> <attribute name='URI' type='anyURI' use='required'/> </complexType>
16.2.3 Decryption Transform Processing
Now we get to the tricky part how to rigorously specify decrypting parts of XML in the XPath data model while minimally changing its serialization in other ways.
The Decryption Transform requires an XPath node-set as input. If the previous Transform or the Reference URI yields an octet stream, it must be parsed. This requirement is only reasonable, as the Transform will look for the EncryptedData elements within the input data. Those that are referenced by the Except parameters are left alone; the others are decrypted and the results plugged in. The XPath data model, on which XML Encryption and Signature are based, does not provide any mechanism for performing "transplant surgery" on an XPath node set, however. As a consequence, much of the processing is defined in terms of substitutions within and augmentations of an octet sequence. In fact, an implementation is merely required to get the same result as it would obtain by following the specified steps. As long as it meets this requirement, it may implement processing in a different fashion.
16.2.4 Decryption Transform Limitations
The concept of a way to protect signed data such that later modifications can be undone and the signature still verified is quite audacious. Even when it is limited to encryption of XML in the same document as the signature, it cannot be done perfectly.
The processing description given in Section 16.2.3 listed a number of caveats. In addition, the following limitations exist: