XML Encryption Requirements

Status of this Document

This is rough draft intended to start discussion in preparation of the XML Encryption Workshop. This document has no standing whatsoever.

This document does not represent consensus. Instead, it is the author's attempt to show requirements and alternatives within the scope already out-line in the XML-Encryption Call for Proposal. Furthermore, it may include things that are not well stated, as well as provocative or contrary positions (or alternative wordings) in order to elicit review and discussion. It's roughly based on the authors understanding of {Imamura}, {SL}, {C2000} and other discussion and proposals, though my characterizations may be in error. Positions which are potentially in conflict are specified as a list of lettered points. For example:

Extensibility

Position
Alternative/Contrary Position

Citation of a source (e.g., {source}) in no way indicates that is the originator or sole supporter of that requirement, it just helps me keep track of at least one source/motivation of the requirement.

Please send comments to the editor <reagle@w3.org> and cc: the list xml-encryption@w3.org (achives) 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.

2. Design Principles and Scope

This section describes requirements over intended result, how these motivations are realized are addressed in subsequent sections.

The XML Encryption specification will describe how to a digitally encrypt a Web resource in general, and an XML document in particular. {Imamura, SL}
1. An XML Encryption can apply to a part or totality of an XML document.
  1. Granularity of encryption is limited to an element. {Imamura}
  2. Granularity of encryption includes attribute values and element content. {SL}
  3. Granularity of encryption includes any Information Set Item. {List: Reagle}
2. Encryption can be recursive. {Imamura, SL}
The mechanisms of encryption will be simple: describe how to encrypt/decrypt digital content, XML documents, and portions thereof. {Reagle}
1. Only enough information necessary for decryption need be provided. {Reagle}
2. The specification will not address the confidence or trust applications place in the provision of a key, nor mechanisms of key establishment. {Reagle}
The only key structures that will be defined relate to those necessary to decrypting opaque content. {Reagle}
1. The specification will address both key-encrypting-keys and data keys. {Reagle}
2. Other key structures should be developed under a different namespace. {Reagle}
The specification will not address authorization and access control. {List: Reagle, Simon, Kudoh}
The specification will not address authentication. {List: Reagle}
The specification will use pre-existing data models (e.g., Information Set) and canonicalization methods (e.g., Canonical XML) unless it can explicitly justify the need for a new one. {Reagle}
Implementation/Design Philosophy
1. Parser
  1. Implementations must work with pre-existing parsers. {MyProof}
  2. Implementations must rely upon namespace aware and schema validating parsers. {Reagle}
2. XML Instances
  1. Implementations must work over pre-existing XML. {MyProof}
3. XML Processing, the transformation/processing model should be
  1. Fast {List: Ferguson}
  2. Memory efficient {List: Ferguson}
  3. Work with tree and event based parsers {List: Ferguson}

3. Requirements

Encryption Data Model and Syntax

An encrypted object is XML. {Imamura, SL}
The XML Encryption data structures will be predicated on: {Reagle}
1. the RDFS schema within the Information Set specification [Infoset]
2. [XSet]
3. ...
An XML Encryption application must be able to use and understand {Reagle}
1. XML-namespaces [XML-namespaces].
2. XML Schema [XML-schema]
XML Encryption can be applied to any Web resource -- including non-XML content. {Imamura, SL}
Encrypted objects are first class objects themselves and consequently can be referenced and signed. {Reagle}
Algorithm Identification
1. Whenever possible, any resource or algorithm is a first class object, and identified by a URI. {Imamura, SL}

Cryptography

The solution must work with arbitrary encryption algorithms, including symmetric and asymmetric keys schemes as well as dynamic negotiation of keying material. {Imamura, SL}
1. The specification will not address key establishment methods. {Reagle}
The specification must specify at least one mandatory to implement canonicalization, hash, and encryption algorithm. {Reagle}
1. Encryption
  1. TripleDES {List: Ferguson}
  2. AES {List: Ferguson}
2. Canonicalization
  1. Canonical XML [XML-C14N]

Canonicalization

Processing

Validity (attempt 1:instances)
1. upon encryption
  1. must still be valid in the original namespace. {List: Reagle}
  2. must be only well formed. {List: Reagle}
  3. must be valid in a new namespace with modified schema. {List: Reagle}
2. upon decryption
  1. must be as valid as the original {List: Reagle}
Validity (attempt 2:parsers)
1. XML Encryption applications need only operate over well formed namespace-aware XML. {Reagle}
2. XML Encryption applications must be schema aware and permit alterations to the target such that encryption modifications are made where permitted by its schema content model? (What happens if forbid by schema?) {Reagle}
3. XML Encryption applications must not violate the DTD/schema valid of the target instance. "We have encountered several applications where the customer wishes to encrypt attribute or element CDATA without changing, adding, or deleting any XML tags." {MyProof}
  1. To satisfy this requirement the document to be encrypted SHOULD be referenceable from an external document via XPath. {MyProof}
  2. Any "[XPath] feature causes serious performance problems because the document must be fully buffered in order to apply the XPath expression." {Andy Clark}
The transformation/processing model should be based on:
1. Application specific logic {List: Ferguson}
2. XSLT {List: Ferguson}
3. XPath {MyProof}
4. XLink {List: Maruyama}

Misc

@@Where did we stand on the issue of email headers encryptor/recipient?

Coordination

The XML Encryption specification should meet the requirements of (so as to support) or work with the following applications:

XML Authorization {List: Scherling, Damiani}
[XML Protocols] {Reagle}
[XML Signature] {Reagle}

To ensure the above requirements are adequately addressed, the XML Encryption specification must be reviewed by a designated member of the following communities:

XML Schema Working Group {Reagle}
XML Core Working Group {Reagle}
XML Protocol Working Group {Reagle}
Internationalization Interest Group {Reagle}

Intellectual Property

The specification should be free of encumbering technologies: requiring no licensing fees for implementation and use. {List: Ferguson}

4. References

Imamura: Another proposal of XML Encryption, Takeshi Imamura (Mon, Aug 14 2000)

C2000: Crypto 2000 XML Encryption BoF (minutes). Santa Barbara. August 24 .
DOM: Document Object Model Core, Level 3. Arnaud Le Hors. W3C Working Draft.
http://www.w3.org/TR/DOM-Level-3-Core/core.html
List: XML Encryption List (an unmoderated and unchartered publis list).
MyProof: MyProof Position Paper On XML Encryption
InfoSet: XML Information Set, W3C Working Draft. John Cowan.
http://www.w3.org/TR/xml-infoset.
SL: XML Encryption strawman proposal Ed Simon and Brian LaMacchia (Wed, Aug 09 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. Working Draft. J. Boyer. September 2000.; http://www.w3.org/TR/2000/WD-xml-c14n-20000907
XML-ns: Namespaces in XML Recommendation. T. Bray, D. Hollander, A. Layman. Janaury 1999.; http://www.w3.org/TR/1999/REC-xml-names-19990114
XML-schema: XML Schema Part 1: Structures Working Draft. D. Beech, M. Maloney, N. Mendelshohn. April 2000.; http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/
XML Schema Part 2: Datatypes Working Draft. P. Biron, A. Malhotra. April 2000.; http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/
XMLDSIG: XML-Signature Syntax and Processing. Working Draft. D. Eastlake, J. Reagle, and D. Solo.
http://www.w3.org/TR/2000/WD-xmldsig-core-20000918/
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

XML-Encryption Requirements

Draft 2000-October-06