W3C Logo

Decryption Transform for XML Signature

WG Working Draft 26 June 2001

This version:
Latest version:
Previous version:
Takeshi Imamura <imamu@jp.ibm.com>
Hiroshi Maruyama <maruyama@jp.ibm.com>
See References.


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

Status of this document

This is the first draft of the "Decryption Transform for XML Signature" from the XML Encryption Working Group (Activity). Comments and implementation experience of this proposal are solicited.

Publication of this document does not imply endorsement by the W3C membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite a W3C Working Draft as anything other than a "work in progress." A list of current W3C working drafts can be found at http://www.w3.org/TR/.

Please send comments to the editors (<imamu@jp.ibm.com>, <maruyama@jp.ibm.com>) and cc: the list xml-encryption@w3.org(archives)

Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page in conformance with W3C policy.

Table of Contents

  1. Introduction
    1. Purpose
    2. Editorial Conventions
  2. Decryption Transform
  3. Processing Rules
  4. Transform Creation (Non-Normative)
  5. Example
  6. Security Considerations
  7. References

1 Introduction

1.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. For example, suppose a scenario that Alice has Bob send money to her by postal transfer. Alice draws up a document including a statement, "Bob pays $100 to Alice", and the number of her bank account and sends it to Bob. The number is encrypted with a bank's public key for guarding her privacy. Then, Bob includes the number of his bank account in the document, signs it for proving that he approves the statement, and sends it to the bank. The number is also encrypted. As a result, encryption, signature, and encryption are performed in this order on the document the bank receives.

Since encryption operations applied to part of the signed content after a signature operation cause a signature not to 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 in a transform sequence (e.g., before Canonical XML [XML-C14N] or XPath [XPath]) if there is a possibility that someone will encrypt portions of the signature.

The transform defined in this document 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 ds:DigestValue element or a (part of) ds: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.

1.2 Editorial Conventions

This document makes use of the XML Encryption [XML-Encryption] and XML Signature [XML-Signature] namespaces with the following prefixes:


The XML Encryption namespace is also used as the prefix for an algorithm identifier defined in this document. While applications MUST support XML and XML namespaces, the use of our "enc" and "ds" XML namespace prefixes is OPTIONAL; we use this facility to provide compact and readable exposition.

2 Decryption Transform


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 enc:DataRef elements that appear as the direct child elements of the ds: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 enc:EncryptedData elements (as defined in the forthcoming XML Encryption standard [XML-Encryption]) except for those specified by enc:DataRef elements. The output of this transform is a node-set.

3 Processing Rules

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 enc:EncryptedData in X.
Y is a node-set obtained by the following steps:
  1. Convert X into an octet stream as described in The Reference Processing Model of the XML Signature specification [XML-Signature] (this means the use of the REQUIRED canonicalization algorithm [XML-C14N]).
  2. If the result ing octet stream is not a well-formed XML (e.g., a sequence of elements without a single root element), wrap the octet stream with a pair of dummy tags (i.e., <dummy> and </dummy>) as described in [Tobin].
  3. Decrypt the element corresponding to e according to XML Encryption [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 as described in The Reference Processing Model of the XML Signature specification, resulting in a node-set.
  5. If the pre-decryption octet stream was wrapped by a pair of dummy tags in Step 2, Y is all the immediate child nodes of the root element node of the node-set. Otherwise, Y is the root element node of the node-set.
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.), this function also fails.
N = noDecryptNodes(X, R)
where X is a node-set and R is a set of enc:DataRefer ence elements specified as the parameter of this transform.
This function evaluates the URI attributes of all the enc:DataReference elements in R in the context of the node-set X. N is a set of nodes referenced by R.

