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
signature (and must not be decrypted) and those that were encrypted
after the signature (and must be decrypted) for the signature to
properly validate.
Status of this document
This is an editors' draft with no official standing.
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.
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 policy.
- Introduction
- Purpose
- Editorial Conventions
- Decryption Transform
- Processing Rules
-
- Functions
- Restrictions and Limitations
- Transform Creation (Non-Normative)
- Example
- Security Considerations
- Signatures Over Encrypted Data May
Reveal Information
- "Sign What You See"
- References
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.
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.
- Identifier:
-
http://www.w3.org/2001/04/decrypt#
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
, defined below via XML Schema [XML-Schema], that appear 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 a fragment identifier) or
XPointer expression and identify an
enc:EncryptedData
or enc:EncryptedKey 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
The Reference Processing Model (section 4.3.3.2) 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" [
<!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>
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 e, the first element node in X.
[is this e different than that in decryptIncludedNodes?
-JR]
- Name and value of each entity
[is this the formal definion from xml1.0 -JR] that is
effective for the XML document causing X.
- 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:
- 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.
- Let C be a parsing context of X.
- 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).
- 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:
- 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].
- 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.
- 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].
- 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.
- 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).)
These restrictions are necessary to ensure that the decrypted
octet stream is parsed correctly in a given parsing context.
- 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.
- 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.
- 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 an advisory.
A ds:Transform element can be created by the
following steps:
- Apply all the transforms being placed before this transform to
a data object being signed.
- 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].
- 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.
- Create a
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 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.
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.
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!
- Finney
- Hal Finney.
Re: Combining signing and encrypting, XML Encryption mailing
list, 2000.
http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0064
- Herzberg
- Amir Herzberg.
Signing encrypted data, XML Encryption mailing list,
2001.
http://lists.w3.org/Archives/Public/xml-encryption/2001Mar/0025
- Keywords
- Scott Bradner. Key
words for use in RFCs to Indicate Requirement Levels, RFC 2119,
1997.
http://www.ietf.org/rfc/rfc2119.txt
- Reagle
- Joseph Reagle.
Re: Signing and Encryption, XML Encryption mailing list,
2001.
http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0100
- Solo
- David Solo.
Combining signing and encrypting, XML Encryption mailing list,
2000.
http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0058
- Tobin
- Richard Tobin.
Infoset for external entities, XML Core mailing list,
2000.
http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000OctDec/0054
[W3C Member
Only]
- 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
- John Boyer. Canonical XML
Version 1.0, W3C Rec., 2001.
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
-
XML-Encryption
- Donald Eastlake and Joseph Reagle. XML Encryption
Syntax and Processing, W3C Working Draft, 2001.
http://www.w3.org/TR/2001/WD-xmlenc-core-20011018
- XML-Schema
- Henry Thompson, David Beech, Murray Maloney, and Noah
Mendelsohn. XML Schema
Part 1: Structures, W3C Rec., 2001.
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502
Paul Biron and Ashok Malhotra. XML Schema
Part 2: Datatypes, W3C Rec., 2001.
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502
-
XML-Signature
- Donald Eastlake, Joseph Reagle, and David Solo. XML-Signature
Syntax and Processing, W3C Proposed Rec., 2001.
http://www.w3.org/TR/2001/PR-xmldsig-core-20010820
- XPath
- James Clark and Steve DeRose. XML Path Language
(XPath) Version 1.0, W3C Rec., 1999.
http://www.w3.org/TR/1999/REC-xpath-19991116