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. 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.
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
4.3.3.2 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.
In order to help an unambiguous definition of the exact semantics of this transform, we define the following two functions:
EncryptedData defined in XML Encryption
[XML-Encryption].<Dummy>
... </Dummy>). This idea is
described in [Tobin].
EncryptedReference elements specified as the parameter
of the transform.EncryptedReference 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:
EncryptedReference elements
given as the parameter of this transform.
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.
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="http://www.w3.org/2000/11/temp-xmlenc" 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="http://www.w3.org/2000/09/xmldsig#"> [02] <SignedInfo> [03] ... [04] <Reference URI="#order"> [05] <Transforms> [06] <Transform Algorithm="http://www.w3.org/2000/11/temp-xmlenc#decryption"> [07] <EncryptedReference xmlns="http://www.w3.org/2000/11/temp-xmlenc" 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 xmlns="http://www.w3.org/2000/11/temp-xmlenc" Id="enc2">...</EncryptedData> [23] <EncryptedData xmlns="http://www.w3.org/2000/11/temp-xmlenc" 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.
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.