CR-xmlenc-decrypt-20020304 31.3 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
  <title>Decryption Transform for XML Signature</title>
  <style type="text/css">
<!--
/*<![CDATA[*/
u,ins                 { background: white; color: red;}

del,strike,.strike    { background: white; color: silver; text-decoration: line-through;}
code                  {font-weight: normal; }
.link-def             { background: #FFFFFF; color: teal;  font-style: italic;}
.comment              { background: #FFFFF5; color: black; padding: .7em; border:
                        navy thin solid;}
.discuss              { color: blue; background: yellow; }
.xml-example,.xml-dtd { margin-left: -1em; padding: .5em; border: none;}
.xml-dtd              { background: #efeff8; color: black;}
/*]]>*/
-->


  </style>
  <link rel="stylesheet" type="text/css"
  href="http://www.w3.org/StyleSheets/TR/W3C-CR.css" />
</head>

<body xml:lang="en" lang="en">

<div class="head">
<p><a href="http://www.w3.org/"><img height="48" width="72" alt="W3C"
src="http://www.w3.org/Icons/w3c_home" /></a></p>

<h1 class="notoc">Decryption Transform for XML Signature</h1>

<h2 class="notoc">W3C Candidate Recommendation 04 March 2002</h2>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2002/CR-xmlenc-decrypt-20020304">http://www.w3.org/TR/2002/CR-xmlenc-decrypt-20020304</a></dd>
  <dt>Latest version:</dt>
    <dd><a
      href="http://www.w3.org/TR/xmlenc-decrypt">http://www.w3.org/TR/xmlenc-decrypt</a></dd>
  <dt>Previous version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2001/WD-xmlenc-decrypt-20011018">http://www.w3.org/TR/2001/WD-xmlenc-decrypt-20011018</a></dd>
  <dt>Editors</dt>
    <dd>Takeshi Imamura &lt;<a
      href="mailto:imamu@jp.ibm.com">imamu@jp.ibm.com</a>&gt;</dd>
    <dd>Hiroshi Maruyama &lt;<a
      href="mailto:maruyama@jp.ibm.com">maruyama@jp.ibm.com</a>&gt;</dd>
  <dt>Contributors</dt>
    <dd>See <a href="#references">References</a>.</dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">Copyright</a>
© 2002 <a href="http://www.w3.org/"><abbr
title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a
href="http://www.lcs.mit.edu/"><abbr
title="Massachusetts Institute of Technology">MIT</abbr></a>, <a
href="http://www.inria.fr/"><abbr xml:lang="fr" lang="fr"
title="Institut National de Recherche en Informatique et Automatique">INRIA</abbr></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>,
<a
href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document
use</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software
licensing</a> rules apply.</p>
<hr title="Separator from Header" />
</div>

<h2>Abstract</h2>

<p>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.</p>

<h2 class="notoc">Status of this document</h2>

<div class="">
<p>This specification from the <a
href="http://www.w3.org/Encryption/2001/Overview.html">XML Encryption Working
Group</a> (<a
href="http://www.w3.org/Encryption/2001/Activity.html">Activity</a>) is a <a
class="loc"
href="http://www.w3.org/Consortium/Process/Process-19991111/process.html#RecsCR">Candidate
Recommendation</a> of the W3C. None of the <a
href="http://www.w3.org/Encryption/2001/11/last-call-issues.html">last call
issues</a> on the XML Encryption specifications concerned this specification.
Furthermore, the WG considers this specification to be stable and invites
implementation feedback during this period.</p>

<p>The exit criteria for this phase is at least two interoperable
implementations of this transform with acceptable performance. The
interoperability of this specification will be demonstrated as <a
href="http://www.w3.org/Encryption/2002/02-xenc-interop.html#decryption-transform">an
algorithm</a> in the XML Encryption Syntax and Processing <a
href="http://www.w3.org/Encryption/2002/02-xenc-interop.html">Interoperability
Report</a>. We expect to meet all requirements of that report within the two
month Candidate Recommendation period (closing April 25). Specific areas
where we would appreciate further experience are:</p>
<ul>
  <li>Do implementations achieve satisfactory performance?</li>
  <li>Does the specification satisfy application scenario requirements for
    encrypting and signing portions of XML?</li>
</ul>

<p>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 <a
href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p>

<p>Please send comments to the editors (&lt;<a
href="mailto:imamu@jp.ibm.com">imamu@jp.ibm.com</a>&gt;, &lt;<a
href="mailto:maruyama@jp.ibm.com">maruyama@jp.ibm.com</a>&gt;) and cc: the
list <a href="mailto:xml-encryption@w3.org">xml-encryption@w3.org</a>
(publicly <a
href="http://lists.w3.org/Archives/Public/xml-encryption/">archived</a>).</p>

<p>Patent disclosures relevant to this specification may be found on the
Working Group's <a
href="http://www.w3.org/Encryption/2001/Disclosures">patent disclosure
page</a> in conformance with W3C policy.</p>

<h2>Table of Contents</h2>
</div>
<ol>
  <li><a href="#introduction">Introduction</a>
    <ol>
      <li><a href="#purpose">Purpose</a></li>
      <li><a href="#conventions">Editorial Conventions</a></li>
    </ol>
  </li>
  <li><a href="#transform">Decryption Transform</a>
    <ol>
      <li><a href="#processing">Processing Rules</a></li>
      <li style="list-style: none"><ol>
          <li><a href="#functions">Functions</a></li>
          <li><a href="#restrictions">Restrictions and Limitations</a></li>
        </ol>
      </li>
    </ol>
  </li>
  <li><a href="#creation">Transform Creation (Non-Normative)</a></li>
  <li><a href="#example">Example</a></li>
  <li><a href="#security">Security Considerations</a>
    <ol>
      <li><a href="#security-reveal">Signatures Over Encrypted Data May
        Reveal Information</a></li>
      <li><a href="#sign-what-you-see">"Sign What You See"</a></li>
    </ol>
  </li>
  <li><a href="#references">References</a></li>
</ol>
<hr />

<h2><a id="introduction" name="introduction">1 Introduction</a></h2>

<h3><a id="purpose" name="purpose">1.1 Purpose</a></h3>

<p>It has been noted by David Solo in [<a href="#Solo">Solo</a>] that both
signature [<a href="#XML-Signature">XML-Signature</a>] and encryption [<a
href="#XML-Encryption">XML-Encryption</a>] 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 <em><a href="#sign-what-you-see">"Sign What You See"</a></em>
(section 5.2) for more on signing encrypted data.)</p>

<p>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 [<a
href="#XML-C14N">XML-C14N</a>] or XPath [<a href="#XPath">XPath</a>]) if
there is a possibility that someone will encrypt portions of the
signature.</p>

