xml-encryption-req 35.7 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>
  <title>XML Encryption Requirements</title>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
  <style type="text/css">
  <!--
/*<![CDATA[*/
code         { font-weight: normal; font-family: monospace }
del,.strike { text-decoration: line-through; background: white; color: silver;}
.discuss     { color: purple }
.link-def    { color: teal; font-style: italic }
.comment     { border-right: navy thin solid; border-top: navy thin solid;
               border-left: navy thin solid; border-bottom: navy thin solid;
               background-color: #fffff5 }
.term        { font-weight: bold; background-color: yellow }
.xml-example { font-size: 90%; margin-left: -1em; text-indent: 0px;
               line-height: normal; margin-right: 0em;
               font-family: monospace; letter-spacing: normal }
.xml-dtd     { font-size: 90%; margin-left: -1em; text-indent: 0px;
               line-height: normal; margin-right: 0em;
               font-family: monospace; letter-spacing: normal;
               background-color: rgb(239,239,248) }
/*]]>*/
  -->

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

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

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

<h1>XML Encryption Requirements</h1>

<h2>W3C Note 04 March 2002</h2>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2002/NOTE-xml-encryption-req-20020304">http://www.w3.org/TR/2002/NOTE-xml-encryption-req-20020304</a></dd>
  <dt>Latest version:</dt>
    <dd><a
      href="http://www.w3.org/TR/xml-encryption-req">http://www.w3.org/TR/xml-encryption-req</a></dd>
  <dt>Previous version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2001/WD-xml-encryption-req-20011018">http://www.w3.org/TR/2001/WD-xml-encryption-req-20011018</a></dd>
  <dt>Editor:</dt>
    <dd>Joseph Reagle &lt;<a
    href="mailto:reagle@w3.org">reagle@w3.org</a>&gt;</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 class="abstract">Abstract</h2>

<p>This document lists the design principles, scope, and requirements for XML
Encryption. It includes requirements as they relate to the encryption syntax,
data model, format, cryptographic processing, and external requirements and
coordination.</p>

<div class="status">
<h2 class="status">Status of this Document</h2>

<div class="">
<p>This is the XML Encryption Requirements Note from the <a
href="http://www.w3.org/Encryption/2001/">XML Encryption Working Group</a>
(<a href="http://www.w3.org/Encryption/2001/Activity.html">Activity
Statement</a>). This version represents the consensus of the Working Group
since March 2001 on the requirements for the <a
href="http://www.w3.org/TR/xmlenc-core/">XML Encryption Syntax and Processing
specification</a>. It has also underwent minor changes resulting from the <a
href="http://www.w3.org/Encryption/2001/11/last-call-issues.html">Last Call
(issues)</a> ending on November 9 2001. The Working Group has no plans to
update the content of this document; it serves to document the agreed upon
set of requirements the specification will address.</p>

<p>This document is a NOTE made available by the W3C for archival purposes.
Publication of this Note by W3C indicates no endorsement by W3C or the W3C
Team, or any W3C Members. A list of current W3C technical reports and
publications, including Recommendations, Working Drafts, and Notes can be
found at <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p>

<p>Please send comments to the editor &lt;<a
href="mailto:reagle@w3.org">reagle@w3.org</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.html">patent disclosure
page</a> in conformance with W3C policy.</p>
</div>
</div>
<hr />

<div>
<h2 class="table-of-contents">Table of Contents</h2>
<ol class="table-of-contents">
  <li><a href="#sec-Intro">Introduction</a></li>
  <li><a href="#sec-design-principles-scope">Design Principles and
  Scope</a></li>
  <li><a href="#sec-Requirements">Requirements</a> to be able to partially
    encrypt and the requirements of the XML Encryption Syntax and Processing
    document.
    <ol class="table-of-contents">
      <li><a href="#sec-Model">Encryption Data Model and Syntax</a></li>
      <li><a href="#sec-Objects">Objects</a></li>
      <li><a href="#sec-Processing">Processing</a></li>
      <li><a href="#sec-Algorithms">Algorithms and Structures</a></li>
      <li><a href="#sec-Security">Security</a></li>
      <li><a href="#sec-Coordination">Coordination</a></li>
      <li><a href="#sec-IPR">Intellectual Property</a></li>
    </ol>
  </li>
  <li><a href="#sec-References">References</a></li>
</ol>
</div>
<hr />

<div>
<h2><a id="sec-Intro" name="sec-Intro">1. Introduction</a></h2>

<p>The XML 1.0 Recommendation [<a href="#ref-XML">XML</a>] specifies the
syntax of a class of resources called XML documents. This specification
provides requirements for a XML syntax and processing for encrypting digital
content, including portions of XML documents and protocol messages.</p>

<h2><a id="sec-design-principles-scope" name="sec-design-principles-scope">2.
Design Principles and Scope</a></h2>

<p>This section describes high level principles of design and definition of
scope. They are an expression of intent/motivation. How these motivations are
realized are addressed in subsequent sections.</p>
<ol>
  <li>The XML Encryption specification must describe how to use XML to
    represent a digitally encrypted Web resource (including XML itself). {<a
    href="#ref-prop2">prop1</a>, <a href="#ref-prop2">prop2</a>}. The XML
    representation of the encrypted resource must be a first class object
    (i.e., referenceable and consequently describable, signable, etc.) and
    represented by a distinct element type.
    <ol>
      <li>The specification must provide for the encryption of a <a
        id="req-granularity" name="req-granularity">part</a> or totality of
        an XML document
        <ol type="1">
          <li>Granularity of encryption in an XML document is limited to an
            element (including start/end tags) or element content (between
            the start/end tags). {<a href="#ref-prop2">prop2</a>, <a
            href="#ref-WS">WS</a>, <a href="#ref-FTF1">FTF1</a>}
            <p class="comment">Comment: After much discussion about the
            requirements, complexities, and alternatives of attribute
            encryption {List: <a
            href="http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0007.html">Hallam-Baker</a>,
            <a
            href="http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0036.html">Simon</a>,
            <a
            href="http://lists.w3.org/Archives/Public/xml-encryption/2001Mar/0033.html">Reagle</a>}
            the WG has decided to proceed under the requirement of element
            encryption. During last call feedback from implementors and
            reviewers was expressly solicited on this issue with no requests
            for change.</p>
          </li>
        </ol>
      </li>
      <li>The specification must provide for <span xml:lang="EN-US"
        lang="EN-US">the separation of encryption information from encrypted
        data, and support reference mechanisms for addressing encryption
        information from encrypted data sections and vice-versa. {<a
        href="#ref-HP">HP</a>: R3.7,</span> <a
        href="#ref-prop2">prop2</a><span xml:lang="EN-US"
        lang="EN-US">}</span></li>
      <li>The specification must allow for the super-encryption of data
        (i.e., encrypting XML in which some elements are already encrypted).
        {<a href="#ref-prop1">prop1</a>, <a href="#ref-prop2">prop2</a>}
        Super-encrypted data must use the same syntax and semantics as any
        other encrypted data.</li>
    </ol>
  </li>
  <li>The specification must provide a mechanism for conveying encryption key
    information to a recipient. The structure must be flexible so as to meet
    a variety of application requirements including:
    <ul>
      <li>Carrying an encrypted key value that is encrypted to the recipient
        with an asymmetric or symmetric cipher.</li>
      <li>Providing a name or URI reference to a known key</li>
    </ul>
    <p>It must be possible (though it is not necessary) to include key
    information as part of an XML encrypted data representation or referenced
    externally. Additionally, keys must be able to (though it is not
    necessary) to identify the data that they encrypt.</p>
  </li>
</ol>
<ol start="3">
  <li>The mechanisms of encryption must be simple: describe how to
    encrypt/decrypt digital content, XML documents, and portions thereof.
    {Reagle}
    <ol>
      <li>Only information necessary for decryption need be provided.
        {Reagle}.The specification must permit the efficient encoding of
        encrypted data and related information when parties have pre-agreed
        upon the encryption approach and keying material. Hence, the
        specification must not mandate the presence of any attributes
        describing how the data is encrypted.</li>
      <li>The specification will not address the confidence or trust
        applications place in the provision of a key</li>
      <li>The specification will not address authentication. {<a
        href="#ref-List">List</a>: <a
        href="http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0017.html">Reagle</a>,
        <a href="#ref-WS">WS</a>}</li>
      <li>The specification will not address authorization and access
        control. {<a href="#ref-List">List</a>: <a
        href="http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0009.html">Reagle</a>,
        <a
        href="http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0008.html">Simon</a>,
        <a
        href="http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0012.html">Kudoh</a>,
        <a href="#ref-WS">WS</a>}</li>
    </ol>
  </li>
  <li>The Working Group (WG) must use pre-existing specifications unless it
    can explicitly justify the need for a new one. {Reagle} For example, it
    should use DOM or Information Set as a data model for XML instances and
    Canonical XML for canonicalization unless a compelling argument for an
    alternative can be made.</li>
  <li>The specification must define a minimal (extensible) set of algorithms
    and key structures necessary for interoperability purposes. {Reagle}</li>
  <li>The specification should strive to limit optionality and maximize
    extensibility such that all of the specification can be quickly
    implemented</li>
  <li>Whenever possible, any encryption resource or algorithm is a first
    class object (which can also be encrypted or signed), and identified by a
    URI. {<a href="#ref-prop1">prop1</a>, <a href="#ref-prop2">prop2</a>}</li>
</ol>

<h2><a id="sec-Requirements" name="sec-Requirements">3. Requirements</a></h2>

<h3>1. Encryption Data <a id="sec-Model" name="sec-Model">Model</a> and
Syntax</h3>
<ol>
  <li>The XML <a id="req-data-model" name="req-data-model">data model</a>
    used by XML Encryption in identifying or representing data that has been
    processed must be predicated on:
    <ol type="1">
      <li>a simple enumerated subset of the data model (e.g., element,
        attribute, etc.) and properties {e.g., child, parent, localname,
        prefix, etc.) {<a href="#ref-WS">WS</a>}</li>
    </ol>
  </li>
  <li>XML Encryption can be applied to any Web resource -- including non-XML
    content. {<a href="#ref-prop1">prop1</a>, <a href="#ref-prop2">prop2</a>}
    Also, see <a href="#sec-Objects">Requirements: Objects</a>.
    <ol type="1">
      <li>When a non-XML object (i.e., external data) is encrypted, the
        information necessary to aid the recipient in decrypting the object
        is captured in an instance of XML (i.e. the encryption method, keying
        information, etc.). It is an application decision whether to include
        the encrypted object cipher data within this XML, as a base64 encoded
        CDATA, or to simply reference the external cipher data octet
        sequence. In either case, the decrypted data must revert to the media
        type of the original object. {TimBL, Dillaway} </li>
    </ol>
  </li>
</ol>

<h3>2. <a id="sec-Objects" name="sec-Objects">Objects</a></h3>
<ol>
  <li>It must be possible to indicate the original type (e.g., XML CDATA,
    image/gif) of the encrypted data to aid the decryptor in processing it.
    For non-XML data, existing MIME type definitions [MIME] should be
  used. </li>
  <li>Binary data must be encoded as Base64 when represented in XML. {<a
    href="#ref-FTF1">FTF1</a>}</li>
  <li>The specification must not define packaging representations of non XML
    data (e.g., MIME-objects) other than the encrypted and encoded
    information appearing within the XML Encryption defined syntax.</li>
  <li>The specification must not define a packaging format that describes the
    relationships between encrypted objects. For instance, the specification
    will not specify how an application can designate that a set of encrypted
    objects are actually encryptions over different representations
    (encodings, compression, etc.) of the same object. {<a
    href="#ref-prop3">prop3</a>: open issue 2, resolved at <a
    href="#ref-FTF1">FTF1</a>}</li>
</ol>

<h3>3. <a id="sec-Processing" name="sec-Processing">Processing</a></h3>
<ol>
  <li>Parsing  {<a href="#ref-WS">WS</a>}
    <ol type="1">
      <li>XML Encryption applications must be XML-namespaces [<a
        href="#ref-XML-ns">XML-namespaces</a>] aware.</li>
      <li>XML Encryption applications must be XML Schema [<a
        href="#ref-XML-schema"></a> <a href="#ref-XML-schema">XML-schema</a>]
        aware in that they create XML encryption instances conforming to the
        encryption schema definitions. {Reagle}</li>
      <li>Implementation of the specification should work with existing XML
        parser and schema implementations. However, alterations to particular
        DOM and/or XML parser implementations may prove beneficial in terms
        of simplifying application development or improving  runtime
        efficiency. These details are outside the scope of the XML Encryption
        specification.</li>
    </ol>
  </li>
  <li>XML Instance <a id="req-Validity" name="req-Validity">Validity</a> {<a
    href="#ref-WS">WS</a>}
    <ol type="1">
      <li>Encrypted instances must be well-formed but need not be valid
        against their original definition (i.e. applications that encrypt the
        element structure are purposefully hiding that structure.)</li>
      <li>Instance authors that want to validate encrypted instances must do
        one of the following:
        <ol type="1">
          <li>Write the original schema so as to validate resulting instances
            given the change in its structure and inclusion of element types
            from the XML Encryption namespace.</li>
          <li>Provide a post-encryption schema for validating encrypted
            instances.</li>
          <li>Provide information on how to restore the document to its
            original state via application context (e.g., headers). {<a
            href="#ref-List">List</a>: <a
            href="http://lists.w3.org/Archives/Public/xml-encryption/2002Feb/0016.html">Reagle</a>}</li>
        </ol>
      </li>
    </ol>
  </li>
  <li>The <a id="req-processing-model" name="req-processing-model">processing
    model</a> must be described using XML, DOM, or Information Set
    terminology and implementations can be based on application specific
    logic (e.g., XPath and DOM are not required to implement).  {<a
    href="#ref-List">List</a>: <a
    href="http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0007.html">Ferguson</a>,
    <a href="#ref-FTF1">FTF1</a>}</li>
  <li>The <a id="req-referencing-model"
    name="req-referencing-model">referencing model</a> must be based on XML
    Signature's <a
    href="http://www.w3.org/TR/xmldsig-core/#sec-ReferenceProcessingModel">Reference
    Processing Model</a> [<a href="#ref-XML-DSIG">XMLDSIG</a>] with the
    following two qualifications:
    <ol type="1">
      <li>As recommended by [<a href="#ref-XML-DSIG">XMLDSIG</a>], where a
        referencing mechanism supports transforms any fragment processing
        should be specified as part of the transform.</li>
      <li>Where a referencing mechanism does not support Transforms,
        applications should support same-document XPointers '#xpointer(/)'
        and '#xpointer(id("<em>ID</em>"))'.</li>
    </ol>
  </li>
  <li><a id="req-Transforms" name="req-Transforms">Transforms</a>  {<a
    href="#ref-WS">WS</a>}
    <ol>
      <li>Encryption Transforms: The specification must not enable the
        specification of additional transforms as part of encrypting and
        decrypting data; transforms on data being encrypted/decrypted must be
        done by the application. For example, compression could be done by
        compressing the content and wrapping that data in an XML compression
        syntax and then encrypting it. {<a href="#ref-FTF1">FTF1</a>, <a
        href="#ref-List">List</a>: <a
        href="http://lists.w3.org/Archives/Public/xml-encryption/2002Feb/0017.html">Reagle</a>}</li>
    </ol>
  </li>
  <li>Encryption and <a id="req-Signatures"
    name="req-Signatures">Signatures</a>
    <ol>
      <li>The specification must recommend approaches for use of XML
        Signature with XML Encryption such that multiple parties may
        selectively encrypt and sign portions of documents that might already
        be signed and encrypted. Recipients should be able to easily
        determine whether or not to decrypt data prior to signature
        validation.
        <ol type="1">
          <li>Applications have the following options:
            <ol type="1">
              <li>When data is encrypted, so is its Signature; consequently
                those Signature you can see can be validated. (However, <a
                href="http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0081.html">this
                is not always easily accomplished with detached
                Signatures</a>.){<a href="#ref-List">List</a>: <a
                href="http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0081.html">Finney</a>}</li>
              <li>Employ the "decrypt-except" [<a
                href="#ref-XML-DSIG-Decrypt">XML-DSIG-Decrypt</a>] signature
                transform. It works as follows: during signature transform
                processing, if you encounter a decrypt transform, decrypt all
                encrypted content in the document except for those excepted
                by an enumerated set of references. {<a
                href="#ref-List">List</a>: <a
                href="http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0087.html">Maruyama</a>,
                <a href="#ref-FTF1">FTF1</a>}.</li>
            </ol>
          </li>
        </ol>
      </li>
    </ol>
  </li>
  <li>The encryption and XML processing should be
    <ol>
      <li>Fast {<a href="#ref-List">List</a>: <a
        href="http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0007.html">Ferguson</a>}</li>
      <li>Memory efficient {<a href="#ref-List">List</a>: <a
        href="http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0007.html">Ferguson</a>}</li>
      <li>Work with tree and event based parsers {<a
        href="#ref-List">List</a>: <a
        href="http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0007.html">Ferguson</a>}</li>
    </ol>
  </li>
  <li>If a document is (partially) encrpyted, transcoded, and then decrypted,
    the resulting octets must be the same as if the document had been just
    transcoded (assuming the target character encoding is the same in both
    cases).</li>
</ol>

<h3>4. <a id="sec-Algorithms" name="sec-Algorithms">Algorithms</a> and
Structures</h3>
<ol>
  <li>The solution must work with arbitrary encryption algorithms, including
    symmetric and asymmetric keys schemes as well as dynamic negotiation of
    keying material. {<a href="#ref-prop1">prop1</a>, <a
    href="#ref-prop2">prop2</a>}</li>
  <li>The specification must specify or reference one mandatory to implement
    algorithm for only the most common application scenarios.
    <ol type="1">
      <li>Stream Encryption Algorithms {<a href="#ref-FTF1">FTF1</a>}
        <ol type="1">
          <li>none</li>
        </ol>
      </li>
      <li>Block Encryption Algorithms {<a href="#ref-FTF1">FTF1</a>}
        <ol type="1">
          <li>AES with CMS keylength is required to implement</li>
          <li>3DES is required to implement -- this may be relaxed when AES
            as matures.</li>
          <li>AES at other keylengths is optional to implement.</li>
        </ol>
      </li>
      <li>Chaining Modes {<a href="#ref-FTF1">FTF1</a>}
        <ol type="1">
          <li>CBC (Cipher Block Chaining) with PKCS#5 padding is optional to
            implement.</li>
        </ol>
      </li>
      <li>Key Transport {<a href="#ref-FTF1">FTF1</a>}
        <ol>
          <li>RSA-OAEP used with AES is required to implement.</li>
          <li>RSA-v1.5 used with 3DES is required to implement -- this may be
            relaxed as AES matures.</li>
        </ol>
      </li>
      <li>Key Agreement {<a href="#ref-FTF1">FTF1</a>}
        <ol type="1">
          <li>Diffie-Hellman is optional to implement</li>
        </ol>
      </li>
      <li>Symmetric Key Wrap {<a href="#ref-FTF1">FTF1</a>}
        <ol type="1">
          <li>AES KeyWrap is mandatory -- when it's completely specified.</li>
          <li>CMS-KeyWrap-3DES is required.</li>
        </ol>
      </li>
      <li>Message Integrity
        <ol type="1">
          <li>AES/3DES with SHA1 is optional to implement.</li>
        </ol>
      </li>
      <li>Message Authentication {<a href="#ref-FTF1">FTF1</a>}
        <ol type="1">
          <li>XML Signature [<a href="#ref-XML-DSIG">XMLDSIG</a>] is
            recommended to implement.</li>
        </ol>
      </li>
      <li>Canonicalization {<a href="#ref-FTF1">FTF1</a>}
        <ol type="1">
          <li>Canonical XML is optional to implement.</li>
        </ol>
      </li>
      <li>Compression {<a href="#ref-FTF1">FTF1</a>}
        <ol type="1">
          <li>none</li>
        </ol>
      </li>
    </ol>
  </li>
  <li><a id="req-KeyStructures" name="req-KeyStructures">Key Structures</a>
    <ol>
      <li>Scope: the only defined key structures must be those required by
        the mandatory and recommended algorithms. {Reagle}</li>
      <li>The specification should not address how to specify the intended
        recipient of keying information beyond an optional "hint" attribute.
        {<a href="#ref-prop3">prop3</a>: open issue 1, <a
        href="#ref-FTF1">FTF1</a>}</li>
      <li>The specification should leverage the XML Signature specification's
        syntax for keying information (dsig:KeyInfo element) to the maximum
        extent possible.{<a href="#ref-prop3">prop3</a>, <a
        href="#ref-FTF1">FTF1</a>}</li>
    </ol>
  </li>
</ol>

<h3>5. <a id="sec-Security" name="sec-Security">Security</a></h3>

<p>The XML Encryption specification must include a discussion of potential
vulnerabilities and recommended practices when using the defined processing
model in a larger application context. While it is impossible to predict all
the ways an XML Encryption standard may be used, the discussion should alert
users to ways in which potentially subtle weaknesses might be introduced.</p>

<p>At a minimum, the following types of vulnerabilities must be addressed.</p>
<ol>
  <li>Security issues arising from known plain-text and data length
    information
    <ol>
      <li>An attacker may know the original structure of the plain-text via
        its schema. {<a href="#ref-List">List</a>: <a
        href="http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0037.html">Wiley</a>}</li>
      <li>An attacker may know the length and redundancy of the plain-text
        data. {<a href="#ref-List">List</a>: <a
        href="http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0042.html">Finney</a>}</li>
    </ol>
  </li>
  <li>Processing of invalid decrypted data if an integrity checking mechanism
    is not used in conjunction with encryption. {<a
    href="#ref-List">List</a>: <a
    href="http://lists.w3.org/Archives/Public/xml-encryption/2001Mar/0001.html">Lambert</a>,
    <a href="#ref-FTF1">FTF1</a>}</li>
  <li>Potential weaknesses resulting from combining signing and encryption
    operations.
    <ol type="1">
      <li>sign before you encrypt: the signature may reveal information about
        the data that has now been encrypted unless proper precautions are
        taken (such as properly adding an encrypted random string to the
        plaintext before hashing). {<a href="#ref-List">List</a>: <a
        href="http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0081.html">Finney</a>}</li>
      <li>encrypt before you sign: Users might mistakenly sign encrypted data
        under a semantic (e.g., asserts or agrees to<em>)</em> associated
        with the data's <em>decrypted</em> form. [<a
        href="#ref-XML-DSIG">XMLDSIG</a>: <a
        href="http://www.w3.org/TR/xmldsig-core/#sec-Seen">Only What is
        "Seen" Should be Signed</a>]. Additionally, there may be multiple
        {data,key} pairs that result in the same encrypted data, therefore
        special care must be taken in the selection of the encryption
        function or in the signature process to mitigate the possibility of
        signature repudiation (e.g., "I didn't say this, I signed a different
        message encrypted under a different key.") {<a
        href="#ref-List">List</a>: <a
        href="http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0071.html">Wang</a>,
        <a
        href="http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0076.html">Ashwood</a>}.</li>
    </ol>
  </li>
  <li value="4">The specification should warn application designers and users
    about revealing information about the encrypted data
    <ol>
      <li>via any semantics inferred from a URI.</li>
    </ol>
  </li>
