XML Encryption Requirements XML Encryption Requirements W3C Note 04 March 2002 This version: http://www.w3.org/TR/2002/NOTE-xml-encryption-req-20020304 Latest version: http://www.w3.org/TR/xml-encryption-req Previous version: http://www.w3.org/TR/2001/WD-xml-encryption-req-20011018 Editor: Joseph Reagle < [email protected] Copyright W3C ® MIT INRIA Keio liability trademark document use software licensing Abstract 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. Status of this Document This is the XML Encryption Requirements Note from the XML Encryption Working Group Activity Statement XML Encryption Syntax and Processing specification Last Call (issues) 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 http://www.w3.org/TR/ Please send comments to the editor < [email protected] [email protected] archived Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page Table of Contents Introduction Design Principles and Scope Requirements Encryption Data Model and Syntax Objects Processing Algorithms and Structures Security Coordination Intellectual Property References 1. Introduction The XML 1.0 Recommendation [ XML 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. The XML Encryption specification must describe how to use XML to represent a digitally encrypted Web resource (including XML itself). { prop1 prop2 The specification must provide for the encryption of a part 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 Comment: After much discussion about the requirements, complexities, and alternatives of attribute encryption {List: Hallam-Baker Simon Reagle 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 prop2 } The specification must allow for the super-encryption of data (i.e., encrypting XML in which some elements are already encrypted). { prop1 prop2 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 3. Requirements 1. Encryption Data Model The XML data model 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 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} 2. Objects 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 FTF1 3. Processing Parsing { WS XML Encryption applications must be XML-namespaces [ XML-namespaces XML Encryption applications must be XML Schema [ XML-schema 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. Provide information on how to restore the document to its original state via application context (e.g., headers). { List Reagle The processing model List Ferguson FTF1 The referencing model Reference Processing Model XMLDSIG As recommended by [ XMLDSIG 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 List Reagle 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 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 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). 4. Algorithms 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 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 FTF1 The specification should leverage the XML Signature specification's syntax for keying information (dsig:KeyInfo element) to the maximum extent possible.{ prop3 FTF1 5. Security 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 ) decrypted XMLDSIG Only What is "Seen" Should be Signed 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. 6. Coordination The XML Encryption specification should meet the requirements of (so as to support) or work with the following applications: XW3C XML Signature W3C XML Protocols Oasis XML-Based Security Services TC (SSTC) Synchronized Multimedia Integration Language List Simon 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 8 Intellectual Property 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. 4. References C2000 Crypto 2000 XML Encryption BoF DOM Document Object Model Core, Level 3 http://www.w3.org/TR/DOM-Level-3-Core/core.html FTF1 XML Encryption Face-to-Face HP Requirements and Goals for the Design of an 'XML Encryption Standard' Gerald Huck and Arne Priewe. November 2000. InfoSet XML Information Set http://www.w3.org/TR/2001/REC-xml-infoset-20011024/ List XML Encryption List MIME RFC2046. MIME Part Two: Media Types November 1996. http://rfc.net/rfc2046.html MyProof MyProof Position Paper On XML Encryption prop1 XML Encryption strawman proposal prop2 Another proposal of XML Encryption prop3 XML Encryption Syntax and Processing WS W3C XML Encryption Workshop minutes 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. 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 http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XML Schema Part 2: Datatypes http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ XML-Signature Syntax and Processing. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ Decryption Transform for XML Signatur http://www.w3.org/TR/2002/CR-xmlenc-decrypt-20020304 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. http://www.ietf.org/rfc/rfc2396.txt