<p>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 <code>ds:DigestValue</code>
element or a (part of) <code>ds:SignedInfo</code> element is encrypted, the
ordering is obvious (without decryption, signature verification is not
possible) and there is no need to introduce a new transform.</p>

<h3><a id="conventions" name="conventions">1.2 Editorial Conventions</a></h3>

<p>The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [<a
href="#Keywords">Keywords</a>].</p>

<p>This document makes use of the XML Encryption [<a
href="#XML-Encryption">XML-Encryption</a>] and XML Signature [<a
href="#XML-Signature">XML-Signature</a>] namespaces, and defines it own, with
the following prefixes:</p>
<pre>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#"
</pre>

<p>While applications MUST support XML and XML namespaces, the use of our
"<code>enc</code>", "<code>ds</code>", and "<code>dcrpt</code>" XML namespace
prefixes is OPTIONAL; we use this facility to provide compact and readable
exposition.</p>

<h2><a id="transform" name="transform">2 Decryption Transform</a></h2>
<dl>
  <dt>Identifier:</dt>
    <dd><a
      href="http://www.w3.org/2001/04/decrypt#">http://www.w3.org/2001/04/decrypt#</a></dd>
</dl>

<p>This transform requires an XPath node-set [<a href="#XPath">XPath</a>] for
input. If an octet stream is given as input, it must be converted to a
node-set as described in <em><a
href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/#sec-ReferenceProcessingModel">The
Reference Processing Model</a></em> (section 4.3.3.2) of the XML Signature
specification [<a href="#XML-Signature">XML-Signature</a>]. The transform
decrypts all the <code>enc:EncryptedData</code> elements [<a
href="#XML-Encryption">XML-Encryption</a>] except for those specified by
<code>dcrpt:Except</code> elements. <code>dcrpt:Except</code> is defined
below via XML Schema [<a href="#XML-Schema">XML-Schema</a>] and appears as
direct child elements of the <code>ds:Transform</code> element.</p>