</ol>

<h3>6. <a id="sec-Coordination" name="sec-Coordination">Coordination</a></h3>

<p>The XML Encryption specification should meet the requirements of (so as to
support) or work with the following applications:</p>
<ul>
  <li><a href="#ref-XML-DSIG">XW3C XML Signature</a> {Reagle}</li>
  <li><a href="http://www.w3.org/2002/ws/">W3C XML Protocols</a> {Reagle}</li>
  <li><a
    href="http://www.oasis-open.org/committees/security/index.shtml">Oasis
    XML-Based Security Services TC (SSTC)</a> {Reagle}</li>
  <li><a href="http://www.w3.org/AudioVideo/">Synchronized Multimedia
    Integration Language</a>. {<a href="#ref-List">List</a>: <a
    href="http://lists.w3.org/Archives/Public/xml-encryption/2000Dec/0004.html">Simon</a>}</li>
</ul>

<p>To ensure the above requirements are adequately addressed, the XML
Encryption specification must be reviewed by a designated member of the
following communities:</p>
<ul>
  <li>XML Signature WG</li>
  <li><a href="http://www.w3.org/2002/ws/">XML Protocol</a></li>
  <li>XML Schema WG</li>
  <li>XML Core WG</li>
  <li>Internationalization IG</li>
</ul>

