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 [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 output of
the transform is a node-set or octet stream, depending on the
input.
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 xenc: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>
This section describes the processing rules of the transform. The rules are written as three functions; the inputs and outputs of the transform are the inputs and outputs of the decryptIncludedNodes() function, which itself calls the decryptXML() or decryptOctets() function.
The transform operates over a node-set X, and its parsing context , which consists of the following items:
The decryptIncludedNodes() also takes a set of
dcrpt:Except
elements that identify
xenc:EncryptedData
elements that should not be processed by this
transform. When dereferencing dcrpt:Except
URIs, the application
MUST behave as if the root document node of the input node set is used to
initialize the [XPointer] evaluation context, even if
this node is not part of the node set. Unlike [XML-Signature], the URI may be evaluated against a
different document from the signature document. If the input is a different
document then, as per [XPointer], use of the here() function is
an error.
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:
xenc:EncryptedData
, such that it 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.
Type
attribute of e is &xenc;Element or &xenc;Content:
Type
attribute is absent or otherwise
indicates octets:
where X is a node-set, e is an element node with the type
xenc:EncryptedData
in X, and C is a parsing context of X.
Y is a node-set obtained by the following steps:
<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.
(In decryptXML(), 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).)
where X is a node-set and e is an element node
with the type xenc:EncryptedData
in X.
Y' is an octet stream obtained by the following steps:
If any of the above steps in decryptXML() or decryptOctets() fails for whatever reasons (e.g., the decryption key cannot be located, parsing fails, etc.), the function also fails.
These restrictions are necessary to ensure that the transform is performed correctly.
xenc:EncryptedData
element node being
decrypted is the first node in X, the value of its
Type
attribute MUST NOT be
&xenc;Content.
Otherwise, the value MUST be &xenc;Element
or &xenc;Content.
xenc:EncryptedKey
elements within
its scope of specifically indicating elements, and their exceptions, that
should be decrypted. An xenc:EncryptedKey
that exists as a
descendent of xenc:EncryptedData
might be decrypted and will be
removed from the original document as part of processing its ancestor
xenc:EncryptedData
with this transform. However, a lone
xenc: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 xenc:EncryptedKey
elements
always be children of an xenc:EncryptedData
's
ds:KeyInfo
when they fall within the scope of a signature.