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.
This document is the W3C Decryption Transform for XML Signature Recommendation
(REC). This document has been reviewed by W3C Members and other
interested parties and has been endorsed by the Director as a W3C
Recommendation. It is a stable document and may be used as reference material
or cited as a normative reference from another document. W3C's role in making
the Recommendation is to draw attention to the specification and to promote
its widespread deployment. This enhances the functionality and
interoperability of the Web.
This specification was produced by the W3C XML Encryption Working
Group (Activity) which
believes the specification is sufficient for the creation of independent
interoperable implementations as demonstrated in the Interoperablity
Report.
Patent disclosures relevant to this specification may be found on the
Working Group's patent disclosure
page in conformance with W3C policy.
Pleae report errors in this document to [email protected] (public
archive).
The list of known errors in this specification is available at http://www.w3.org/Encryption/2002/12-xmlenc-decrypt-errata.
The English version of this specification is the only normative version.
Information about translations of this document (if any) is available http://www.w3.org/Encryption/2002/12-xmlenc-translations.
A list of current W3C Recommendations and other technical documents can be
found at http://www.w3.org/TR/.
- Introduction
- Purpose
- Editorial Conventions
- Acknlowledgments
- Decryption Transform Syntax
- XML-Mode Decryption Transform
- Processing Rules
- Transform Creation
(Non-Normative)
- Example
- Restrictions and Limitations
- The Constraint of Well-Formed
Data
- Inheriting Attributes
from the XML Namespace
- References and
Structural Changes
- References and
Super-Encryption
- References Using
Non-barename XPointers
- Interactions with Other
Filters
- EncryptedKey is Out of
Scope
- Binary-Mode Decryption Transform
- Processing Rules
- 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", "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:
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:dcrpt="http://www.w3.org/2002/07/decrypt#"
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".
The contributions of the following Working Group participants to this
specification are gratefully acknowledged:
- Hal Finney, PGP Security
- Amir Herzberg, NewGenPay
- Takeshi Imamura, IBM
- Ari Kermaier, Phaos
- Hiroshi Maruyama, IBM
- Joseph Reagle, W3C
- David Solo, Citigroup
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].
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/2002/07/decrypt#">
<!ENTITY % p ''>
<!ENTITY % s ''>
]>
<schema xmlns="http://www.w3.org/2001/XMLSchema" version="0.1"
xmlns:dt="http://www.w3.org/2002/07/decrypt#"
targetNamespace="http://www.w3.org/2002/07/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>
- Identifier:
- http://www.w3.org/2002/07/decrypt#XML
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.
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.
- O =
decryptXML(N, E)
where N is a node-set and E is a set of
exception URIs held by URI attributes of
dcrpt:Except elements. O is a node-set, computed
as follows:
- Let Y, a set of replacement node-sets,
be decryptNodeSet(N, E).
- Canonicalize-with-Replacement:
convert N to an octet stream B, (which MUST be well-formed (see section 3.4.1)), using
[XML-C14N]
as described in The
Reference Processing Model [XML-Signature, section 4.3.3.2]; but, in
place of any decrypted
xenc:EncryptedData element
d and its descendants, process the replacement node-set
Od, from Y. During
this step, canonicalization of the replacement node-set MUST be augmented (see section
3.4.2) as follows:
- A namespace declaration
xmlns="" MUST be emitted
with every apex
element that has no namespace node declaring a value for the
default namespace as described in Serializing
XML [XML-Encryption, section
4.3.3].
- If a node-set is replacing an element from N whose
parent element is not in N, then its apex elements
MUST inherit attributes associated with the XML namespace
from the parent element., such as
xml:base,
xml:lang and xml:space.
B may not be in canonical form.
- Let O, the output of this function, be a node-set
converted from B as described in The
Reference Processing Model [XML-Signature, section 4.3.3.2].
- If parsing of B fails, then the implementation MUST
signal a failure of the transform.
- Note that even if there are no decrypted
xenc:EncryptedData elements, then N is
still canonicalized and parsed.
- Y = decryptNodeSet(N, E)
where N is a node-set and E is a set of
exception URIs held by URI attributes of
dcrpt:Except elements. Y is a
set of node-sets, computed as follows:
- Let D be a node-set containing all element nodes in
N with the type
xenc:EncryptedData that are
not identified by any exception URI in E.
- When dereferencing an exception URI in the context
of the original input node set, the implementation MUST behave
as if the document node of the input node-set is used to
initialize the XPointer evaluation context [XPointer], even if the node is not part of
the node-set. Unlike XML Signature [XML-Signature], the exception URI may
be evaluated against a different document than the "root node
of the XML document containing the URI attribute." If the input
is a different document then, as per XPointer [XPointer], use of the here() function is an error.
- When dereferencing an exception URI in the context
of a replacement node-set, bare name [XPointer] exception URIs are used to
locate
xenc:EncryptedData elements with matching
Id attributes. Implementors MAY attempt to resolve
full XPointers into replacement node-sets using appropriate
techniques to take into account the location of the replacement
node-set in the input document, see References Using
Non-barename XPointers (section 3.4.5).
- If an exception URI fails to dereference any nodes,
then the resulting error MUST be ignored; it may be the result
of part of the input document being encrypted.
- Let Y be {}, an empty set.
- For each
xenc:EncryptedData element d from
D:
- Decrypt d, without regard for which, if any, of its
descendants are in N, and process it in accordance
with the value of its
Type attribute, resulting in
a node-set Od.
- For example, processing of an
xenc:EncryptedData element with the
Type attribute whose value is &xenc;Element
or &xenc;Content
is specified in A
Decrypt Implementation (section 4.3.1) of [XML-Encryption], and the result
is a node-set.
- If the
Type attribute is absent, is not
known to the decryptor, or the result of its processing is
not a node-set, then the implementation MUST signal a
failure of the transform.
- If decryption of any
xenc:EncryptedData
element fails, then the implementation MUST signal a
failure of the transform.
- Replace Y with
Y ∪ {Od}.
- If Od contains
xenc:EncryptedData that are not in E,
replace Y with
Y ∪ decryptNodeSet(Od, E). This
recursively decrypts super-encrypted
data within the replacement node-set.
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:
- 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 [XML-Signature, section 4.3.3.2].
- For each node in the node-set, if the node is an element node with the
type
xenc: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 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.
[01] <Document>
[02] <ToBeSigned Id="tbs">
[03] <Part number="1">
[04] <Data>...</Data>
[05] <xenc:EncryptedData Id="#secret-1" .../>
[06] </Part>
[07] <Part number="2">
[08] <Data>...</Data>
[09] </Part>
[10] <Secrets>
[11] <xenc:EncryptedData .../>
[12] <xenc:EncryptedData .../>
[13] </Secrets>
[14] </ToBeSigned>
[15] </Document>
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.
[a01] <Document>
[a02] <ToBeSigned Id="tbs">
[a03] <Part number="1">
[a04] <Data>...</Data>
[a05] <xenc:EncryptedData Id="#secret-1" .../>
[a06] </Part>
[a07] <Part number="2">
[a08] <Data>...</Data>
[a09] </Part>
[a10] <Secrets>
[a11] <xenc:EncryptedData .../>
[a12] <xenc:EncryptedData .../>
[a13] </Secrets>
[a14] </ToBeSigned>
[a15] <dsig:Signature ...>
[a16] ...
[a17] <dsig:Reference URI="#tbs">
[a18] <dsig:Transforms>
[a19] <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#XML">
[a20] <dcrpt:Except URI="#secret-1"/>
[a21] <dcrpt:Except URI="#xpointer(id('tbs')/Secrets/*)"/>
[a22] </dsig:Transform>
[a23] </dsig:Transforms>
[a24] ...
[a25] </dsig:Reference>
[a26] ...
[a27] </dsig:Signature>
[a28] </Document>
Consider that this document is subsequently encrypted by various
processes, resulting in the following:
[b01] <Document>
[b02] <ToBeSigned Id="tbs">
[b03] <xenc:EncryptedData Id="part-1" Type="&enc;Element" .../>
[b04] <xenc:EncryptedData Id="part-2" Type="&enc;Element" .../>
[b05] <Secrets>
[b06] <xenc:EncryptedData .../>
[b07] <xenc:EncryptedData .../>
[b08] </Secrets>
[b09] </ToBeSigned>
[b10] <dsig:Signature ...>
[b11] ...
[b12] <dsig:Reference URI="#tbs">
[b13] <dsig:Transforms>
[b14] <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#XML">
[b15] <dcrpt:Except URI="#secret-1"/>
[b16] <dcrpt:Except URI="#xpointer(id('tbs')/Secrets/*)"/>
[b17] </dsig:Transform>
[b18] </dsig:Transforms>
[b19] ...
[b20] </dsig:Reference>
[b21] ...
[b22] </dsig:Signature>
[b23] </Document>
Execution of the decryption transform will proceed as follows:
- The input to the transform, N, is a node-set containing the
ToBeSigned element and its children, less comments
([b02-b09]). The parameter to the transform, E, is
a set containing the two exception URIs ([b15,b16]).
- The first exception URI does not resolve in this document; the second
resolves to the two children of the
Secrets element
([b06,b07]).
- As a result, D for N is a node-set consisting of the
two
xenc:EncryptedData elements, dpart-1
([d03]) and dpart-2
([d04]). Each of these is decrypted, resulting in the
following node-sets for Opart-1 and
Opart-2:
[c01] <Part number="1">
[c02] <Data>...</Data>
[c03] <xenc:EncryptedData Id="#secret-1" .../>
[c04] </Part>
[d01] <Part number="2">
[d02] <xenc:EncryptedData Id="#data-2" Type="&enc;Element" .../>
[d03] </Part>
- After this decryption stage, two new
xenc:EncryptedData
elements ([c03] and [d02]) have been revealed.
However, the first matches an exception URI with a bare name and so is
not considered further; hence, D for Opart-1
is empty while D for Opart-2 contains just
the xenc:EncryptedData element ddata-2
([d02]). This is decrypted again, resulting in the following
node-set Odata-2:
[e01] <Data>...</Data>
- No new
xenc:EncryptedData element are revealed, so
D for Odata-2 is empty and processing falls
through to canonicalization.
- The canonicalization-with-replace operation canonicalizes the node-set
N; but, in place of any
xenc:EncryptedData elements
that were decrypted, it canonicalizes the replacement node-sets.
Similarly, it also replaces any decrypted xenc:EncryptedData
elements in the replacement node-sets. Further, canonicalization of any
replacement node-sets is augmented such that xmlns="" is
emitted on any apex elements that have no namespace node declaring a
value for the default namespace. The resulting canonicalized data are the
following:
[f01] <Document>
[f02] <ToBeSigned Id="tbs">
[f03] <Part xmlns="" number="1">
[f04] <Data>...</Data>
[f05] <xenc:EncryptedData Id="#secret-1" .../>
[f06] </Part>
[f07] <Part xmlns="" number="2">
[f08] <Data xmlns="">...</Data>
[f09] </Part>
[f10] <Secrets>
[f11] <xenc:EncryptedData .../>
[f12] <xenc:EncryptedData .../>
[f13] </Secrets>
[f14] </ToBeSigned>
[f15] </Document>
- This octet stream is then parsed and returned as the output of the
transform.
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.
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:
[01] <Document xml:lang="ga">
[02] <ToBeSigned Id="tbs">
[03] ...
[04] </ToBeSigned>
[05] <dsig:Signature ...>
[06] ...
[07] <dsig:Reference URI="#tbs">
[08] <dsig:Transforms>
[09] <dsig:Transform Algorithm="http://www.w3.org/2001/04/decrypt#XML" />
[10] </dsig:Transforms>
[11] ...
[12] </dsig:Reference>
[13] ...
[14] </dsig:Signature>
[15] </Document>
The canonical form of the ToBeSigned element (the target of
the #tbs reference, [02-04]) is the following
([a01-a03]):
[a01] <ToBeSigned Id="tbs" xml:lang="ga">
[a02] ...
[a03] </ToBeSigned>
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]):
[b01] <Document xml:lang="ga">
[b02] <xenc:EncryptedData Id="tbs" ...>
[b03] ...
[b04] </xenc:EncryptedData>
[b05] <dsig:Signature ...>
[b06] ...
Upon decryption, the document that would be parsed to form the replacement
node set would be:
[c01] <dummy><ToBeSigned xmlns="" Id="tbs">
[c02] ...
[c03] </ToBeSigned></dummy>
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.
[d01] <ToBeSigned Id="tbs">
[d02] ...
[d03] </ToBeSigned>
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 from the XML namespace 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], 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.
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.
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]):
[01] <Document>
[02] <ToBeSigned Id="tbs">
[03] <Data>...</Data>
[04] ...
[05] </ToBeSigned>
[06] <dsig:Signature ...>
[07] ...
[08] <dsig:Reference URI="#tbs">
[09] <dsig:Transforms>
[10] <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#XML" />
[11] </dsig:Transforms>
[12] ...
[13] </dsig:Reference>
[14] ...
[15] </dsig:Signature>
[16] ...
[17] </Document>
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]):
[a01] <Document>
[a02] <ToBeSigned Id="tbs">
[a03] <xenc:EncryptedData ...>
[a04] ...
[a05] <dsig:KeyInfo ...>
[a06] <dsig:RetrievalMethod URI="#key-info"
Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey" .../>
[a07] </dsig:KeyInfo>
[a08] ...
[a09] </xenc:EncryptedData>
[a10] ...
[a11] </ToBeSigned>
[a12] <xenc:EncryptedKey Id="key-info" .../>
[a13] <dsig:Signature ...>
[a14] ...
[a15] <dsig:Reference URI="#tbs">
[a16] <dsig:Transforms>
[a17] <dsig:Transform
Algorithm="http://www.w3.org/2002/07/decrypt#XML"/>
[a18] </dsig:Transforms>
[a19] ...
[a20] </dsig:Reference>
[a21] ...
[a22] </dsig:Signature>
[a23] </Document>
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.
[b01] <Document>
[b02] <xenc:EncryptedData Id="tbs" .../>
[b03] <xenc:EncryptedKey Id="key-info" .../>
[b04] <dsig:Signature ...>
[b05] ...
[b06] <dsig:Reference URI="#tbs">
[b07] <dsig:Transforms>
[b08] <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#XML" />
[b09] </dsig:Transforms>
[b10] ...
[b11] </dsig:Reference>
[b12] ...
[b13] </dsig:Signature>
[b14] </Document>
Upon decryption, the document that would be parsed to form the
replacement node set would be:
[d01] <dummy><ToBeSigned Id="tbs">
[d02] <xenc:EncryptedData ...>
[d03] ...
[d04] <dsig:KeyInfo ...>
[d05] <dsig:RetrievalMethod URI="#key-info"
Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"
.../>
[d06] </dsig:KeyInfo>
[d07] ...
[d08] </xenc:EncryptedData>
[d09] ...
[d10] </ToBeSigned></dummy>
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:
[01] <Document>
[02] <ToBeSigned Id="tbs">
[03] <Data>...</Data>
[04] <Secrets>
[05] <xenc:EncryptedData Id="#secret-1" .../>
[06] </Secrets>
[07] </ToBeSigned>
[08] <dsig:Signature ...>
[09] ...
[10] <dsig:Reference URI="#tbs">
[11] <dsig:Transforms>
[12] <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#XML">
[13] <dcrpt:Except URI="#xpointer(/Document/ToBeSigned/Secrets/*)"/>
[14] </dsig:Transform>
[15] </dsig:Transforms>
[16] ...
[17] </dsig:Reference>
[18] ...
[19] </dsig:Signature>
[20] </Document>
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.
[a01] <Document>
[a02] <ToBeSigned Id="tbs">
[a03] <Data>...</Data>
[a04] <xenc:EncryptedData Id="#secrets" .../>
[a05] </ToBeSigned>
[a06] <dsig:Signature ...>
[a07] ...
[a08] <dsig:Reference URI="#tbs">
[a09] <dsig:Transforms>
[a10] <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#XML">
[a11] <dcrpt:Except URI="#xpointer(/Document/ToBeSigned/Secrets/*)"/>
[a12] </dsig:Transform>
[a13] </dsig:Transforms>
[a14] ...
[a15] </dsig:Reference>
[a16] ...
[a17] </dsig:Signature>
[a18] </Document>
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]):
[b01] <dummy>
[b02] <Secrets>
[b03] <xenc:EncryptedData Id="#secret-1" .../>
[b04] </Secrets>
[b05] </dummy>
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.
[01] <Document>
[02] <ToBeSigned For="job">
[03] ...
[04] </ToBeSigned>
[05] <ToBeSigned For="bob">
[06] ...
[07] <xenc:EncryptedData .../>
[08] </ToBeSigned>
[09] </Document>
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
- Identifier:
- http://www.w3.org/2002/07/decrypt#Binary
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 an octet-stream.
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.
- O
= decryptBinary(N, E)
where N is a node-set and E is a set of
exception URIs held by URI attributes of
dcrpt:Except elements. O is an octet stream,
computed as follows:
- Let D be a node-set containing all element nodes in
N with the type
xenc:EncryptedData that are
not identified by any exception URI in E.
- When dereferencing an exception URI, the implementation MUST
behave as if the document node of the input node-set is used to
initialize the XPointer evaluation context [XPointer], even if the node is not part of
the node-set. Unlike XML Signature [XML-Signature], the exception URI may
be evaluated against a different document from the signature
document. If the input is a different document then, as per
XPointer [XPointer], use of the here() function is an error.
- If an exception URI fails to dereference any nodes, then the
resulting error MUST be ignored; it may be the result of part
of the input document being encrypted.
- For each
xenc:EncryptedData element d from
D, decrypt d, without regard for which, if any,
of its descendants are in N, and without consideration of
its Type attribute, resulting in an octet-stream
Od.
- Let O, the output of this transform, be the
concatenation of the octet streams Od, ordered
in the document order of d.
- If there are no
EncryptedData elements in
D, then the result is a zero-length octet stream.
Consider the following example signed document:
<Document>
<xenc:EncryptedData Id="image" MimeType="image/png" ...>
...
<!-- image data -->
...
</xenc:EncryptedData>
<dsig:Signature ...>
...
<dsig:Reference URI="#image">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#Binary" />
</dsig:Transforms>
...
</dsig:Reference>
...
</dsig:Signature>
</Document>
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.
Execution of the decryption transform will proceed as follows:
- The input to the transform, N, is a node set containing the
EncryptedData element and its children, less comments. The
parameter to the transform, E, is empty.
- As a result, D is a node set consisting of the one
EncryptedData element, dimage. This is
decrypted, resulting in an octet string Oimage
containing the plaintext of the binary image.
- There are no other data to decrypt, so the result of this transform is
the plaintext obtained in the previous step. This will be used directly
as input to the digest algorithm.
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.
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
- Re:
Combining signing and encrypting. H. Finney. XML Encryption mailing
list, 2000.
- http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0064
- Herzberg
- Signing
encrypted data. A. Herzberg. XML Encryption mailing list, 2001.
- http://lists.w3.org/Archives/Public/xml-encryption/2001Mar/0025
- Keywords
- RFC 2119: Key words for
use in RFCs to Indicate Requirement Levels. S. Bradner. Best
Current Practices, 1997.
- http://www.ietf.org/rfc/rfc2119.txt
- Reagle
- Re:
Signing and Encryption. J. Reagle. XML Encryption mailing list,
2001.
- http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0100
- Solo
- Combining
signing and encrypting. D. Solo. XML Encryption mailing list,
2000.
- http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0058
- URI
- RFC 2396: Uniform
Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R.
Fielding, and L. Masinter. Standards Track, 1998.
- http://www.ietf.org/rfc/rfc2396.txt
- XML
- Extensible
Markup Language (XML) 1.0 (Second Edition). T. Bray, J. Paoli, C.
M. Sperberg-McQueen, and E. Maler. W3C Recommendation, 2000.
- http://www.w3.org/TR/2000/REC-xml-20001006
- XML-C14N
- Canonical
XML Version 1.0. J. Boyer. W3C Recommendation, 2001.
- http://www.w3.org/TR/2001/REC-xml-c14n-20010315
- XML-exc-C14N
- Exclusive
XML Canonicalization. J. Boyer, D. Eastlake, and J. Reagle. W3C
Recommendation, 2002.
- http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/
- XML-Encryption
- XML
Encryption Syntax and Processing. D. Eastlake and J. Reagle. W3C
Recommendation, 2002.
- http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/
- XML-Schema
- XML
Schema Part 1: Structures. H. Thompson, D. Beech, M. Maloney, and
N. Mendelsohn. W3C Recommendation, 2001.
- http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
- XML
Schema Part 2: Datatypes. P. Biron and A. Malhotra. W3C
Recommendation, 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, 2002.
- http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
- XPath
- XML Path
Language (XPath) Version 1.0. J. Clark and S. DeRose. W3C
Recommendation, 1999.
- http://www.w3.org/TR/1999/REC-xpath-19991116
- XPointer
- XML Pointer
Language (XPointer). S. DeRose, R. Daniel, and E. Maler. W3C
Candidate Recommendation, 2001.
- http://www.w3.org/TR/2001/CR-xptr-20010911/