Decryption Transform for XML Signature Version 1.1

Editor's Draft 10 July 2007

This version:: http://www.w3.org/2007/xmlsec/Drafts/xmlenc-decrypt
Latest version:: http://www.w3.org/TR/xmlenc-decrypt11/
Latest Decryption Transform for XML Signature Recommendation:: http://www.w3.org/TR/xmlenc-decrypt
Editors: Merlin Hughes <merlin@baltimore.ie>; Takeshi Imamura <imamu@jp.ibm.com>; Hiroshi Maruyama <maruyama@jp.ibm.com>; Frederick Hirsch <frederick.hirsch@nokia.com> (Version 1.1); Thomas Roessler <tlr@w3.org> (Version 1.1)
Contributors: See ~~Acknlowledgements~~Acknowledgements

Please see the errata for this document, which may include some normative corrections. See also translations.

Abstract

This document specifies an XML Signature "decryption transform" that enables XML Signature applications to distinguish between those XML Encryption structures that were encrypted before signing (and must not be decrypted) and those that were encrypted after signing (and must be decrypted) for the signature to validate.

Status of this document

~~Editor's note: I've given up on change tracking in the SOTD since it's a complete rewrite.~~

This document is an editors' copy that has no official standing.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is both a First Public Working Draft and a Last Call Working Draft of "Decryption Transform for XML Signature Version 1.1." The W3C Membership and other interested parties are invited to review the document and comment through 30 September 2007.

The Working Group is tracking all comments via Bugzilla and highly prefers to receive comments via this system. If access to Bugzilla is not feasible, you may send your comments to the mailing list public-xmlsec-comments@w3.org mailing list (public archive). Each Bugzilla entry and email message should contain only one comment. All comments on this specification should be made following the Description for Issues of the Working Group.

This revision of the Decryption Transform was prepared by the XML Security Specifications Maintenance Working Group to specifically address issues that have occured in the context of inheritance behavior of attributes in the XML namespace. The changes against the Decryption Transform for XML Signature Recommendation are limited to changes necessary to address these issues as well as incorporation of errata. The Working Group expects to advance this Working Draft to Recommendation Status.

Publication as a Working Draft 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 this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

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, 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. To 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 5.2) 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.

1.2 Editorial Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [Keywords].

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

While implementations MUST support XML and XML namespaces, the use of our "xenc", "ds", and "dcrpt" XML namespace prefixes is OPTIONAL; we use this facility to provide compact and readable exposition. Additionally, the entity &xenc; is borrowed from [XML-Encryption] to provide short-hand identifiers for URIs defined in that specification. For example "&xenc;Element" corresponds to "http://www.w3.org/2001/04/xmlenc#Element".

~~1.3 Acknlowledgments~~ 1.3 Acknowledgments

The contributions of the following Working Group participants to this specification are gratefully acknowledged:

2 Decryption Transform Syntax

This transform supports two modes of operation. In XML mode the data is encrypted XML and the result of decryption is a node set. In binary mode the data is an encrypted octet sequence and the result of decryption is an octet sequence. In both modes, xenc:EncryptedData elements in the input node-set can be excluded from processing using dcrpt:Except elements. dcrpt:Except is defined below via XML Schema [XML-Schema] and appears as direct child elements of the ds:Transform element.

The REQUIRED URI attribute value of the dcrpt:Except element identifies xenc:EncryptedData elements within the input to the transform. The value MUST be a non-empty same-document [URI] reference (i.e., a number sign '#' character) followed by an XPointer expression [XPointer] as profiled by The Reference Processing Model [XML-Signature, section 4.3.3.2].

3 XML Mode Decryption Transform

This mode of the 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 (section 4.3.3.2) of the XML Signature specification [XML-Signature]. The transform decrypts all the xenc:EncryptedData elements except for those specified by dcrpt:Except elements. The output of the transform is a node-set.

3.1 Processing Rules

This section describes the processing rules of the transform. The rules are written as two functions; the inputs and outputs of the transform are those of the decryptXML() function, which itself calls the decryptNodeSet() function.

