Contacts: Please address
This strawman proposal describes how the proposed W3C XML Encryption specification might look and work should the W3C choose to charter an XML Encryption Work Group.
Though it is conceivable that XML Encryption could be used to encrypt any type of data, encryption of XML-encoded data is of special interest. This is because XML's ability to capture the structure and semantics of data unleashes new applications for the area of encryption. To this end, an important design consideration is to not encrypt more of an XML instance's structure and semantics than is necessary.
For example, suppose there is an XML instance containing a list of customers including their names, addresses, and credit card numbers. A contracted marketing employee may be entrusted to see the names and addresses but must not see the credit card number. If an application knows it should just be decrypting the content of <name> elements, the XML instance needs to maintain its structure identifying what is a "name" and what isn't. Otherwise the application would have to decrypt the other data just to find out what it was supposed to be decrypting in the first place which is problematic from both a security and performance point of view.
So what level of granularity is needed? XML's document model provides access to a number of node types including elements, attributes, processing instructions, comments, and text nodes. However, because elements and attributes are the nodes intended for defining structure and semantics, the XML Encryption model (illustrated in the following examples) restricts itself to handling those. (Question to the XML Encryption list: should more types of nodes be supported.)
The centerpiece of XML Encryption is the <EncryptedNode> element. It has an attribute, NodeType, which indicates the type of node that was encrypted: element, element content, attribute, or attribute value. The encrypted node appears as a base64-encoded string which forms the content of the <EncryptedNode> element.
Algorithm and keying information are captured in the <EncryptionInfo> element. Each <EncryptedNode> element has an associated <EncryptionInfo> element. The association my be accomplished by either
When encrypting, applications create the <EncryptionInfo> element to store the information necessary for decryption. Multiple <EncryptedNode> elements may share a single <EncryptionInfo> element.
In addition to node-wise encryption, XML Encryption also supports the basic scenario in which one or more arbitrary objects needs to be stored in encrypted form. For example, an application might wish to use XML Encryption to secure an SVG image, a GIF image, a PDF file, a CSS stylesheet, an XML fragment, and a whole XML document. To this end, XML Encryption defines the top-level <Encryption> element which has two child elements: the <EncryptedNodes> element for holding one or more <EncryptedNode> elements and the <EncryptionInfos> element for holding one or more <EncryptedInfo> elements. Each <EncryptedNode> element contains the encrypted data for one object. (An <Encryption> element may contain only an <EncryptedNodes> element or only an <EncryptedInfos> element.)
As discussed below, the <Encryption> element can also be used by applications that prefer to isolate the encrypted nodes from the remaining XML plaintext.
The examples in this section illustrate how XML Encryption would work in a variety of scenarios.
Scenario: an application wants to keep secret all details of an element, even the element's name.
The plaintext:
<root> ... <ElementToBeEncrypted Attr1="Value1" Attr2="Value2" ...> ... </ElementToBeEncrypted> ... </root>
when secured becomes
<root>
...
<EncryptionInfo xmlns="http://www.w3.org/2001/03/Encryption
Id="encryptionInfo23"...>
(<see "The <EncryptionInfo> element" for details)
<EncryptionInfo>
...
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="Element"
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted Element node)
</EncryptedNode>
...
</root>
The value that is encrypted are the bytes of the stringified version of the element starting from the element's initial "<" to its final ">". See Before encryption, are the values canonicalized and/or serialized? for more discussion.
Scenario: As mentioned earlier, in many applications it makes sense NOT to unnecessarily encrypt the structure and semantics of an XML instance. In this case, an application wants to keep secret just the content of an element.
The plaintext:
<root> ... <Element Attr1="Value1" Attr2="Value2" Attr3="Value3"> ... </Element> ... </root>
when secured becomes
<root>
...
<EncryptionInfo xmlns="http://www.w3.org/2001/03/Encryption
Id="encryptionInfo23"...>
(<see "The <EncryptionInfo> element" for details)
<EncryptionInfo>
...
<Element Attr1="Value1" Attr2="Value2" Attr3="Value3">
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="ElementContent"
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted element content)
</EncryptedNode>
</Element>
...
</root>
The value that is encrypted are the bytes of the stringified version of the element's content starting inclusively from the first child node to the last. See Before encryption, are the values canonicalized and/or serialized? for more discussion.
Scenario: An application wants to secure both the names and values of certain attributes.
The plaintext:
<root> ... <Element Attr1="Value1" Attr2Secret="Value2" Attr3Secret="Value3"> ... </Element> ... </root>
when secured becomes
<root>
...
<EncryptionInfo xmlns="http://www.w3.org/2001/03/Encryption
Id="encryptionInfo23"...>
(<see "The <EncryptionInfo> element" for details)
<EncryptionInfo>
...
<Element Attr1="Value1">
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="Attribute"
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted attribute Attr2Secret)
</EncryptedNode>
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="Attribute"
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted attribute Attr3Secret)
</EncryptedNode>
(element content goes here)
</Element>
...
</root>
The value that is encrypted are the bytes of the stringified version of the attribute starting with the attribute name up to the terminating quotation mark bounding the attribute's value. See Before encryption, are the values canonicalized and/or serialized? for more discussion.
When an <EncryptedNode> element has a NodeType attribute with value "Attribute", the encrypted attribute belongs to the parent of the <EncryptedNode> element.
Scenario: An application wants to secure both the values, but not the names, of certain attributes.
The plaintext:
<root> ... <Element Attr1="Value1" Attr2="Value2Secret" Attr3="Value3Secret"> ... </Element> ... </root>
when secured becomes
<root>
...
<EncryptionInfo xmlns="http://www.w3.org/2001/03/Encryption
Id="encryptionInfo23"...>
(<see "The <EncryptionInfo> element" for details)
<EncryptionInfo>
...
<Element Attr1="Value1"
Attr2="(base64 of encrypted Value2Secret)"
Attr3="(base64 of encrypted Value3Secret)">
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="AttributeValue(Attr2)"
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted attribute Value2Secret)
</EncryptedNode>
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="AttributeValue(Attr3)"
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted attribute Value3Secret)
</EncryptedNode>
(element content goes here)
</Element>
...
</root>
The value that is encrypted are the bytes of the stringified version of the attribute's value starting immediately after the initial bounding quotation mark and including all text (including whitespace) up to the terminating, bounding quotation mark. See Before encryption, are the values canonicalized and/or serialized? for more discussion.
When an <EncryptedNode> element has a NodeType attribute with value "AttributeValue(attrName)", the encrypted attribute value belongs to the attribute with the name specified by attrName in the parent of the <EncryptedNode> element.
Scenario: This example illustrates how XML Encryption supports the encryption of a variety of nodes within a single element.
The plaintext:
<root> ... <Element Attr1="Value1" Attr2="Value2Secret" Attr3Secret="Value3"> ... </Element> ... </root>
when secured becomes
<root>
...
<EncryptionInfo xmlns="http://www.w3.org/2001/03/Encryption
Id="encryptionInfo23"...>
(<see "The <EncryptionInfo> element" for details)
<EncryptionInfo>
...
<Element Attr1="Value1"
Attr2="(base64 of encrypted Value2Secret)"
Attr3="(base64 of encrypted Value3Secret)">
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="AttributeValue(Attr2)"
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted attribute Value2Secret)
</EncryptedNode>
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="Attribute"
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted attribute Attr3Secret)
</EncryptedNode>
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="ElementContent"
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted element content)
</EncryptedNode>
</Element>
...
</root>
If an application prefers it can specify the <EncryptionInfo> element inline rather than referring to it through the <EncryptedNode>'s EncryptionInfo attribute. In this case, do not specify the EncryptionInfo attribute and specify the <EncryptionInfo> element as the first child of the <EncryptedNode> element. When inline, the <EncryptionInfo> element's Id attribute becomes optional. For example...
<root>
...
<Element Attr1="Value1"
Attr2="(base64 of encrypted Value2Secret)">
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="AttributeValue(Attr2)"> <!-- uses child EncryptionInfo element -->
<EncryptionInfo...>
(<see "The <EncryptionInfo> element" for details)
<EncryptionInfo>
(Base64 of encrypted attribute Value2Secret)
</EncryptedNode>
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="Attribute"> <!-- uses child EncryptionInfo element -->
<EncryptionInfo Id="encryptionInfo37"...>
(<see "The <EncryptionInfo> element" for details)
<EncryptionInfo>
(Base64 of encrypted attribute Attr3Secret)
</EncryptedNode>
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="ElementContent"
EncryptionInfo="#encryptionInfo37"> <!-- uses previous sibling's child EncryptionInfo element -->
(Base64 of encrypted element content)
</EncryptedNode>
</Element>
...
</root>
Good question! The decrypting application must be able to reconstruct the original content including the XML structure and character encoding. When thinking about canonicalization/serialization, it is important to remember that unlike XML Signatures, the canonicalization/serialization process MUST be reversible to the degree that the encrypted value can be restored into a DOM sub-structure consistent with the context's overall DOM structure.
It would seem that the simplest solution is to just construct the string value (described for each scenario) and obtain the bytes to be encrypted according to the XML instance's character encoding (eg. minimal canonicalization). However, IBM's Element-Wise XML Encryption makes some good arguments for requiring a canonicalization and serialization process like the XML Canonicalization used in XML Signatures. As well, XML nodes may need to be both signed AND encrypted so the use of XML Canonicalization (required for XML Signatures) may still need to be handled by the XML Encryption specification even if minimal canonicalization is adequate for encryption-only scenarios. This topic needs to be explored further.
(Compressing XML-encoded data may often be desirable. The proposed XML Encryption Work Group would need to discuss this topic.)
Another possiblity for defining the value of NodeType is use XPath. One advantage of doing so would be that <EncryptedNode> elements would not have to reside inline at the location where the encrypted node was.
First, let's look at an example where XPath is used as the syntax for inline <EncryptedNode> elements. Here's the original version:
<root> ... <ElementToBeEncrypted Attr1="Value1" Attr2="Value2" ...> ... </ElementToBeEncrypted> ... ... <Element Attr1="Value1" Attr2="Value2Secret" Attr3Secret="Value3"> ... </Element> ... </root>
when secured becomes
<root>
...
<EncryptionInfo xmlns="http://www.w3.org/2001/03/Encryption
Id="encryptionInfo23"...>
(<see "The <EncryptionInfo> element" for details)
<EncryptionInfo>
...
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="." <!-- "." indicates the <EncryptedNode> element is right
where the original unencrypted element was -->
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted Element node)
</EncryptedNode>
...
<Element Attr1="Value1"
Attr2="(base64 of encrypted Value2Secret)">
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="../@Attr2" <!-- "../Attr2" indicates the <EncryptedNode> element contains
the encrypted value of the parent element's Attr2 attribute -->
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted attribute Value2Secret)
</EncryptedNode>
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="../@*" <!-- "../@*" indicates the <EncryptedNode> element contains
the encrypted attribute (name and value) of the parent element. -->
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted attribute Attr3Secret)
</EncryptedNode>
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="./node()" <!-- "./node()" indicates the <EncryptedNode> element contains
the encrypted content of the parent element. -->
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted element content)
</EncryptedNode>
</Element>
...
</root>
Some applications may find it particularly advantageous to completely separate the encrypted nodes (along with the associated encryption information) from the original document. For example, a server might send a client an XML document which itself contains
Then, based on the identity of the authenticated user, access to the relevant encrypted nodes would be granted. In cases where the authenticated user only has access to a small portion of references encrypted nodes, or where an authenticated user has wide access but only wishes to view a subset of the encrypted information, detached encrypted nodes may provide significant performance benefits.
Note: Supporting detached encrypted nodes could be particularly useful in access control scenarios and hinder traffic analysis attacks (particularly in the case where the original document contains no hint that there are encrypted nodes associated with it).
As an example of the first scenario where a document contains pointers to encrypted nodes, the referencing document would look like this:
<root>
...
<Element Attr1="Value1">
<EncryptedNodeReference xmlns="http://www.w3.org/2001/03/Encryption"
URI="http://www.agentsinblack.com/secretagents.xml?//EncryptedNode[@Id='2701']"/>
</Element>
...
</root>
and "http://www.agentsinblack.com/secretagents.xml" might look like
<SecretAgents>
...
<Encryption xmlns="http://www.w3.org/2001/03/Encryption>
<EncryptedNodes>
<EncryptedNode
Id="2700"
NodeType="EncryptedContent"
EncryptionInfo="#encryptionInfo00">
(Base64 of encrypted the element)
</EncryptedNode>
<EncryptedNode
Id="2701"
NodeType="EncryptedContent"
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted the element)
</EncryptedNode>
<EncryptedNode
Id="2702"
NodeType="EncryptedContent"
EncryptionInfo="http://www.agentsinblack.com/evenmoreencryptioninfo.xml#encryptionInfo47">
(Base64 of encrypted the element)
</EncryptedNode>
</EncryptedNodes>
<EncryptedInfos>
...
<EncryptionInfo Id="encryptionInfo00"...>
(<see "The <EncryptionInfo> element" for details)
<EncryptionInfo>
...
<EncryptionInfo Id="encryptionInfo23"...>
(<see "The <EncryptionInfo> element" for details)
<EncryptionInfo>
...
</EncryptedInfos>
</Encryption>
...
</SecretAgents>
If the application wished to store <EncryptedInfo> elements in a separate XML instance, a URI would appear ahead of the XPath expression. In contrast to the previous scenario where the primary document points to the <EncryptedNode> elements , each <EncryptedNode> element points to the location where it would be inserted (and decrypted). For example, the primary document (employees.xml) would look like this:
<Employees>
...
<Employee SerialNumber="2701"
Function="secretary">
Name="Alice Ordinary"/>
...
</Employees>
and the XML instance containing the <EncryptedNodes> would look like this:
<SecretAgents>
...
<Encryption xmlns="http://www.w3.org/2001/03/Encryption>
<EncryptedNodes>
<EncryptedNode
NodeType="http://www.agentsinblack.com/employees.xml?//Employee[@SerialNumber='2701']/@RealName"
<!-- This nodetype indicates the <EncryptedNode> element contains
the encrypted ReaName attribute belong to the <SecretAgent> element
with attribute SerialNumber equal to '2701' that is found in the document at
"http://www.agentsinblack.com/employees.xml". -->
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted the element)
</EncryptedNode>
...
</EncryptedNodes>
</XmlEncryption>
...
</SecretAgents>
Suppose an application wants to encrypt an SVG image, a GIF image, a PDF file, a CSS stylesheet, an XML fragment, and a whole XML document. To do so, it creates a top-level <Encryption> element with an <EncryptedNodes> child and an <EncryptedInfos> child (the latter is optional because encryption information need NOT be stored within the parent <Encryption> element).
Then, each object is encrypted, base64ed, and the result is placed within an <EncryptedNode> element that has a NodeType attribute value of "null". (A NodeType attribute value of "null" indicates that the data which was encrypted is not explicitly part of this or another XML instance.) Each <EncryptedNode> element is then placed within the <EncryptedNodes> element. For example,
...
<Encryption xmlns="http://www.w3.org/2001/03/Encryption">
<EncryptedNodes>
<EncryptedNode
NodeType="null"
EncryptionInfo="#encryptionInfo00">
(Base64 of encrypted the encrypted data)
</EncryptedNode>
<EncryptedNode
NodeType="null"
EncryptionInfo="#encryptionInfo23">
(Base64 of encrypted other encrypted data)
</EncryptedNode>
<EncryptedNode
NodeType="null"
EncryptionInfo="http://www.agentsinblack.com/evenmoreencryptioninfo.xml#encryptionInfo47">
(Base64 of encrypted yet other encrypted data)
</EncryptedNode>
</EncryptedNodes>
<EncryptedInfos>
...
<EncryptionInfo Id="encryptionInfo00"...>
(<see "The <EncryptionInfo> element" for details)
<EncryptionInfo>
...
<EncryptionInfo Id="encryptionInfo23"...>
(<see "The <EncryptionInfo> element" for details)
<EncryptionInfo>
...
</EncryptedInfos>
</Encryption>
...
Note: An <Encryption> element containing only an <EncryptionInfos> child is useful for storing the <EncryptionInfo> elements pertaining to one or more external <EncryptionNode> elements.
Data can be signed and then encrypted (or encrypted and then signed) using basic namespace processing rules and, if required, an XML Signature transformation for decrypting. Let's jump right into some examples. Here is an XML Signature that signs an <Object> element.
<root>
...
<Signature xmlns="http://www.w3.org/2000/07/xmldsig#"
Id="X01">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/07/xmldsig#dsa"/>
<Reference URI="#id1">
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/07/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo><KeyValue>...</KeyValue></KeyInfo>
<Object Id="id1">
<doc xmlns="http://www.agentsinblack.com/">
<text>Hello World!</text>
<text>Weight loss secrets of Hollywood stars...</text>
</doc>
</Object>
</Signature>
...
</root>
If the content of the <Object> element is to be encrypted before signing, the resultant Signature would look like this:
<root>
...
<Signature xmlns="http://www.w3.org/2000/07/xmldsig#"
Id="X01">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/07/xmldsig#dsa"/>
<Reference URI="#id1">
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/07/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo><KeyValue>...</KeyValue></KeyInfo>
<Object Id="id1">
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="Element"
EncryptionInfo="http://www.agentsinblack/encryptioninfo.xml#encryptionInfo23">
(Base64 of encrypted Element node)
</EncryptedNode>
</Object>
</Signature>
...
</root>
Now suppose the content of the <Object> element is to be encrypted after signing. To do this, we add an XML Signature <Transform> element that decrypts before signing and/or verification is done. Such an XML Signature would look like this:
<root>
...
<Signature xmlns="http://www.w3.org/2000/07/xmldsig#"
Id="X01">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/07/xmldsig#dsa"/>
<Reference URI="#id1">
<Transforms>
<!-- Note ==> --> <Transform Algorithm="http://www.w3.org/2001/03/Encryption#decrypt">
<!-- Note ==> --> <DecryptTransform xmlns="http://www.w3.org/2001/03/Encryption">
<!-- Note ==> --> <Decrypt Match="//node()"/>
<!-- Note ==> --> <DecryptTransform>
<!-- Note ==> --> </Transform>
<Transform Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/07/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo><KeyValue>...</KeyValue></KeyInfo>
<Object Id="id1">
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="Element"
EncryptionInfo="http://www.agentsinblack/encryptioninfo.xml#encryptionInfo23">
(Base64 of encrypted Element node)
</EncryptedNode>
</Object>
</Signature>
...
</root>
To make things interesting, suppose that where an <EncryptedNode> element refers to whole element, the plaintext form is to be signed and then encrypted but if an <EncryptedNode> element refers to just an element's content, then the encrypted form is to be signed. In the given example, this would mean that the plaintext form of the element
<text>Hello World!</text>
is to be signed and then encrypted and that the content of the element
<text>Weight loss secrets of Hollywood stars...</text>
is to be signed in its encrypted form. Here's what the XML Signature would look like:
<root>
...
<Signature xmlns="http://www.w3.org/2000/07/xmldsig#"
Id="X01">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/07/xmldsig#dsa"/>
<Reference URI="#id1">
<Transforms>
<!-- Note ==> --> <Transform Algorithm="http://www.w3.org/2001/03/Encryption#decrypt">
<!-- Note ==> --> <DecryptTransform xmlns="http://www.w3.org/2001/03/Encryption">
<!-- Note ==> --> <!-- Only decrypt encrypted element nodes; leave other nodes alone -->
<!-- Note ==> --> <Decrypt Match="EncryptedNode[@NodeType='Element']"/>
<!-- Note ==> --> <DecryptTransform>
<!-- Note ==> --> </Transform>
<Transform Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/07/xmldsig#sha1"/>
<DigestValue>...</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo><KeyValue>...</KeyValue></KeyInfo>
<Object Id="id1">
<doc xmlns="http://www.agentsinblack.com/">
<EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="Element"
EncryptionInfo="http://www.agentsinblack/encryptioninfo.xml#encryptionInfo23">
(Base64 of encrypted "<text>Hello World!</text>")
</EncryptedNode>
<text><EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
NodeType="ElementContent"
EncryptionInfo="http://www.agentsinblack/encryptioninfo.xml#encryptionInfo99">
(Base64 of encrypted "Weight loss secrets of Hollywood stars...")
</EncryptedNode></text>
</doc>
</Object>
</Signature>
...
</root>
Of course, the above design also works when the XML Signature <Reference> element's URI attribute points to external data.
This section will describe how the algorithm and keying information necessary for decryption will be encoded.
<EncryptionInfo>
<EncryptionControl type="KeyTrans/KeyAgree/Symkey">
<Originator>
<KeyInfo>..</KeyInfo>
</Originator>
<Algorithm URL="URL">
..alg parameters..
</Algorithm>
<Recipient>
<KeyInfo>
..recipient key info..
</KeyInfo>
</Recipient>
<EncryptedKey>
..base64 encrypted key..
</EncryptedKey>
</EncryptionControl>
</EncryptionInfo>
END