<p>The REQUIRED <code>URI</code> attribute value of the
<code>dcrpt:Except</code> element MUST be a non-empty same-document URI
reference [<a href="#URI">URI</a>] (i.e., a number sign ('#') character
followed by an XPointer expression (as profiled by [<a
href="#XML-Signature">XML-Signature</a>, <a
href="http://www.w3.org/TR/xmldsig-core/#sec-ReferenceProcessingModel">Section
4.3.3.2</a>])) and identify an <code>enc:EncryptedData</code> within the
input to this transform.</p>
<pre class="xml-dtd">  Schema Definition:

  &lt;?xml version="1.0" encoding="utf-8"?&gt;
  &lt;!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN"
    "http://www.w3.org/2001/XMLSchema.dtd" [
    &lt;!ATTLIST schema
      xmlns:dt CDATA #FIXED "http://www.w3.org/2001/04/decrypt#"&gt;
    &lt;!ENTITY % p ''&gt;
    &lt;!ENTITY % s ''&gt;
  ]&gt;

  &lt;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"&gt;

    &lt;element name="Except" type="dt:ExceptType"/&gt;
    &lt;complexType name="ExceptType"&gt;
      &lt;attribute name="Id" type="ID" use="optional"/&gt;
      &lt;attribute name="URI" type="anyURI" use="required"/&gt;
    &lt;/complexType&gt;
  &lt;/schema&gt;
</pre>

<h3><a id="processing" name="processing">2.1 Processing Rules</a></h3>

<p>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 <a href="#func-decryptIncludedNodes"
class="link-def">decryptIncludedNodes()</a> function, which itself calls <a
href="#func-decrypt" class="link-def">decypt()</a>.</p>

<p>The transform operates over a node-set <em>X</em>, and its <a
name="def-parsing-context" id="def-parsing-context" class="link-def">parsing
context</a> , which consists of the following items:</p>
<ul>
  <li>Prefix and namespace name of each namespace that is in scope for the
    first element node in <em>X</em>.</li>
  <li>Name and value of each general entity that is effective for the XML
    document causing <em>X</em>.</li>
</ul>

<h4><a id="functions" name="functions">2.1.1 Functions</a></h4>
<dl>
  <dt><a name="func-decryptIncludedNodes" id="func-decryptIncludedNodes"
  class="link-def">Z = decryptIncludedNodes(X, R)</a></dt>
</dl>

<p>where <em>X</em> is a node-set and <em>R</em> is a set of
<code>dcrpt:Except</code> elements specified as a parameter of the transform.
<em>Z</em> is a node-set obtained by the following steps:</p>
<ol>
  <li>Within <em>X</em>, select <em>e</em>, an element node with the type
    <code>enc:EncryptedData</code>, such that is not referenced by any
    <code>dcrpt:Except</code> elements in <em>R</em>. If such <em>e</em>
    cannot be selected, the algorithm terminates and <em>Z</em>, the result
    of the transformation, is <em>X</em>.</li>
  <li>Let <em>C</em> be a <a href="#def-parsing-context"
    class="link-def">parsing context</a> of <em>X</em>.</li>
  <li>Let <em>Y</em> be <a href="#func-decrypt" class="link-def">decrypt(X,
    e, C)</a>. If this function succeeds, replace <em>X</em> with <em>Y</em>.
    Otherwise, the implementation MAY signal a failure of the transform.
    Alternatively, it MAY also continue processing without changing
    <em>X</em> (although it should take an appropriate means to avoid an
    infinite loop).</li>
  <li>Go to Step 1.</li>