<h3>8 <a id="sec-IPR" name="sec-IPR">Intellectual Property</a></h3>
<ol>
  <li>The specification should be free of encumbering technologies: requiring
    no licensing fees for implementation and use. {<a
    href="#ref-List">List</a>: <a
    href="http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0007.html">Ferguson</a>}
    <p>"Members of the XML Encryption Working Group and any other Working
    Group constituted within the XML Encryption Activity are expected to
    disclose any intellectual property they have in this area. Any
    intellectual property essential to implement specifications produced by
    this Activity must be at least available for licensing on a royalty-free
    basis. At the suggestion of the Working Group, and at the discretion of
    the Director of W3C, technologies may be accepted if they are licensed on
    reasonable, non-discriminatory terms." <a
    href="http://www.w3.org/Encryption/2001/01/xmlenc-charter.html#_IPR">XML
    Encryption Charter.</a></p>
  </li>
</ol>

<h2><a id="sec-References" name="sec-References">4. References</a></h2>
<dl>
  <dt><a id="ref-C2000" name="ref-C2000">C2000</a></dt>
    <dd><a
      href="http://lists.w3.org/Archives/Public/xml-encryption/2000Sep/0014.html">Crypto
      2000 XML Encryption BoF</a>. Santa Barbara, CA. August 24 .</dd>
  <dt><a id="ref-DOM" name="ref-DOM">DOM</a></dt>
    <dd><a href="http://www.w3.org/TR/DOM-Level-3-Core/core.html">Document
      Object Model Core, Level 3</a>. Arnaud Le Hors. W3C Working Draft.
      January 2001.<br />
      <a
      href="http://www.w3.org/TR/DOM-Level-3-Core/core.html">http://www.w3.org/TR/DOM-Level-3-Core/core.html</a></dd>
  <dt><a id="ref-FTF1" name="ref-FTF1">FTF1</a></dt>
    <dd><a
      href="http://www.w3.org/Encryption/2001/Minutes/0103-Boston/minutes.html">XML
      Encryption Face-to-Face</a>. Boston, MA. March 2000</dd>
  <dt><a id="ref-HP" name="ref-HP">HP</a></dt>
    <dd><a
      href="http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/att-0004/01-enc-requirements_2000-10-31.html">Requirements
      and Goals for the Design of an 'XML Encryption Standard'</a>. <span
      xml:lang="EN-US" lang="EN-US">Gerald Huck and Arne Priewe. November
      2000.</span></dd>
  <dt><a id="ref-InfoSet" name="ref-InfoSet">InfoSet</a></dt>
    <dd><a href="http://www.w3.org/TR/2001/REC-xml-infoset-20011024/">XML
      Information Set</a>, W3C Recommendation. John Cowan. August 2001.</dd>
    <dd><a
      href="http://www.w3.org/TR/2001/REC-xml-infoset-20011024/">http://www.w3.org/TR/2001/REC-xml-infoset-20011024/</a></dd>
  <dt><a id="ref-List" name="ref-List">List</a></dt>
    <dd><a href="http://lists.w3.org/Archives/Public/xml-encryption/">XML
      Encryption List</a> (an unmoderated and unchartered public list).</dd>
  <dt><a id="ref-MIME" name="ref-MIME">MIME</a></dt>
    <dd>RFC2046. MIME Part Two: Media Types  November 1996.</dd>
    <dd>http://rfc.net/rfc2046.html</dd>
  <dt><a id="ref-MyProof" name="ref-MyProof">MyProof</a></dt>
    <dd><a
      href="http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/att-0011/01-myproof-xml-encryption-position.html">MyProof
      Position Paper On XML Encryption</a>. Steve Wiley.</dd>
  <dt><a id="ref-prop1" name="ref-prop1">prop1</a></dt>
    <dd><a
      href="http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/0001.html">XML
      Encryption strawman proposal</a>. Ed Simon and Brian LaMacchia. Aug 09
      2000.</dd>
  <dt><a id="ref-prop2" name="ref-prop2">prop2</a></dt>
    <dd><a
      href="http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/0005.html">Another
      proposal of XML Encryption</a>. Takeshi Imamura. Aug 14 2000.</dd>
  <dt><a id="ref-prop3" name="ref-prop3">prop3</a></dt>
    <dd><a>XML Encryption Syntax and Processing</a>. Dillaway, Fox, Imamura,
      LaMacchia, Maruyama, Schaad, Simon. December 2000.</dd>
  <dt><a id="ref-WS" name="ref-WS">WS</a></dt>
    <dd><a href="http://www.w3.org/2000/09/XML-Encryption-Workshop.html">W3C
      XML Encryption Workshop</a> [<a
      href="http://www.w3.org/2000/11/02-xml-encryption-ws/minutes.html">minutes</a>].
      SanFrancisco. November 2, 2000.</dd>
  <dt><a id="ref-XML" name="ref-XML">XML</a></dt>
    <dd>Extensible Markup Language (XML) 1.0 Recommendation. T. Bray, J.
      Paoli, C. M. Sperberg-McQueen. February 1998.</dd>
    <dd><a
      href="http://www.w3.org/TR/1998/REC-xml-19980210">http://www.w3.org/TR/1998/REC-xml-19980210</a></dd>
  <dt><a id="ref-XML-C14N" name="ref-XML-C14N">XML-C14N</a></dt>
    <dd><a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">Canonical
      XML.</a> W3C Recommendation. J. Boyer. March 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><br
      />
      <a
      href="http://www.ietf.org/rfc/rfc3076.txt">http://www.ietf.org/rfc/rfc3076.txt</a></dd>
  <dt><a id="ref-XML-ns" name="ref-XML-ns">XML-ns</a></dt>
    <dd>Namespaces in XML Recommendation. T. Bray, D. Hollander, A. Layman.
      January 1999.</dd>
    <dd><a
      href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">http://www.w3.org/TR/1999/REC-xml-names-19990114/</a></dd>
  <dt><a id="ref-XML-schema" name="ref-XML-schema">XML-schema</a></dt>
    <dd><a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">XML
      Schema Part 1: Structures</a> W3C Recommendation. D. Beech, M. Maloney,
      N. Mendelsohn, H. Thompson. May 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><br
      />
      <a href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/">XML
      Schema Part 2: Datatypes</a> W3C Recommendation. P. Biron, A. Malhotra.
      May 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="ref-XML-DSIG" name="ref-XML-DSIG"></a>XML-DSIG</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="ref-XML-DSIG-Decrypt"
  name="ref-XML-DSIG-Decrypt"></a>XML-DSIG-Decrypt</dt>
    <dd><a
      href="http://www.w3.org/TR/2002/CR-xmlenc-decrypt-20020304">Decryption
      Transform for XML Signatur</a>e. T. Imamura and H. Maruyama. W3C
      Candidate Recommendation, March 2002.</dd>
    <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><a id="ref-XSet" name="ref-XSet">XSet</a></dt>
    <dd>Full Fidelity Information Set Representation. Jonathan Borden.
    XML-Dev</dd>
    <dd><a
      href="http://lists.xml.org/archives/xml-dev/200008/msg00239.html">http://lists.xml.org/archives/xml-dev/200008/msg00239.html</a></dd>
  <dt><a id="ref-URI" name="ref-URI">URI</a></dt>
    <dd>RFC2396. <em>Uniform Resource Identifiers (URI): Generic Syntax.</em>
      T. Berners-Lee, R. Fielding, L. Masinter. August 1998<br />
      <a
      href="http://www.ietf.org/rfc/rfc2396.txt">http://www.ietf.org/rfc/rfc2396.txt</a></dd>
</dl>
</div>
</body>
</html>