This document lists the design principles, scope, and
requirements for the XML Encryption. It includes requirements as
they relate to the encryption syntax, data model, format,
cryptographic processing, and external requirements and
coordination.
Status of this Document
This is the Last Call for the XML Encryption Requirements
Working Draft from the XML Encryption Working
Group (Activity
Statement). This version represents the consensus of the
Working Group since March 2001 on the requirements of the XML
Encryption Syntax and Processing document. The last call period is
3 weeks, ending on 9 November 2001.
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 http://www.w3.org/TR/.
Please send comments to the editor <reagle@w3.org> and cc: the
list xml-encryption@w3.org (archives)
Patent disclosures relevant to this specification may be found
on the Working Group's patent
disclosure page in conformance with W3C policy.
The XML 1.0 Recommendation [XML]
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.
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.
- The XML Encryption specification must describe how to use XML
to represent a digitally encrypted Web resource (including XML
itself). {prop1, prop2}. 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.
- The specification must provide for the encryption of a part or totality of
an XML document
- Granularity of encryption in an XML document is limited to an
element (including start/end tags) or element content (between the
start/end tags). {prop2, WS, FTF1}
- The specification must provide for the separation of encryption information from
encrypted data, and support reference mechanisms for addressing
encryption information from encrypted data sections and vice-versa.
{HP: R3.7, prop2}
- The specification must allow for the super-encryption of data
(i.e., encrypting XML in which some elements are already
encrypted). {prop1, prop2} Super-encrypted data must use the same
syntax and semantics as any other encrypted data.
- 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:
- Carrying an encrypted key value that is encrypted to the
recipient with an asymmetric or symmetric cipher.
- Providing a name or URI reference to a known key
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.
- The mechanisms of encryption must be simple: describe how to
encrypt/decrypt digital content, XML documents, and portions
thereof. {Reagle}
- 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.
- The specification will not address the confidence or trust
applications place in the provision of a key
- The specification will not address authentication. {List:
Reagle, WS}
- The specification will not address authorization and access
control. {List:
Reagle,
Simon,
Kudoh, WS}
- 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.
- The specification must define a minimal (extensible) set of
algorithms and key structures necessary for interoperability
purposes. {Reagle}
- The specification should strive to limit optionality and
maximize extensibility such that all of the specification can be
quickly implemented
- Whenever possible, any encryption resource or algorithm is a
first class object (which can also be encrypted or signed), and
identified by a URI. {prop1, prop2}
1. Encryption Data Model
and Syntax
- The XML data
model used by XML Encryption in identifying or representing
data that has been processed must be predicated on:
- a simple enumerated subset of the data model (e.g., element,
attribute, etc.) and properties {e.g., child, parent, localname,
prefix, etc.) {WS}
- XML Encryption can be applied to any Web resource -- including
non-XML content. {prop1, prop2} Also, see Requirements: Objects.
- 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}
- 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.
- Binary data must be encoded as Base64 when represented in XML.
{FTF1}
- 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.
- 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. {prop3: open issue 2,
resolved at FTF1}
- Parsing {WS}
- XML Encryption applications must be XML-namespaces [XML-namespaces] aware.
- XML Encryption applications must be XML Schema [ XML-schema] aware in that they create
XML encryption instances conforming to the encryption schema
definitions. {Reagle}
- 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.
- XML Instance Validity {WS}
- 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.)
- Instance authors that want to validate encrypted instances must
do one of the following:
- 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.
- Provide a post-encryption schema for validating encrypted
instances.
- Only encrypt PCDATA text of element content and place its
decryption and key information in an external document. (This
requires granular detached /external
encryption.)
- The processing model 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). {List:
Ferguson, FTF1}
- The referencing model must be based on
XML Signature's
Reference Processing Model [XMLDSIG] with the following two
qualifications:
- As recommended by [XMLDSIG], where
a referencing mechanism supports transforms any fragment processing
should be specified as part of the transform.
- Where a referencing mechanism does not support Transforms,
applications should support same-document XPointers '#xpointer(/)'
and '#xpointer(id("ID"))'.
- Transforms {WS}
- 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. {FTF1}
- Encryption and Signatures
- 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.
- Applications have the following options:
- When data is encrypted, so is its Signature; consequently those
Signature you can see can be validated. (However,
this is not always easily accomplished with detached
Signatures.){List:
Finney}
- Employ the "decrypt-except" [XML-DSIG-Decrypt] 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. {List:
Maruyama, FTF1}.
- The encryption and XML processing should be
- Fast {List:
Ferguson}
- Memory efficient {List:
Ferguson}
- Work with tree and event based parsers {List:
Ferguson}
- The solution must work with arbitrary encryption algorithms,
including symmetric and asymmetric keys schemes as well as dynamic
negotiation of keying material. {prop1, prop2}
- The specification must specify or reference one mandatory to
implement algorithm for only the most common application scenarios.
- Stream Encryption Algorithms {FTF1}
- none
- Block Encryption Algorithms {FTF1}
- AES with CMS keylength is required to implement
- 3DES is required to implement -- this may be relaxed when AES
as matures.
- AES at other keylengths is optional to implement.
- Chaining Modes {FTF1}
- CBC (Cipher Block Chaining) with PKCS#5 padding is optional to
implement.
- Key Transport {FTF1}
- RSA-OAEP used with AES is required to implement.
- RSA-v1.5 used with 3DES is required to implement -- this may be
relaxed as AES matures.
- Key Agreement {FTF1}
- Diffie-Hellman is optional to implement
- Symmetric Key Wrap {FTF1}
- AES KeyWrap is mandatory -- when it's completely
specified.
- CMS-KeyWrap-3DES is required.
- Message Integrity
- AES/3DES with SHA1 is optional to implement.
- Message Authentication {FTF1}
- XML Signature [XMLDSIG] is
recommended to implement.
- Canonicalization {FTF1}
- Canonical XML is optional to implement.
- Compression {FTF1}
- none
- Key
Structures
- Scope: the only defined key structures must be those required
by the mandatory and recommended algorithms. {Reagle}
- The specification should not address how to specify the
intended recipient of keying information beyond an optional "hint"
attribute. {prop3: open issue 1, FTF1}
- The specification should leverage the XML Signature
specification's syntax for keying information (dsig:KeyInfo
element) to the maximum extent possible.{prop3, FTF1}
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.
At a minimum, the following types of vulnerabilities must be
addressed.
- Security issues arising from known plain-text and data length
information
- An attacker may know the original structure of the plain-text
via its schema. {List:
Wiley}
- An attacker may know the length and redundancy of the
plain-text data. {List:
Finney}
- Processing of invalid decrypted data if an integrity checking
mechanism is not used in conjunction with encryption. {List:
Lambert, FTF1}
- Potential weaknesses resulting from combining signing and
encryption operations.
- 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). {List:
Finney}
- encrypt before you sign: Users might mistakenly sign encrypted
data under a semantic (e.g., asserts or agrees to)
associated with the data's decrypted form. [XMLDSIG: Only What is
"Seen" Should be Signed]. 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.") {List:
Wang,
Ashwood}.
- The specification should warn application designers
and users about revealing information about the encrypted data
- via any semantics inferred from a URI.
The XML Encryption specification should meet the requirements of
(so as to support) or work with the following applications:
To ensure the above requirements are adequately addressed, the
XML Encryption specification must be reviewed by a designated
member of the following communities:
- XML Signature WG
- XML Protocol
- XML Schema WG
- XML Core WG
- Internationalization IG
- The specification should be free of encumbering technologies:
requiring no licensing fees for implementation and use. {List:
Ferguson}
"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."
XML Encryption Charter.
- C2000
-
Crypto 2000 XML Encryption BoF. Santa Barbara, CA. August 24
.
- DOM
- Document
Object Model Core, Level 3. Arnaud Le Hors. W3C Working Draft.
January 2001.
http://www.w3.org/TR/DOM-Level-3-Core/core.html
- FTF1
-
XML Encryption Face-to-Face. Boston, MA. March 2000
- HP
-
Requirements and Goals for the Design of an 'XML Encryption
Standard'. Gerald Huck and
Arne Priewe. November 2000.
- InfoSet
- XML Information Set, W3C Proposed Recommendation. John Cowan.
August 2001.
- http://www.w3.org/TR/2001/PR-xml-infoset-20010810/
- List
- XML
Encryption List (an unmoderated and unchartered public
list).
- MIME
- RFC2046. MIME Part Two: Media Types November 1996.
- http://rfc.net/rfc2046.html
- MyProof
-
MyProof Position Paper On XML Encryption. Steve Wiley.
- prop1
-
XML Encryption strawman proposal. Ed Simon and Brian
LaMacchia. Aug 09 2000.
- prop2
-
Another proposal of XML Encryption. Takeshi Imamura. Aug 14
2000.
- prop3
-
XML Encryption Syntax and Processing. Dillaway, Fox, Imamura,
LaMacchia, Maruyama, Schaad, Simon. December 2000.
- WS
- W3C
XML Encryption Workshop [minutes].
SanFrancisco. November 2, 2000.
- XML
- Extensible Markup Language (XML) 1.0 Recommendation. T. Bray,
J. Paoli, C. M. Sperberg-McQueen. February 1998.
- http://www.w3.org/TR/1998/REC-xml-19980210
- XML-C14N
- Canonical
XML. W3C Recommendation. J. Boyer. March 2001.
- http://www.w3.org/TR/2001/REC-xml-c14n-20010315
http://www.ietf.org/rfc/rfc3076.txt
- XML-ns
- Namespaces in XML Recommendation. T. Bray, D. Hollander, A.
Layman. January 1999.
- http://www.w3.org/TR/1999/REC-xml-names-19990114/
- XML-schema
- XML
Schema Part 1: Structures W3C Recommendation. D. Beech, M.
Maloney, N. Mendelsohn, H. Thompson. May 2001.
- http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
XML
Schema Part 2: Datatypes W3C Recommendation. P. Biron, A.
Malhotra. May 2001.
- http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
- XMLDSIG
-
XML-Signature
Syntax and Processing. W3C Proposed Recommendation. D.
Eastlake, J. Reagle, and D. Solo. August 2001.
- http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/
- XML-DSIG-Decrypt
- Decryption Transform for XML Signature. W3C Working Draft. T.
Imamura and H. Maruyama.
- http://www.w3.org/TR/2001/WD-xmlenc-decrypt-20010626
- XSet
- Full Fidelity Information Set Representation. Jonathan Borden.
XML-Dev
- http://lists.xml.org/archives/xml-dev/200008/msg00239.html
- URI
- RFC2396. Uniform Resource Identifiers (URI): Generic
Syntax. T. Berners-Lee, R. Fielding, L. Masinter. August
1998
http://www.ietf.org/rfc/rfc2396.txt