</ol>
<dl>
  <dt><a name="func-decrypt" id="func-decrypt" class="link-def">Y =
  decrypt(X, e, C)</a></dt>
    <dd>where <em>X</em> is a node-set, <em>e</em> is an element node with
      the type <code>enc:EncryptedData</code> in <em>X</em>, and <em>C</em>
      is a <a href="#def-parsing-context" class="link-def">parsing
      context</a> of <em>X</em>.</dd>
    <dd><em>Y</em> is a node-set obtained by the following steps:
      <ol>
        <li>Convert <em>X</em> to an octet stream as described in <em><a
          href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/#sec-ReferenceProcessingModel">The
          Reference Processing Model</a></em> (section 4.3.3.2) of the XML
          Signature specification [<a
          href="#XML-Signature">XML-Signature</a>].</li>
        <li>Wrap the resulting octet stream with the octets representation of
          dummy tags (i.e., <code>&lt;dummy&gt;</code> and
          <code>&lt;/dummy&gt;</code>) as proposed by Richard Tobin in [<a
          href="#Tobin">Tobin</a>], 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 <em>C</em>, all
          the namespace declarations in <em>C</em> MUST be added to the dummy
          element. Also all the entity declarations in <em>C</em> MUST be
          added to the document type declaration.</li>
        <li>Decrypt the element corresponding to <em>e</em> (which may
          require parsing) and replace it with the resulting octet stream
          according to the XML Encryption specification [<a
          href="#XML-Encryption">XML-Encryption</a>].</li>
        <li>Parse the decrypted octet stream as described in <em><a
          href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/#sec-ReferenceProcessingModel">The
          Reference Processing Model</a></em> (section 4.3.3.2) of the XML
          Signature specification [<a
          href="#XML-Signature">XML-Signature</a>], resulting in a
        node-set.</li>
        <li><em>Y</em> 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.</li>
      </ol>
      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.
      <p>(In <a href="#func-decrypt" class="link-def">decrypt(X, e, C)</a>,
      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).)</p>
    </dd>
</dl>

<h4><a id="restrictions" name="restrictions">2.1.2 Restrictions and
Limitations</a></h4>

<p>These restrictions are necessary to ensure that the decrypted octet stream
is parsed correctly in a given <a href="#def-parsing-context"
class="link-def">parsing context</a>.</p>
<ol>
  <li>During the above steps, <em>X</em> MUST always be a <a
    href="#def-single-rooted" class="link-def">single-rooted</a> node-set. If
    <em>X</em> is not single-rooted, this transform MUST fail. A node-set is
    said to be <a name="def-single-rooted" id="def-single-rooted"
    class="link-def">single-rooted</a> 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.</li>
  <li>If the first node of the input is an element node with the type
    <code>enc:EncryptedData</code>, the decrypted octet stream MUST be of
    type <a
    href="http://www.w3.org/2001/04/xmlenc#Element">http://www.w3.org/2001/04/xmlenc#Element</a>.</li>
  <li>This transform does not include <code>enc:EncryptedKey</code> elements
    within its scope of specifically indicating elements, and their
    exceptions, that should be decrypted. An <code>enc:EncryptedKey</code>
    that exists as a descendent of <code>enc:EncryptedData</code> might be
    decrypted and will be removed from the original document as part of
    processing its ancestor <code>enc:EncryptedData</code> with this
    transform. However, a lone <code>enc:EncryptedKey</code> 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 <code>enc:EncryptedKey</code> elements always be children of an
    <code>enc:EncryptedData</code>'s <code>ds:KeyInfo</code> when they fall
    within the scope of a signature.</li>
</ol>

<h2><a id="creation" name="creation">3 Transform Creation
(Non-Normative)</a></h2>

<p>It is out of scope of this document how to create a
<code>ds:Transform</code> 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.</p>

<p>A <code>ds:Transform</code> element can be created by the following
steps:</p>
<ol>
  <li>Apply all the transforms being placed before this transform to a data
    object being signed.</li>
  <li>If the transform just before this transform outputs an octet stream,
    convert it to a node-set as described in <em><a
    href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/#sec-ReferenceProcessingModel">The
    Reference Processing Model</a></em> (section 4.3.3.2) of the XML
    Signature specification [<a href="#XML-Signature">XML-Signature</a>].</li>
  <li>For each node in the node-set, if the node is an element node with the
    type <code>enc:EncryptedData</code>, create an <code>dcrpt:Except</code>
    element referencing the node.</li>
  <li>Create a <code>ds:Transform</code> element, including the algorithm
    identifier of this transform and all the <code>dcrpt:Except</code>
    elements created in Step 3.</li>
</ol>

<h2><a id="example" name="example">4 Example</a></h2>

<p>Suppose the following XML document is to be signed. Note that the part of
this document (<code>[12]</code>) is already encrypted prior to signature. In
addition, the signer anticipates that some parts of this document, for
example, the <code>cardinfo</code> element (<code>[07-11]</code>) will be
encrypted after signing.</p>
<pre class="xml-example">  [01] &lt;order Id="order"&gt;
  [02]   &lt;item&gt;
  [03]     &lt;title&gt;XML and Java&lt;/title&gt;
  [04]     &lt;price&gt;100.0&lt;/price&gt;
  [05]     &lt;quantity&gt;1&lt;/quantity&gt;
  [06]   &lt;/item&gt;
  [07]   &lt;cardinfo&gt;
  [08]     &lt;name&gt;Your Name&lt;/name&gt;
  [09]     &lt;expiration&gt;04/2002&lt;/expiration&gt;
  [10]     &lt;number&gt;5283 8304 6232 0010&lt;/number&gt;
  [11]   &lt;/cardinfo&gt;
  [12]   &lt;EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
           Id="enc1"&gt;...&lt;/EncryptedData&gt;
  [13] &lt;/order&gt;