3.2 Transform Creation (Non-Normative)

This specification does not mandate a mechanism for creating a ds:Transform element in a [XML-Signature] transform sequence. However, the following is one (non-normative) approach:

3.3 Example

Suppose that a part of the following XML document ([02-14]) is to be signed. Note that a few parts of the document ([05,11,12]) are already encrypted prior to signature. Also suppose that the signer anticipates that additional parts of the document will be encrypted after signing.

In order to let the recipient know the proper order of decryption and signature verification, the signer includes the decryption transform ([a19-a22]) in the signature. The dcrpt:Except elements ([a20,a21]) identify parts of the document that are already encrypted.

Consider that this document is subsequently encrypted by various processes, resulting in the following:

3.4 Restrictions and Limitations

3.4.1 The Constraint of Well-Formed Data

As specified in step 2 of the decryptXML() function, the octet stream resulting from canonicalization-with-replacement MUST be well-formed. Typically this will be characterized by a single-rooted input node-set, where 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 the node-set. Additionally, if the input node-set has, at its top level, an xenc:EncryptedData element being decrypted, then this SHOULD correspond to an encrypted single-rooted node-set. However, this need not be the case: after decryption, multiple top-level nodes may be well-formed if they consist of white space, comments, processing instructions and a single element. No special processing is required to test for this condition because ill-formed data will result in a parsing error.

3.4.2 Inheriting Attributes from the XML Namespace

As specified in step 2 of the decryptXML() function, the canonicalization with replacement step requires XML namespace attribute inheritance. One of the features of the Canonical XML [XML-C14N] algorithm, which is automatically applied by the decryption transform, is that all ancestral attributes from the XML namespace (e.g., xml:lang) are inherited by any element whose parent node is not in the canonicalized node-set. The inheritance in step 2 ensures these attributes are preserved during decryption and replacement. For example, consider the following signed document:

