This document specifies the "decryption transform", which enables XML Signatures verification even if both signature and encryption operations are performed on an XML document.
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
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.
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 "
ds" XML namespace prefixes is OPTIONAL; we use this
facility to provide compact and readable exposition.
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
that appear as the direct child elements of the
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
220.127.116.11 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
enc:DataRef elements. The output of this
transform is a node-set.
In order to help an unambiguous definition of the exact semantics of this transform, we define the following two functions:
</dummy>) as described in [Tobin].
enc:DataRefelements specified as the parameter of this transform.
enc:DataRefelements 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:
enc:DataRefelements given as the parameter of this transform.
EncryptedDataand 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.
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.
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.
ds:Transform element can be created by the following
enc:EncryptedData, create an
enc:DataRefelement referencing the node.
ds:Transformelement, including the algorithm identifier of this transform and all the
enc:DataRefelements created in Step 3.
Suppose the following XML document is to be signed. Note that the
part of this document (
) is already encrypted prior
to signature. In addition, the signer anticipates that some parts of
this document, for example, the
[07-11]) will be encrypted after signing.
 <order Id="order">  <item>  <title>XML and Java</title>  <price>100.0</price>  <quantity>1</quantity>  </item>  <cardinfo>  <name>Your Name</name>  <expiration>04/2002</expiration>  <number>5283 8304 6232 0010</number>  </cardinfo>  <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#" Id="enc1">...</EncryptedData>  </order>
In order to let the recipient know the proper order of decryption
and signature verification, the signer include the decryption
[06-08] below) in the signature. Assuming
that an additional encryption is done on the
), the recipient would see the following
 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">  <SignedInfo>  ...  <Reference URI="#order">  <Transforms>  <Transform Algorithm="http://www.w3.org/2001/04/xmlenc#decryption">  <DataRef xmlns="http://www.w3.org/2001/04/xmlenc#" URI="#enc1"/>  </Transform>  <Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>  </Transforms>  ...  </Reference>  </SignedInfo>  <SignatureValue>...</SignatureValue>  <Object>  <order Id="order">  <item>  <title>XML and Java</title>  <price>100.0</price>  <quantity>1</quantity>  </item>  <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#" Id="enc2">...</EncryptedData>  <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#" Id="enc1">...</EncryptedData>  </order>  </Object>  </Signature>
The recipient should first look at the
[01-26]) for verification. It refers to the
order element (
[16-24]) with two transforms:
[06-08]) and C14N (
decryption transform instructs the signature verifier to decrypt all
the encrypted data except for the one specified in the
DataRef element (
). After decrypting
EncryptedData in line
order element is canonicalized and
It should be noted that in XML Signature
[XML-Signature], the digest value of a
signed resource appears in clear text in a
element, even though the resource is encrypted after signing.
As noted by Hal Finney in [Finney], this may
become vulnerability by plain-text-guessing attacks. However, it is
out of scope of this document and applications should implement
appropriate means to protect from these attacks.
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 may encrypt in addition to a signed resource the
ds:SignedInfo, or just
ds:DigestValue element. Note that, as noted by Joseph
Reagle in [Reagle], this solution works only if
signature and encryption are well known by each other. Also it is
unclear how one encrypting the signed resource should deal with its signature (e.g.,
encrypt the signature or leave it as it is) when someone has already
encrypted the signed resource and the signature.
Anyway, applications should consider this.