XML Encryption Draft Requirements

Status of this Document

This is draft intended to capture the consensus at the 01 March 2001 face-to-face meeting {FTF1}. This document has no formal status or standing yet, but it is hoped it will be issued as a Working Draft by the Working Group (WG) soon. Consequently, this document does not necessarily represent consensus. It's roughly based on the authors understanding of {prop1}, {prop2}, {prop3}, {C2000}, {WS}, {FTF1} and other discussion and proposals. Positions which are potentially in conflict are specified as a list of lettered points. For example:

1. Extensibility
2. 1. Position
   2. Alternative/Contrary Position

Additionally, editorial comments to the WG or reviewers is surrounded by a box.

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

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

Abstract

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.

Table of Contents

1. Introduction
2. Design Principles and Scope
3. Requirements
   1. Encryption Data Model and Syntax
   2. Objects
   3. Processing
   4. Algorithms and Structures
   5. Security
   6. Coordination
   7. Intellectual Property
4. References

1. Introduction

The XML 1.0 Recommendation [XML] describes the syntax of a class of data objects called XML documents. There is interest in a specification of XML syntax and processing for encrypting digital content, including portions of XML documents and protocol messages. This documents provides requirements for such a specification.

2. Design Principles and Scope

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.

1. 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., referenced) and represented by a distinct element type.
   1. The specification must provide for the encryption of a part or totality of an XML document
      1. Granularity of encryption is limited to an element (including start/end tags) or element content (between the start/end tags). {prop2, WS, FTF1}

         The Working Group (WG) solicits comment on this requirement from the broader community. After much discussion about the requirements, complexities, and alternatives of attribute encryption {List: Hallam-Baker, Simon, Reagle} the WG has decided to  proceed under the requirement of element encryption while remaining open to further comment, experimentation and specification of attribute encryption proposals or alternatives that satisfy the requirement to encrypt sensitive attribute values.

   2. 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}
   3. The specification must allow super-encryption of data (i.e,, encrypting XML in which some elements are already encrypted). {prop1, prop2}Super-encrpted data must use the same syntax and semantics as any other encrypted data.

3. The mechanisms of encryption must be simple: describe how to encrypt/decrypt digital content, XML documents, and portions thereof. {Reagle}
   1. 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.
   2. The specification will not address the confidence or trust applications place in the provision of a key
   3. The specification will not address authentication. {List: Reagle, WS}
   4. The specification will not address authorization and access control. {List: Reagle, Simon, Kudoh, WS}
4. The Working Group (WG) must use pre-existing specifications unless it can explicitly justify the need for a new one. {Reagle}For example, its should use Information Set as a data model for XML instances and Canonical XML for canonicalization.
5. The specification must define a minimal set of algorithms and key structures necessary for interoperability purposes. {Reagle}
6. The specification should strive to limit optionality and maximize extensibility such that all of the specification can be quickly implemented
7. 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}

3. Requirements

1. Encryption Data Model and Syntax

1. The XML data model used by XML Encryption in identifying or representing data that has been processed must be predicated on:
   1. a simple enumerated subset of InfoSet items (e.g., element, attribute, etc.) and properties {e.g., child, parent, localname, prefix, etc.) {WS}

      The WG is still working on this issue in the context of our XML processing model and its relationship to tree and event based parsers.

2. XML Encryption can be applied to any Web resource -- including non-XML content. {prop1, prop2} Also, see Requirements: Objects.
   1. 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.  It is an application decision whether to include the encrypted object cipher data with 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} 

2. Objects

1. It must be possible to indicate the original type (i.e., 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. 
2. Binary data must be encoded as Base64 when represented in XML. {FTF1}
3. 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.
4. 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}

3. Processing

1. Parsing  {WS}
   1. XML Encryption applications must be XML-namespaces [XML-namespaces] aware.
   2. XML Encryption applications must be XML Schema [ XML-schema] aware in that they create XML encryption instances conforming to the schema definition. {Reagle}
   3. 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 considerations are outside the scope of the XML Encryption specification.
2. XML Instance Validity {WS}
   1. 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.)
   2. Instance authors that want to validate encrypted instances must do one of the following:
      1. 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.
      2. Provide a post-encryption schema for validating encrypted instances.
      3. Only encrypt PCDATA text of element content and place its decryption and key information in an external document. (This requires granular detached /external encryption.)
3. The processing model must be described using Information Set terminology and implementations can be based on application specific logic (e.g., XPath and DOM are not required).  {List: Ferguson, FTF1}

   The WG is still working on understanding its processing model requirements.

4. The referencing model must be based on XML Signature's Reference Processing Model [XMLDSIG] with the following two qualifications:
   1. As recommended by [XMLDSIG], where a referencing mechanism supports transforms any fragment processing should be specified as part of the transform.
   2. Where a referencing mechanism does not support Transforms, applications should support same-document XPointers '#xpointer(/)' and '#xpointer(id("ID"))'.
5. Transforms  {WS}
   1. 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}
6. Encryption and Signatures
   1. 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.
      1. Applications have the following options:
         1. 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}
         2. Employ the "decrypt-except" signature transform, being developed as a separate specification. 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 WG is continuing to discuss these options and others.

7. The encryption and XML processing should be
   1. Fast {List: Ferguson}
   2. Memory efficient {List: Ferguson}
   3. Work with tree and event based parsers {List: Ferguson}

4. Algorithms and Structures

1. The solution must work with arbitrary encryption algorithms, including symmetric and asymmetric keys schemes as well as dynamic negotiation of keying material. {prop1, prop2}
2. The specification must specify or reference one mandatory to implement algorithm for only the most common application scenarios.
   1. Stream Encryption Algorithms {FTF1}
      1. none
   2. Block Encryption Algorithms {FTF1}
      1. AES with CMS keylength is required to implement
      2. 3DES is required to implement -- this may be relaxed when AES as matures.
      3. AES at other keylengths is optional to implement.
   3. Chaining Modes {FTF1}
      1. CBC (Cipher Block Chaining) with PKCS#5 padding is optional to implement.
   4. Key Transport {FTF1}
      1. RSA-OEAP used with AES is required to implement.
      2. RSA-v1.5 used with 3DES is required to implement -- this may be relaxed as AES matures.
   5. Key Agreement {