</pre>

<p>In order to let the recipient know the proper order of decryption and
signature verification, the signer includes the decryption transform
(<code>[06-08]</code> below) in the signature. Assuming that an additional
encryption is done on the <code>cardinfo</code> element (<code>[22]</code>),
the recipient would see the following encrypt-sign-encrypt document:</p>
<pre class="xml-example">  [01] &lt;Signature xmlns="http://www.w3.org/2000/09/xmldsig#"&gt;
  [02]   &lt;SignedInfo&gt;
  [03]     ...
  [04]     &lt;Reference URI="#order"&gt;
  [05]       &lt;Transforms&gt;
  [06]         &lt;Transform Algorithm="http://www.w3.org/2001/04/decrypt#"&gt;
  [07]           &lt;Except xmlns="http://www.w3.org/2001/04/decrypt#"
                   URI="#enc1"/&gt;
  [08]         &lt;/Transform&gt;
  [09]         &lt;Transform
                 Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/&gt;
  [10]       &lt;/Transforms&gt;
  [11]       ...
  [12]     &lt;/Reference&gt;
  [13]   &lt;/SignedInfo&gt;
  [14]   &lt;SignatureValue&gt;...&lt;/SignatureValue&gt;
  [15]   &lt;Object&gt;
  [16]     &lt;order Id="order"&gt;
  [17]       &lt;item&gt;
  [18]         &lt;title&gt;XML and Java&lt;/title&gt;
  [19]         &lt;price&gt;100.0&lt;/price&gt;
  [20]         &lt;quantity&gt;1&lt;/quantity&gt;
  [21]       &lt;/item&gt;
  [22]       &lt;EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
               Id="enc2"&gt;...&lt;/EncryptedData&gt;
  [23]       &lt;EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
               Id="enc1"&gt;...&lt;/EncryptedData&gt;
  [24]     &lt;/order&gt;
  [25]   &lt;/Object&gt;
  [26] &lt;/Signature&gt;
</pre>

<p>The recipient should first look at the <code>Signature</code> element
(<code>[01-26]</code>) for verification. It refers to the <code>order</code>
element (<code>[16-24]</code>) with two transforms: decryption
(<code>[06-08]</code>) and canonicalization (<code>[09]</code>). The
decryption transform instructs the signature verifier to decrypt all the
encrypted data except for the one specified in the <code>Except</code>
element (<code>[07]</code>). After decrypting the <code>EncryptedData</code>
in line <code>[22]</code>, the <code>order</code> element is canonicalized
and signature-verified.</p>

<h2><a id="security" name="security">5 Security Considerations</a></h2>

<h3><a id="security-reveal" name="security-reveal">5.1 Signatures Over
Encrypted Data May Reveal Information</a></h3>

<p>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 <code>ds:Reference</code> element. As noted by Hal Finney in
[<a href="#Finney">Finney</a>], 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 [<a
href="#Herzberg">Herzberg</a>], one may include a random 'salt' in a resource
being signed to increase its entropy.</p>

<p>Another approach is that when a signature referent is encrypted, one may
also encrypt the signature (or at least the <code>ds:DigestValue</code>
elements). As noted by Joseph Reagle in [<a href="#Reagle">Reagle</a>], 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.</p>

<h3><a id="sign-what-you-see" name="sign-what-you-see">5.2 "Sign What You
See"</a></h3>

<p>This specification serves scenarios in which a person might sign encrypted
data. Because XML Signature [<a href="#XML-Signature">XML-Signature</a>] 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 <a
href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/#sec-Seen"><em>Only
What is 'Seen' Should be Signed</em></a> and <a
href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/#sec-See"><em>'See'
What is Signed</em></a> 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!</p>

