Copyright ©2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document specifies the "decryption transform", which enables XML Signatures verification even if both signature and encryption operations are performed on an XML document.
This is the Last Call for the "Decryption Transform for XML Signature" Working Draft from the XML Encryption Working Group (Activity Statement). This version represents a consensus towards satisfying the requirement of partially signing and encrypting XML documents. The last call period is 3 weeks, ending on 9 November 2001.
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.
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, Alice wishes to order and pay for a book from Bob using the mutually trusted payment system ZipPay. Bob creates an order form including the book title, price and his account info. He wants to sign all of this information, but will subsequently encrypt his account info for ZipPay only. He sends this to Alice who affirms the book title and price, signs the form and presents the twice-signed order with her own payment information to ZipPay. Two validate both signatures ZipPay will have to know that the cipher data version of the encrypted information is necessary for validating Alice's signature, but the plain data form is necessary for validating Bob's signature. (See Sign What You See (section 6) for more on signing encrypted data.)
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.
This document makes use of the XML Encryption [XML-Encryption] and XML Signature [XML-Signature] namespaces, and defines it own, with the following prefixes:
xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dcrpt="http://www.w3.org/2001/04/decrypt#"
While applications MUST support XML and XML namespaces, the use of our
"enc
", "ds
", and "dcrpt
" XML namespace
prefixes is OPTIONAL; we use this facility to provide compact and readable
exposition.
This transform takes as a parameter a set of references to encrypted
portions that are not to be decrypted by the transform. These references are
expressed by the dcrpt:Except
elements that appear as direct
child elements of the ds:Transform
element. The value of the
URI
attribute of the dcrpt:Except
element MUST be a
non-empty same-document URI reference [URI]
(i.e., a number sign ('#') character followed by a fragment identifier) and
identify an enc:EncryptedData
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].
The transform decrypts all the enc:EncryptedData
elements (as
defined in the forthcoming XML Encryption standard [XML-Encryption])
except for those specified by dcrpt:Except
elements. The output
of the transform is also a node-set.
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='optional'/> </complexType>
This section describes the processing rules of the transform. The rules
are written as two functions, whereas the inputs and outputs of the transform
are the inputs and outputs of the noDecryptNodes()
function,
which itself calls Decypt()
. The processing rules and functions
are conceptual only and do not mandate any particular implementation.
[Definition: Let X be a node-set. Let e be the first element node in X. A parsing context of X consists of the following items:
dcrpt:Except
elements specified as a parameter of the
transform.URI
attributes of all the
dcrpt:Except
elements in R in the context of
X. N is a set of enc:EncryptedData
element
nodes in X referenced by the elements.This transform performs the following steps:
dcrpt:Except
elements given as a parameter of the
transform.enc:EncryptedData
, 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.
[Definition: A node-set is said to be single-rooted if and only if all of its member nodes are either (1) the first node in the node-set in the document order, (2) a descendant node of the first node, or (3) an attribute node or a namespace node of another node in this node-set.]
During the above steps, X MUST always be a single-rooted node-set. If X is not single-rooted, this transform MUST fail.
enc:EncryptedData
in X, and C is a
parsing context of X.<dummy>
and
</dummy>
) as described in [Tobin],
and if needed, prepend the octets representing an XML declaration
and a document type declaration. In order to parse the octet stream
in the context of C, all the namespace declarations in
C MUST be added to the dummy element. Also all the entity
declarations in C MUST be added to the document type
declaration.Note: Condition places certain restrictions on the use of this transform.
First, the input to the transform MUST be single-rooted. Second, if the first
node of the inpassumeut is an element node with the type
enc:EncryptedData
, the decrypted octet stream MUST be of type
http://www.w3.org/2001/04/xmlenc#Element. These restrictions are necessary to
ensure that the decrypted octet stream is parsed correctly in a given parsing
context.
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 a signature being
validated. However, it is unclear how the 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 a 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.
A ds:Transform
element can be created by the following
steps:
enc:EncryptedData
, create an dcrpt:Except
element referencing the node.ds:Transform
element, including the algorithm
identifier of this transform and all the dcrpt:Except
elements created in Step 3.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/decrypt#"> [07] <Except URI="#enc1" xmlns="http://www.w3.org/2001/04/decrypt#"/> [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 Except
element ([07]
).
After decrypting the EncryptedData
in line [22]
,
the order
element is canonicalized and signature-verified.
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.
This specification serves scenarios in which a person might sign encrypted data. Because [XML-Signature] has only a simple semantic whereby a key is associated with some data -- and nothing more -- the signing of encrypted data is a legitimate process. For example, someone might run a content-neutral time stamp service that will sign any data sent to it with its timestamping key under the semantic, "I received this on $date $time." However, applications often explicitly or implicitly associate more substantive semantics (e.g., authorizes, agrees, authors) with a signature. No one should be asked to apply a signature and its semantic to data he or she did not see. Just as the principles of Only What is 'Seen' Should be Signed and 'See' What is Signed are important for understanding the import of an XML Signature, they are doubly important when semantics are associated with that signature: one MUST NOT infer that a signature over encrypted data is also a signature over its plain text form, nor that the meaning of that signature over the encrypted data also applies to the plain text. If one wishes to sign the plain text form of data which is later encrypted, use the transform specified in this document!