This transform performs the following steps:

  1. Let X be the node-set given as input. Let R be the set of enc:DataReference 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 XML Encryption [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.

Note: this transform does not deal with any detached enc:EncryptedKey elements. When an enc:EncryptedData element is decrypted, some enc:EncryptedKey elements detached from the enc:EncryptedData element have to be removed if the enc:EncryptedKey elements are in the scope of signature being validated. However, it is unclear how this transform should deal with the enc:EncryptedKey elements, and hence it is not recommended in this document to detach enc:EncryptedKey elements from an enc:EncryptedData element or to include detached enc:EncryptedKey elements in the scope of signature.

4 Transform Creation (Non-Normative)

It is out of scope of this document how to create a ds:Transform element and where to insert it in a transform sequence. In this section, we just show a way to create the element as advisory.

A ds:Transform element can be created by the following steps:

  1. Apply all the transforms placed before this transform to a data object being signed.
  2. If the transform just before this transform outputs an octet stream, convert it to a node-set as described in The Reference Processing Model of the XML Signature specification [XML-Signature].
  3. For each node in the node-set, if the node is an element node with the type enc:EncryptedData, create an enc:DataReference element referencing the node.
  4. Create a ds:Transform element, including the algorithm identifier of this transform and all the enc:DataRef elements created in Step 3.

5 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 Id="enc1" xmlns="http://www.w3.org/2001/04/xmlenc#">...</EncryptedData>
   [13] </order>

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

   [01] <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
   [02]   <SignedInfo>
   [03]     ...
   [04]     <Reference URI="#order">
   [05]       <Transforms>
   [06]         <Transform Algorithm="http://www.w3.org/2001/04/xmlenc#decryption">
   [07]           <DataReference URI="#enc1"
   [08]         </Transform>
   [09]         <Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
   [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 Id="enc2" xmlns="http://www.w3.org/2001/04/xmlenc#">...</EncryptedData>
   [23]       <EncryptedData Id="enc1" xmlns="http://www.w3.org/2001/04/xmlenc#">...</EncryptedData>
   [24]     </order>
   [25]   </Object>
   [26] </Signature>

The recipient should first look at the Signature element ([01-26]) for verification. It refers to the order element ([16-24]) with two transforms: decryption ([06-08]) and C14N ([09]). The decryption transform instructs the signature verifier to decrypt all the encrypted data except for the one specified in the DataRef element ([07]). After decrypting the EncryptedData in line [22], the order element is canonicalized and signature-verified.

6 Security Considerations

When this algorithm is used to permit subsequent encryption of data already signed, the digest value of the signed resource still appears in clear text in a ds:Reference element. As noted by Hal Finney in [Finney], such a signature may reveal information (via the digest value) over encrypted data that increases the encryption's vulnerabaility to plain-text-guessing attacks. This consideration is out of scope of this document and (if relevant) should be addressed by applications. For example, as proposed by Amir Herzberg in [Herzberg], one may include a random 'salt' in a resource being signed to increase its entropy.

Another approach is that when a signature referent is encrypted, one may also encrypt the signature (or at least the ds:DigestValue elements). As noted by Joseph Reagle in [Reagle], this latter solution works only if signature and encryption are well known by each other. For example, the signature may not be known of because it is detached. Or, it may it's already encrypted! Consider, Alice Encrypts element A and the Signature over the parent of A. Bob Encrypts element B (sibling of A) but not the Signature since he doesn't know about it. Alice then decrypts A and it's Signature, which may provide information to a subsequent plain text attack on the encrypted B.

7 References

Hal Finney. Re: Combining signing and encrypting, XML Encryption mailing list, 2000.
Amir Herzberg. Signing encrypted data, XML Encryption mailing list, 2001.
Joseph Reagle. Re: Signing and Encryption, XML Encryption mailing list, 2001.
David Solo. Combining signing and encrypting, XML Encryption mailing list, 2000.
Richard Tobin. Infoset for external entities, XML Core mailing list, [W3C Member Only] 2000.
John Boyer. Canonical XML Version 1.0, W3C 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., 2001.
James Clark and Steve DeRose. XML Path Language (XPath) Version 1.0, W3C Rec., 1999.