Decryption Transform for XML Signature

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

1. Introduction
   1. Purpose
   2. Editorial Conventions
2. Decryption Transform
   1. Processing Rules
   2. 1. Functions
      2. Restrictions and Limitations
3. Transform Creation (Non-Normative)
4. Example
5. Security Considerations
   1. Signatures Over Encrypted Data May Reveal Information
   2. "Sign What You See"
6. References

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", "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:

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.

2 Decryption Transform

Identifier:

http://www.w3.org/2001/04/decrypt#

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 enc:EncryptedData elements [XML-Encryption] 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 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 (as profiled by [XML-Signature, Section 4.3.3.2])) and identify an enc:EncryptedData within the input to this transform.

  Schema Definition:

  <?xml version="1.0" encoding="utf-8"?>
  <!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN"
    "http://www.w3.org/2001/XMLSchema.dtd" [
    <!ATTLIST schema
      xmlns:dt CDATA #FIXED "http://www.w3.org/2001/04/decrypt#">
    <!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="required"/>
    </complexType>
  </schema>

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 the inputs and outputs of the decryptIncludedNodes() function, which itself calls decypt().

The transform operates over a node-set X, and its parsing context , which consists of the following items:

• Prefix and namespace name of each namespace that is in scope for the first element node in X.
• Name and value of each general entity that is effective for the XML document causing X.

2.1.1 Functions

Z = decryptIncludedNodes(X, R)

where X is a node-set and R is a set of dcrpt:Except elements specified as a parameter of the transform. Z is a node-set obtained by the following steps:

1. Within X, select e, an element node with the type enc:EncryptedData, such that is not referenced by any dcrpt:Except elements in R. If such e cannot be selected, the algorithm terminates and Z, the result of the transformation, is X.
2. Let C be a parsing context of X.
3. Let Y be decrypt(X, e, C). If this function succeeds, replace X with Y. Otherwise, the implementation MAY signal a failure of the transform. Alternatively, it MAY also continue processing without changing X (although it should take an appropriate means to avoid an infinite loop).
4. Go to Step 1.

Y = decrypt(X, e, C)

where X is a node-set, e is an element node with the type enc:EncryptedData in X, and C is a parsing context of X.

Y is a node-set obtained by the following steps:

1. Convert X to an octet stream as described in The Reference Processing Model (section 4.3.3.2) of the XML Signature specification [XML-Signature].
2. Wrap the resulting octet stream with the octets representation of dummy tags (i.e., <dummy> and </dummy>) as proposed by Richard Tobin 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.
3. Decrypt the element corresponding to e (which may require parsing) and replace it with the resulting octet stream according to the XML Encryption specification [XML-Encryption].
4. Parse the decrypted octet stream as described in The Reference Processing Model (section 4.3.3.2) of the XML Signature specification [XML-Signature], resulting in a node-set.
5. Y is the node-set obtained by removing the root node, the dummy element node, and its associated set of attribute and namespace nodes from the node-set obtained in Step 4.

If any of the above steps fails for whatever reasons (e.g., the decryption key cannot be located, parsing in Step 4 fails, etc.), this function also fails.

(In decrypt(X, e, C), all of the steps except the actual decryption are necessary because XPath does not permit one to remove and then replace a node. Consequently, we must serialize (1), wrap (2), reparse (4), and trim the node set (5).)

2.1.2 Restrictions and Limitations

These restrictions are necessary to ensure that the decrypted octet stream is parsed correctly in a given parsing context.

1. During the above steps, X MUST always be a single-rooted node-set. If X is not single-rooted, this transform MUST fail. 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.
2. If the first node of the input 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.
3. This transform does not include enc:EncryptedKey elements within its scope of specifically indicating elements, and their exceptions, that should be decrypted. An enc:EncryptedKey that exists as a descendent of enc:EncryptedData might be decrypted and will be removed from the original document as part of processing its ancestor enc:EncryptedData with this transform. However, a lone enc:EncryptedKey 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 enc:EncryptedKey elements always be children of an enc:EncryptedData's ds:KeyInfo when they fall within the scope of a signature.

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.

A ds:Transform element can be created by the following steps:

1. Apply all the transforms being placed before this transform to a data object being signed.
2. If the transform just before this transform outputs an octet stream, convert it to a node-set as described in The Reference Processing Model (section 4.3.3.2) of the XML Signature specification [XML-Signature].
3. For each node in the node-set, if the node is an element node with the type enc:EncryptedData, create an dcrpt:Except element referencing the node.
4. Create a ds:Transform element, including the algorithm identifier of this transform and all the dcrpt:Except elements created in Step 3.

4 Example

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/2001/04/xmlenc#"
           Id="enc1">...</EncryptedData>
  [13] </order>

In order to let the recipient know the proper order of decryption and signature verification, the signer includes 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 xmlns="http://www.w3.org/2001/04/decrypt#"
                   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/2001/04/xmlenc#"
               Id="enc2">...</EncryptedData>
  [23]       <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
               Id="enc1">...</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 canonicalization ([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.

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!

6 References

Finney

H. Finney. Re: Combining signing and encrypting, XML Encryption mailing list, 2000.

http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0064

Herzberg

A. Herzberg. Signing encrypted data, XML Encryption mailing list, 2001.

http://lists.w3.org/Archives/Public/xml-encryption/2001Mar/0025

Keywords

S. Bradner. Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, 1997.

http://www.ietf.org/rfc/rfc2119.txt

Reagle

J. Reagle. Re: Signing and Encryption, XML Encryption mailing list, 2001.

http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0100

Solo

D. Solo. Combining signing and encrypting, XML Encryption mailing list, 2000.

http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0058

Tobin

R. Tobin. Infoset for external entities, XML Core mailing list, 2000 [W3C Member Only].

http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000OctDec/0054

URI

T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax, RFC 2396, 1998.

http://www.ietf.org/rfc/rfc2396.txt

XML-C14N

J. Boyer. Canonical XML Version 1.0, W3C Recommendation, 2001.

http://www.w3.org/TR/2001/REC-xml-c14n-20010315

XML-Encryption

D. Eastlake and J. Reagle. XML Encryption Syntax and Processing, W3C Candidate Recommendation, 2002.

http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/

XML-Schema

H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn. XML Schema Part 1: Structures, W3C Recommendation, 2001.

http://www.w3.org/TR/2001/REC-xmlschema-1-20010502

P. Biron and A. Malhotra. XML Schema Part 2: Datatypes, W3C Rec., 2001.

http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

XML-Signature

XML-Signature Syntax and Processing. D. Eastlake, J. Reagle, and D. Solo. W3C Recommendation, February 2002. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

XPath

J. Clark and S. DeRose. XML Path Language (XPath) Version 1.0, W3C Recommendation, 1999.

http://www.w3.org/TR/1999/REC-xpath-19991116