You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
735 lines
36 KiB
735 lines
36 KiB
<?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 <<a
|
|
href="mailto:reagle@w3.org">reagle@w3.org</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 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 <<a
|
|
href="mailto:reagle@w3.org">reagle@w3.org</a>> 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>
|