Decryption Transform for XML Signature

W3C Candidate Recommendation XX Foo 2002

This version:: http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt; $Revision: 1.45 $ on $Date: 2002/05/30 18:59:06 $ GMT by $Author: reagle $
Latest version:: http://www.w3.org/TR/xmlenc-decrypt
Previous version:: http://www.w3.org/TR/2001/WD-xmlenc-decrypt-20011018
Editors: Merlin Hughes <merlin@baltimore.ie>; Takeshi Imamura <imamu@jp.ibm.com>; Hiroshi Maruyama <maruyama@jp.ibm.com>
Contributors: See Acknlowledgements

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

This specification from the XML Encryption Working Group (Activity) is a Candidate Recommendation of the W3C. None of the last call issues on the XML Encryption specifications concerned this specification. Furthermore, the WG considers this specification to be stable and invites implementation feedback during this period.

The exit criteria for this phase is at least two interoperable implementations of this transform with acceptable performance. The interoperability of this specification will be demonstrated as an algorithm in the XML Encryption Syntax and Processing Interoperability Report. We expect to meet all requirements of that report within the two month Candidate Recommendation period (closing April 25). Specific areas where we would appreciate further experience are:

Do implementations achieve satisfactory performance?
Does the specification satisfy application scenario requirements for encrypting and signing portions of XML?

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 (<merlin@baltimore.ie>, <imamu@jp.ibm.com>, and <maruyama@jp.ibm.com>) and cc: the list xml-encryption@w3.org (publicly archived).

Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page in conformance with W3C 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 [XML-Encryption] and XML Signature [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.

1.3 Acknlowledgements

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

2 Decryption Transform

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 (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. dcrpt:Except is defined below via XML Schema [XML-Schema] and appears as direct child elements of the ds:Transform element. The output of the transform is a node-set.

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

2.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 foo() function, which itself calls the bar() function.

2.2 Restrictions and Limitations

3 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 an advisory.

4 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 ([19-22]) in the signature. The dcrpt:Except elements ([20,21]) identify parts of the document that are already encrypted.

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

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 well known by 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 it's 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!