<h2><a id="references" name="references">6 References</a></h2>
<dl>
  <dt><a id="Finney" name="Finney">Finney</a></dt>
    <dd>H. Finney. <a
      href="http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0064">Re:
      Combining signing and encrypting</a>, XML Encryption mailing list,
    2000.</dd>
    <dd><a
      href="http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0064">http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0064</a></dd>
  <dt><a id="Herzberg" name="Herzberg">Herzberg</a></dt>
    <dd>A. Herzberg. <a
      href="http://lists.w3.org/Archives/Public/xml-encryption/2001Mar/0025">Signing
      encrypted data</a>, XML Encryption mailing list, 2001.</dd>
    <dd><a
      href="http://lists.w3.org/Archives/Public/xml-encryption/2001Mar/0025">http://lists.w3.org/Archives/Public/xml-encryption/2001Mar/0025</a></dd>
  <dt><a id="Keywords" name="Keywords">Keywords</a></dt>
    <dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt">Key words
      for use in RFCs to Indicate Requirement Levels</a>, RFC 2119, 1997.</dd>
    <dd><a
      href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a></dd>
  <dt><a id="Reagle" name="Reagle">Reagle</a></dt>
    <dd>J. Reagle. <a>Re: Signing and Encryption</a>, XML Encryption mailing
      list, 2001.</dd>
    <dd><a
      href="http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0100">http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0100</a></dd>
  <dt><a id="Solo" name="Solo">Solo</a></dt>
    <dd>D. Solo. <a
      href="http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0058">Combining
      signing and encrypting</a>, XML Encryption mailing list, 2000.</dd>
    <dd><a
      href="http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0058">http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0058</a></dd>
  <dt><a id="Tobin" name="Tobin">Tobin</a></dt>
    <dd>R. Tobin. <a
      href="http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000OctDec/0054">Infoset
      for external entities</a>, XML Core mailing list, 2000 [<a
      href="http://cgi.w3.org/MemberAccess/AccessRequest">W3C Member
      Only</a>].</dd>
    <dd><a
      href="http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000OctDec/0054">http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000OctDec/0054</a></dd>
  <dt><a id="URI" name="URI">URI</a></dt>
    <dd>T. Berners-Lee, R. Fielding, and L. Masinter. <a
      href="http://www.ietf.org/rfc/rfc2396.txt">Uniform Resource Identifiers
      (URI): Generic Syntax</a>, RFC 2396, 1998.</dd>
    <dd><a
      href="http://www.ietf.org/rfc/rfc2396.txt">http://www.ietf.org/rfc/rfc2396.txt</a></dd>
  <dt><a id="XML-C14N" name="XML-C14N">XML-C14N</a></dt>
    <dd>J. Boyer. <a
      href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">Canonical XML
      Version 1.0</a>, W3C Recommendation, 2001.</dd>
    <dd><a
      href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a></dd>
  <dt><a id="XML-Encryption" name="XML-Encryption">XML-Encryption</a></dt>
    <dd>D. Eastlake and J. Reagle. <a
      href="http://www.w3.org/TR/2001/WD-xmlenc-core-20011018/">XML
      Encryption Syntax and Processing</a>, W3C Candidate Recommendation,
      2002.</dd>
    <dd><a
      href="http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/">http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/</a></dd>
  <dt><a id="XML-Schema" name="XML-Schema">XML-Schema</a></dt>
    <dd>H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn. <a
      href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">XML Schema
      Part 1: Structures</a>, W3C Recommendation, 2001.</dd>
    <dd><a
      href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-1-20010502</a></dd>
    <dd>P. Biron and A. Malhotra. <a
      href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/">XML Schema
      Part 2: Datatypes</a>, W3C Rec., 2001.</dd>
    <dd><a
      href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/</a></dd>
  <dt><a id="XML-Signature" name="XML-Signature">XML-Signature</a></dt>
    <dd><a
      href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/">XML-Signature
      Syntax and Processing</a>. D. Eastlake, J. Reagle, and D. Solo. W3C
      Recommendation, February 2002. <a
      href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/">http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/</a></dd>
  <dt><a id="XPath" name="XPath">XPath</a></dt>
    <dd>J. Clark and S. DeRose. <a
      href="http://www.w3.org/TR/1999/REC-xpath-19991116">XML Path Language
      (XPath) Version 1.0</a>, W3C Recommendation, 1999.</dd>
    <dd><a
      href="http://www.w3.org/TR/1999/REC-xpath-19991116">http://www.w3.org/TR/1999/REC-xpath-19991116</a></dd>
</dl>
</body>
</html>