The canonical form of the ToBeSigned element (the target of the #tbs reference, [02-04]) is the following ([a01-a03]):

Consider, however, if this top-level signed element is subsequently encrypted using an XML serialization algorithm that does not include inherited attributes from the XML namespace ([b02-b04]):

Upon decryption, the document that would be parsed to form the replacement node set would be:

Because this fragment is no longer in its original ancestral context, the canonical form of the resulting ToBeSigned element ([d01-d03]) would not match that which was originally signed and the signature verification operation would fail.

As shown, this failure often occurs when a directly-signed element was encrypted. The remedy is to augment the internal canonicalization of the canonicalization-with-replacement step of decryptXML(): node-sets that are replacing elements whose parent node is not part of the original signed node-set are canonicalized ~~with attributes~~as described in the Canonical XML 1.1 section on ~~Document Subsets [~~Document Subsets [Section 2.4,XML-C14N11]. This provides for inheritance of xml:space and xml:lang from the XML namespace and fixups for xml:base. xml:id is treated as an ordinary attribute. ~~that would have been inherited by the unencrypted element in its original document.~~

While this change is made to maintain the validity of signatures using ~~[XML-C14N]~~[XML-C14N11], it does not interfere with the validity of signatures using [XML-exc-C14N]. This transform, and the inclusion of attributes from the XML namespace (i.e., 'xml:'), is performed during signature validation and generation. Consequently, the exclusively canonicalized form of the element will maintain these 'xml:' attributes — even if the exclusively canonicalized form of the element would not have had them without this transform.

3.4.3 References and Structural Changes

URIs with a full XPointer or child sequence (whether in exceptions, encrypted data or elsewhere) may fail to resolve if encryption results in a structural change to part of the document relied upon by the reference. For example, the URI #xpointer(/ToBeSigned/*[3]) will no longer function if the first two children of the ToBeSigned element are encrypted together. Care SHOULD be taken when employing such references in association with the decryption transform.

3.4.4 References and Super Encryption

Super-encryption may cause problems if a super-encrypted xenc:EncryptedData element uses same-document references, or if an exceptional super-encrypted xenc:EncryptedData element is referenced by a non-bare name XPointer URI. Super-encryption of signed data under these conditions is NOT RECOMMENDED: super-encryption is precluded, or such references should not be used.

As an example of where super-encryption over same-document references may cause problems, consider the following signed document ([02-05]):

If the Data element ([03]) is subsequently encrypted, along with other data elsewhere in the document, the new xenc:EncryptedData element could use a same-document retrieval method to identify shared keying information ([a06]):

If this new xenc:EncryptedData is subsequently super-encrypted ([b02]), the decryption transform will fail: When the inner retrieval method is processed, it will be dereferenced within the context of a new decrypted document that does not contain the referenced keying information.

Upon decryption, the document that would be parsed to form the replacement node set would be:

3.4.5 References Using Non-barename XPointers

As an example of where non-barename XPointers may fail, consider the following signed document ([02-07]) which uses a full XPointer ([13]) to identify data that was already encrypted when the signature was generated ([05]), and so should not be processed by the decryption transform:

If the Secrets element is subsequently encrypted, as shown in the following example ([a04]); i.e., the existing xenc:EncryptedData is super-encrypted, then the XPointer exception URI will no longer resolve. As a result, the decryption transform will attempt to perform super-decryption of the inner xenc:EncryptedData element and processing will fail.

The reason that the full XPointer cannot be processed is that the document which results from decrypting the outer xenc:EncryptedData element will have the following form ([b01-b05]):

3.4.6 Interactions with Other Filters

The XML signature reference processing model allows transforms to remove parts of a node-set undergoing transformation. It is RECOMMENDED that any such transforms appear before the decryption transform. Otherwise, encrypted data that appear in parts of the document that are to be removed and cannot be processed by the recipient will cause the decryption transform to fail.

For example, consider the following document which contains parts that are to be signed for receipt by different individuals. The XPath transform ancestor-or-self::*[@For="job"] selects only the subset [02-04]. If this XPath transform occurs after the decryption transform, and another part of the document contains encrypted data (e.g., [07]), whether created before or after the signature, then the decryption transform may fail to decrypt them and processing will fail. If the XPath transform occurs first, then the encrypted data will not be considered by the decryption transform.

3.4.7 EncryptedKey is Out of Scope

This transform does not include any xenc:EncryptedKey elements within its scope of specifically indicating elements, and their exceptions, that should be decrypted. An xenc:EncryptedKey element that exists as a descendent of xenc:EncryptedData element might be decrypted and will be removed from the original document as part of processing its ancestor xenc:EncryptedData element with the transform. However, a lone xenc:EncryptedKey element will be processed like any other data: a signature is presumed to be over that actual element and not its decrypted form. Consequently, we RECOMMEND that xenc:EncryptedKey elements always be children of an xenc:EncryptedData element's ds:KeyInfo element when they fall within the scope of a signature.

4 Binary Mode Decryption Transform

4.1 Processing Rules

The binary mode of operation is intended for use when generating a signature over binary data that are to be encrypted for transmission to the recipient. Use of this mode of the transform allows a signature to be computed over the plaintext form of the data, rather than the opaque ciphertext. This further allows the ciphertext to be stored elsewhere, identified by a cipher reference, without the need for the signature to take this into account.

This section describes the processing rules of the binary mode of this transform. The inputs and outputs of the transform are those of the decryptBinary() function.

4.2 Example

Much of the encrypted data and signature are elided; the implication of the comment in the encrypted data is that the encrypted content is a binary image.

5 Security Considerations

5.1 Signatures Over Encrypted Data May Reveal Information

When this algorithm is used to facilitate 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 vulnerability 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 known to each other. For example, the signature may not be known of because it is detached. Or, it may be 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 its signature, which may provide information to a subsequent plain text attack on the encrypted B.

5.2 "Sign What You See"

This specification serves scenarios in which a person might sign encrypted data. Because XML Signature [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 time-stamping 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!