Decryption Transform for XML Signature

Note 26-February-2001

Takeshi Imamura <>
Hiroshi Maruyama <>


This document specifies the "decryption transform", which enables XML Signatures verification even if both signature and encryption operations are performed on an XML document.

Table of Contents

  1. Purpose
  2. Decryption Transform
  3. Processing Rules
  4. Example
  5. Security Considerations
  6. References

1 Purpose

It has been noted by David Solo in [Solo] that both signature [XML-Signature] and encryption [XML-Encryption] operations may be performed on an XML document at any time and in any order, especially in scenarios such as workflow. Since encryption operations applied to part of the signed content after a signature operation cause a signature to not be verifiable, it is necessary to decrypt the portions encrypted after signing before the signature is verified. The "decryption transform" proposed in this document provides a mechanism; decrypting only signed-then-encrypted portions (and ignoring encrypted-then-signed ones). A signer can insert this transform before the Canonical XML [XML-C14N] if there is a possibility that someone will encrypt portions of the signature.

The transform defined here is intended to propose a resolution to the decryption/verification ordering issue within signed resources. It is out of scope of this document to deal with the cases where the ordering can be derived from the context. For example, when a SignatureValue element or a (part of) SignedInfo element is encrypted, the ordering is obvious (without decryption, signature verification is not possible) and there is no need to introduce a new transform.

2 Decryption Transform

Algorithm Identifier:

This transform takes as a parameter a list of references to encrypted portions that are not to be decrypted by this transform. These references are expressed by EncryptedReference elements that appear as the direct child elements of the Transform element.

This transform requires an XPath node-set [XPath] for input. If an octet stream is given as input, it must be converted to a node-set as described in The Reference Processing Model of the XML Signature specification [XML-Signature]. This transform decrypts all the EncryptedData elements (as defined in forthcoming XML Encryption standard [XML-Encryption]) except for those specified by EncryptedReference elements. The output of this transform is a node-set.

3 Processing Rules

3.1 Preparation

In order to help an unambiguous definition of the exact semantics of this transform, we define the following two functions:

Y = decrypt(X,e)
where X is a node-set and e is an element node with the type EncryptedData defined in XML Encryption [XML-Encryption].
Y is a node-set obtained by the following steps:
  1. Convert X into an octet stream as described in in XML Signature [XML-Signature] (this means the use of the REQUIRED canonicalization algorithm [XML-C14N]).
  2. If the resulted octet stream is not a well-formed XML (e.g., a sequence of elements without a single root element), wrap the stream with a pair of dummy tags (i.e., <Dummy> ... </Dummy>). This idea is described in [Tobin].
  3. Decrypt the element corresponding to e according to XML Encryption. This decryption process receives an octet stream that is a well-formed XML document and generates another XML document as an octet stream.
  4. Parse the decrypted octet stream, resulting in a node set.
  5. If the pre-decryption octet stream was wrapped by a dummy element in Step 2 above, Y is the all immediate child nodes of the root element node of the parsed document. Otherwise, Y is the root element node of the parsed document.
If any of the above decryption steps fails for whatever reasons (e.g., the decryption key cannot be located, parsing in Step 3 fails, etc.), the decrypt() function also fails.
N = noDecryptNodes(X, R)
where X is a node set and R is a set of EncryptedReference elements specified as the parameter of the transform.
This function evaluates the URI attributes of all the EncryptedReference elements in R in the context of the node-set X. N is a set of nodes referenced by R.

3.2 Decryption Transform

This transform performs the following steps:

  1. Let X be the node-set given as input. Let R be the set of EncryptedReference elements given as the parameter of this transform.
  2. Within X, select e, an element node, whose local name is EncryptedData and whose namespace URI is the one defined in the XML Encryption, such that e is not a member of noDecryptNodes(X,R). If such e cannot be selected, the algorithm terminates and the result of the transformation is X.
  3. Let Y be decrypt(X,e). If the decryption succeeds, replace X with Y. If the decryption fails, the application MAY signal a failure of the transform. Alternatively, it MAY also continue processing without changing X (although it should take an appropriate means to avoid an infinite loop).
  4. Go to Step 2.

4 Example

Suppose the following XML document is to be signed. Note that the part of this document ([12]) is already encrypted prior to signature. In addition, the signer anticipates that some parts of this document, for example, the cardinfo element ([07-11]) will be encrypted after signing.

   [01] <order Id="order">
   [02]   <item>
   [03]     <title>XML and Java</title>
   [04]     <price>100.0</price>
   [05]     <quantity>1</quantity>
   [06]   </item>
   [07]   <cardinfo>
   [08]     <name>Your Name</name>
   [09]     <expiration>04/2002</expiration>
   [10]     <number>5283 8304 6232 0010</number>
   [11]   </cardinfo>
   [12]   <EncryptedData xmlns="" Id="enc1">...</EncryptedData>
   [13] </order>

In order to let the recipient know the proper order of decryption and signature verification, the signer include the decryption transform in the signature. Assuming that an additional encryption is done on the cardinfo element ([22] below), the recipient would see the following encrypt-sign-encrypt document:

   [01] <Signature xmlns="">
   [02]   <SignedInfo>
   [03]     ...
   [04]     <Reference URI="#order">
   [05]       <Transforms>
   [06]         <Transform Algorithm="">
   [07]           <EncryptedReference xmlns="" URI="#enc1"/>
   [08]         </Transform>
   [09]         <Transform Algorithm=""/>
   [10]       </Transforms>
   [11]       ...
   [12]     </Reference>
   [13]   </SignedInfo>
   [14]   <SignatureValue>...</SignatureValue>
   [15]   <Object>
   [16]     <order Id="order">
   [17]       <item>
   [18]         <title>XML and Java</title>
   [19]         <price>100.0</price>
   [20]         <quantity>1</quantity>
   [21]       </item>
   [22]       <EncryptedData xmlns="" Id="enc2">...</EncryptedData>
   [23]       <EncryptedData xmlns="" Id="enc1">...</EncryptedData>
   [24]     </order>
   [25]   </Object>
   [26] </Signature>

The recipient should first look at the Signature element for verification. It refers to the order element with two transforms: decryption and C14N. The decryption transform instructs the signature verifier to decrypt all the encrypted data except for the one specified in the EncryptedReference element. After decrypting the EncryptedData in line [22], the order element is canonicalized and signature-verified.

5 Security Considerations

It should be noted that in XML Signature [XML-Signature], the digest value of a signed resource appears in clear text in a Reference element, even though the resource itself is encrypted after signing. As noted by Hal Finney in [Finney], this may become vulnerability by plain-text-guessing attacks. Applications should implement appropriate means to protect from these attacks.

6 References

Hal Finney. Re: Combining signing and encrypting, XML Encryption Mailing List, 2000.
David Solo. Combining signing and encrypting, XML Encryption Mailing List, 2000.
Richard Tobin. Infoset for external entities, XML Core Mailing List, 2000.
John Boyer. Canonical XML Version 1.0, W3C Proposed Rec., 2001.
Blair Dillaway, Barbara Fox, Takeshi Imamura, Brian LaMacchia, Hiroshi Maruyama, Jim Schaad, and Ed Simon. XML Encryption Syntax and Processing Version 1.0, 2000.
Donald Eastlake, Joseph Reagle, and David Solo. XML-Signature Syntax and Processing, W3C Candidate Rec., 2000.
James Clark and Steve DeRose. XML Path Language (XPath) Version 1.0, W3C Rec., 1999.