Technology Reports of XML and Encryption:

The World Wide Web Consortium (W3C) has announced the publication of XML Encryption Syntax and Processing and Decryption Transform for XML Signature as W3C Recommendations, signifying a “cross-industry agreement on an XML-based approach for securing XML data in a document. A W3C Recommendation indicates that a specification is stable, contributes to Web interoperability, and has been reviewed by the W3C Membership, who favor its widespread adoption.” The Encryption document “specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data.” The Decryption Recommendation “specifies an XML Signature ‘decryption transform’ that enables XML Signature applications to distinguish between those XML Encryption structures that were encrypted before signing (and must not be decrypted) and those that were encrypted after signing (and must be decrypted) for the signature to validate.”

W3C Specifications for XML Encryption Released as Proposed Recommendations. The W3C XML Encryption Working Group has released Proposed Recommendation specifications for XML Encryption Syntax and Processing and Decryption Transform for XML Signature. Pending review of comments from the W3C Advisory Committee Members and the public, the specifications may reach Recommendation status after November 14, 2002. The XML Encryption document “specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data.” The Decryption document “specifies an XML Signature ‘decryption transform’ that enables XML Signature applications to distinguish between those XML Encryption structures that were encrypted before signing (and must not be decrypted) and those that were encrypted after signing (and must be decrypted) for the signature to validate. XML Encryption is a method whereby XML content can be transformed such that it is discernable only to the intended recipients, and opaque to all others. There are many applications for such a specification given the increasing importance of XML on the Internet and Web including the protection of payment and transaction information.” [Full context]

XML Encryption Candidate Recommendation. XML Encryption Syntax and Processing. W3C Candidate Recommendation 02-August-2002. Edited by Donald Eastlake and Joseph Reagle.Second W3C Candidate Recommendation from the XML Encryption Working Group. “This document specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data.” See the “XML Encryption Implementation and Interoperability Report.”

[March 04, 2002] W3C XML Encryption Working Group Releases Candidate Recommendation Specifications. The W3C XML Encryption Working Group has published an updated XML Encryption Requirements document and has approved the release of XML Encryption Syntax and Processing and Decryption Transform for XML Signature as Candidate Recommendation specifications. The working group expects to meet the exit criteria for the two CRs, but solicits additional feedback (until April 25, 2002) based upon on implementation experience. The requirements specification outlines “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.” The core specification for XML Encryption Syntax and Processing defines “a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption EncryptedData element which contains (via one of its children’s content) or identifies (via a URI reference) the cipher data. When encrypting an XML element or element content the EncryptedData element replaces the element or content (respectively) in the encrypted version of the XML document. When encrypting arbitrary data (including entire XML documents), the EncryptedData element may become the root of a new XML document or become a child element in an application-chosen XML document.” The Decryption Transform document ” specifies an XML Signature “decryption transform” that enables XML Signature applications to distinguish between those XML Encryption structures that were encrypted before signing (and must not be decrypted) and those that were encrypted after signing (and must be decrypted) for the signature to validate.” [Full context]

[January 25, 2001] W3C Approves XML Encryption Activity. Joseph Reagle (W3C Policy Analyst, IETF/W3C XML-Signature Co-Chair) posted an announcement to the Public XML Encryption List ‘xml-encryption@w3.org’ indicating that an official W3C XML Encryption Activity has been approved. The XML Encryption Charter has been reviewed by the W3C Advisory Committee, Team, and Director. The [draft] charter says, in part: “The mission of this working group is to develop a process for encrypting/decyrpting digital content (including XML documents and portions thereof) and an XML syntax used to represent the (1) encrypted content and (2) information that enables an intendent recipient to decrypt it. XML Encryption is a method whereby XML content can be transformed such that it is discernable only to the intended recipients, and opaque to all others. There are many applications for such a specification given the increasing importance of XML on the Internet and Web including the protection of payment and transaction information. The proposed work will obviously address how to encrypt an XML documents including elements. The following additional requirements must be met by the WG; these requirements must be augmented and extended by the Requirements Document deliverable: (1) The mechanisms of encryption must be simple: describe how to encrypt/decrypt digital content, XML documents, and portions thereof. a) Only enough information necessary for decryption need be provided. b) The specification must not address authorization, authentication, nor the confidence or trust applications place in the provision of a key though it should enable (or at least not hinder) such XML based technologies. (2) XML-Encryption must be coordinated with and use the work product of other mature XML technologies including XML Schema and XML Signature. (See Coordination) (3) The mandatory portions of the specification must be implemented in at least two independent implementations before being advanced to Proposed Recommendation. The core scope of this activity will be in specifying the necessary data model, syntax, and processing to encrypt XML content. The Working Group (WG) will: (1) Specify a requirements document that further defines the scope and requirements of the WG’s deliverables. (2) Specify the syntax and processing necessary for creating XML Encryption content. The WG should decide what level of granularity is appropriate with the meta-requirement that the design be simple to implement and quickly deployable. (3) Choose a data model (and representation via XML element types or URIs) for describing any necessary public characteristics of the encrypted content (e.g., the data encrypted is an http://someURI#elementNode). The WG must use pre-existing models such as Information Set, XPath, SetX, or DOM. (4) Choose a method (that can be optional) to canonicalize XML prior to encryption such that it can be decrypted consistently. The WG must use a pre-existing canonicalization method such as Canonical XML. (5) Specify a minimal set of encryption and key information for interoperability purposes. This may be a separate document or part of the specification. (6) Address security concerns arising from the design and its implementation. This may be a separate document or part of the specification. (7) Optionally, develop a document of scenarios and recommendations regarding the affects and requirements of XML Encryption processing on XML parsing and validation. This must be a separate document. (8) Redefine the charter for subsequent work once (1-7) has been achieved. The requirement document must specify and describe the WG’s choice with respect to the granularity of encryption, the data model and representation resulting from that choice, and the necessity and choice of canonicalization algorithms. The WG must rely upon existing W3C specifications as building blocks to its own design, unless the WG can demonstrate these specifications fail to meet the requirements of XML Encryption applications. In which case the WG must give a strong rationale and obtain Director approval.” The web site for the XML Encryption WG is publicly accessible.

source: http://xml.coverpages.org/xmlAndEncryption.html