[December 10, 2002]   XML Encryption and Decryption Specifications Published as W3C Recommendations.    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."

[October 07, 2002]   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. Authors: Takeshi Imamura, Blair Dillaway, and Ed Simon. Version URL: http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/. Latest version URL: http://www.w3.org/TR/xmlenc-core/. Previous version: http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/. 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.

Principal References

• W3C XML Encryption Working Group
• Mailing list archives for 'xml-encryption'
• XML Encryption Requirements
• XML Encryption Syntax and Processing
• Decryption Transform for XML Signature
• XML Encryption Implementation and Interoperability Report
• Additional XML Security URIs. This memo defines a number of URIs intended for use with XML Digital Signatures, Encryption, and Canonnicalization. These URIs identify algorithms and types of keying information." [ID-Tracker]
• "XML and Security": General references.

General: News, Articles, Reports, Drafts

• [December 26, 2002] "Safeguard Your XML-Based Messages: Create Secure Web Services With Apache XML Security." By Tarak Modi. In Java World (December 20, 2002). With source code. ['Apache XML Security is an open source implementation of the XML Digital Signature specification that allows you to digitally sign your Web service messages. Digital signatures assure your messages' receivers that the messages are really from you. After reading this article, which serves as an introductory tutorial to Apache XML Security, you will be well prepared to start signing your Web services messages.'] "Web services are here to stay, but if you are like most software developers, you worry about the plaintext SOAP (Simple Object Access Protocol) messages being exchanged over the Web. Web services security is a hot topic today because the success of this exciting technology hinges directly upon how secure we can make it. To that end, the World Wide Web Consortium (W3C) has defined the XML Signature and XML Encryption specifications for digitally signing and encrypting XML-based communication messages, such as the SOAP messages used in Web services. Furthermore, companies such as IBM, Microsoft, and VeriSign have partnered to provide additional specifications, such as WS-Security (Web Services Security), that build upon these W3C specifications. And who hasn't heard of the Liberty Alliance Project, a consortium of companies led by Sun Microsystems to provide a standards-based single sign-on solution to Web services? In the midst of all these initiatives lies the Apache XML Security project, an open source project that currently implements the W3C XML Signature specification and will soon support the XML Encryption specification. This article serves as a tutorial to get you up to speed with this outstanding implementation... [the article gives a] whirlwind tour of Apache XML Security and puts it in the context of a real-world example by discussing a use of this library with Axis. By using Apache XML Security with Axis to sign SOAP messages, you gain three of the four secure messaging characteristics mentioned above: namely authentication of origin, nonrepudiation, and message integrity. To gain the fourth characteristic of privacy, you must use XML Encryption. Soon Apache XML Security will support that as well. Also, keep an eye out for announcements related to Java Specification Requests (JSRs) 105 and 106, which the Java Community Process (JCP) is currently working on. The proposed final draft of JSR 105, XML Digital Signature APIs, will define a standard set of APIs for XML digital signatures services. And for those worried developers out there, yes, Apache is on JSR 105's expert group. JSR 106, XML Digital Encryption APIs, will define a standard set of APIs for XML digital encryption services..." See Apache XML Security Project.

• [December 10, 2002] "VeriSign Offers Open Source WS-Security Implementation and Integration Toolkit to Help Developers Integrate Security Into Web Services. Effort Continues VeriSign's Commitment to Driving Trusted Web Services With Royalty-Free Implementation." - "Furthering its commitment to trusted Web services, VeriSign, Inc., the leading provider of digital trust services, announced today the royalty free availability of technology that will allow companies to integrate digital signatures and encryption into Web services. Based on the recently announced WS-Security specification and Addendum, which was co-written by IBM, Microsoft and VeriSign, this implementation provides enterprises, software developers and systems integrators with code they can use to achieve higher levels of trust and security when designing Web services applications and services. Offering this code as open source is intended to accelerate widespread adoption of Web services by making them even easier to secure. In addition, VeriSign announced that it has made available a version of its VeriSign Trust Service Integration Kit (TSIK) with security features for Web services, such as XML Signature, XML Encryption, and XML Key Management Services (XKMS). VeriSign TSIK is a Java-based developer toolkit for integrating security capabilities into Web services. 'Companies simply will not implement Web services until the industry adequately addresses the issues of trust and security,' said Dr. Phillip Hallam-Baker, VeriSign's Principal Scientist and Web Services Security Architect. 'We are helping to address those critical issues by taking a leadership role in providing customers and developers with some extremely useful code that they can implement in their Web services applications today to alleviate those concerns'... VeriSign will provide an open source implementation of WS-Security through its open source libraries, providing resources for building interoperable, trusted Web services using the proposed WS-Security standard. The VeriSign libraries can be deployed to provide protocol support for both client and server applications. In a typical situation, a Web service will rely on these libraries to add secure messaging to whatever business logic the Web service supports. The Trust Service Integration Kit includes three basic components: the messaging framework, the trust layer and XML resources. (1) The messaging framework brings together various VeriSign Application Programming Interfaces (APIs) to provide a robust environment for developing secure, trusted, interoperable Web services. The Java libraries enable developers to create Java objects for sending and receiving XML messages in conjunction with a customer Web service API. (2) The trust layer provides APIs for security XML messages using public key infrastructure (PKI), and includes implementations of two key specifications, W3C XML Digital Signature and XML Encryption. These implementations emphasize ease-of-use over feature coverage... The Trust Verifier provides several mechanisms, including real-time XML Key Management Specification (XKMS) lookups, for establishing whether a public key or certificate chain is trusted. (3) The API also includes low-level resources for directly manipulating XML, building data types, navigating through document structures, validating the format of schemas and interfacing with parsers..."

• [August 26, 2002] "Cryptographically Enforced Conditional Access for XML." Paper presented at the Fifth International Workshop on the Web and Databases (WebDB 2002), Madison, Wisconsin - June 6-7, 2002. By Gerome Miklau and Dan Suciu (University of Washington). [Note: several accepted papers from the workshop cover XML.] "Access control for databases is typically enforced by a trusted server responsible for permitting or denying users access to the database. This server-based protection model is increasingly becoming inconvenient for web based applications. We propose encryption techniques that allow XML documents to be distributed over the web to clients for local processing while maintaining certain access controls. In particular, we focus on conditional access controls, where a user is granted access to certain data elements conditioned on the user's existing knowledge of another part of the data. We believe such access controls are important in practice, and that enforcing them cryptographically on remote instances allows for more efficient data dissemination and processing... An access control model is used to permit or refuse access by subjects to data objects. Subjects are users, or groups of users usually defined by name, network identification or other static affiliation. For XML, objects are documents or parts of documents defined by XPath expressions. Access control in relational database systems, and most proposed XML systems, is enforced by a server that handles all data requests and strictly controls which users can access what data. While this model is sometimes also used in Web applications, it is often too restrictive. As the following examples show, there are a number of advantages to delivering remote copies of the data to clients if access control can be maintained... We propose an approach for publishing XML data on the Web while controlling how the data is accessed. In particular, we propose a novel and flexible language of conditional access rules used to define security policy. We explain how to encrypt XML data to enforce these access controls without a trusted server, and we discuss query processing over encrypted data. Our notion of conditional access generalizes the static categorization of subjects into authorization classes. Subjects are not identified by user name or network identifier but by their knowledge. As a special case, access may be conditioned on knowledge of a private key or password in a conventional way. But more generally, subjects qualify for access to an object by virtue of their knowledge of the data. Conditional access rules specify what data values need to be presented by the subject before granting access to other data values. Subject authorization is therefore flexible and dynamic in a way not possible with conventional access classes. The flexibility of our conditional access rules distinguishes our work from other attempts to encrypt data and manage decryption keys..." [alt URL, cache]

• [August 21, 2002] "Exploring XML Encryption, Part 2. Implement an XML Encryption Engine." By Bilal Siddiqui (CEO, WAP Monster). From IBM developerWorks, XML Zone. August 2002. ['In this second installment, Bilal Siddiqui examines the usage model of XML Encryption with the help of a use case scenario. He presents a simple demo application, explaining how it uses the XML Encryption implementation. He then continues with his last implementation of XML Encryption and makes use of JCA/JCE classes to support cryptography. Finally, he briefly discusses the applications of XML Encryption in SOAP-based Web services.'] "In Part 1 of this series ['Demonstrating the secure exchange of structured data '], I gave an introduction to XML Encryption and its underlying syntax and processing. I examined the different tags and their respective use in XML encryption with a simple example of secure exchange of structured data, proposed a Java API for XML Encryption based on DOM, and gave a brief overview of cryptography in Java (JCA/JCE). I start my discussion in this part with an information exchange scenario which demonstrates the use of XML encryption... Consider the process of information exchange between two enterprises. One is an online books-seller and the other is a publisher. When the books-seller wants to purchase books, it submits a purchase order to the publisher. At the publisher's end, the sales department receives this order, processes it, and forwards it to the accounts department. The two enterprises exchange information in the form of XML documents. Since some portion of the document needs to be secure and the rest can be sent insecurely, XML encryption is the natural approach for applying security to distinct portions of the document... According to the books-seller's security policy, the payment information will only be revealed to the accounts department. The sales department will need to extract only the name of the book, its item ID and the quantity ordered; because this is insensitive information it can remain insecure. The accounts department will need to decrypt the payment information in the purchase order using a pre-exchanged secret key... Mapping this policy, XML Encryption facilitates the concealment of payment information in the sales department and its disclosure in the accounts department... At this point, it may be useful to ponder a bit on the concept of document-based security. With this security architecture, you can impose security at the document level..."

• [June 17, 2002] "application/xenc+xml Media Type Registration." By Joseph M. Reagle Jr. (W3C; Massachusetts Institute of Technology Laboratory for Computer Science). IETF Internet-Draft. Reference: 'draft-reagle-xenc-mediatype-00'. June 2002, expires: October 2002. ['describes a media type (application/xenc+xml) for use with the XML Encryption specification'] "The XML Encryption Syntax and Processing 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 application/xenc+xml media type allows XENC applications to identify XENC documents for processing. Additionally it allows applications cognizant of this media-type (even if they are not XENC implementations) to note that the media type of the decrypted (original) object might a type other than XML. This media-type is only used for documents in which the XENC EncyptedData and EncryptedKey element types appear as the root element of the XML document. XML documents which contain XENC element types in places other than the root element can be described using facilities such as W3C XML-schema or 'Registration of xmlns Media Feature Tag' (StLaurent)..."

• [March 26, 2002] "Exploring XML Encryption, Part 1. Demonstrating the Secure Exchange of Structured Data." By Bilal Siddiqui (CEO, WAP Monster). From IBM developerWorks, XML Zone. March 2002. ['XML Encryption provides end-to-end security for applications that require secure exchange of structured data. XML itself is the most popular technology for structuring data, and therefore XML-based encryption is the natural way to handle complex requirements for security in data interchange applications. Here in part 1 of this two-part series, Bilal explains how XML and security are proposed to be integrated into the W3C's Working Draft for XML Encryption.'] "Currently, Transport Layer Security (TLS) is the de facto standard for secure communication over the Internet. TLS is an end-to-end security protocol that follows the famous Secure Socket Layer (SSL). SSL was originally designed by Netscape, and its version 3.0 was later adapted by the Internet Engineering Task Force (IETF) while they were designing TLS. This is a very secure and reliable protocol that provides end-to-end security sessions between two parties. XML Encryption is not intended to replace or supersede SSL/TLS. Rather, it provides a mechanism for security requirements that are not covered by SSL. The following are a two important areas not addressed by SSL: (1) Encrypting part of the data being exchanged; (2) Secure sessions between more than two parties. With XML Encryption, each party can maintain secure or insecure states with any of the communicating parties. Both secure and non-secure data can be exchanged in the same document. For example, think of a secure chat application containing a number of chat rooms with several people in each room. XML-encrypted files can be exchanged between chatting partners so that data intended for one room will not be visible to other rooms. XML Encryption can handle both XML and non-XML (e.g., binary) data. We'll now demonstrate a simple exchange of data, making it secure through XML Encryption. We'll then slowly increase the complexity of the security requirements and explain the XML Encryption schema and the use of its different elements... In our next installment of this series of articles, we will discuss and implement the details of cryptography. We'll demonstrate the working of encryption and decryption classes and their interaction with parsing logic, and present applications of XML Encryption in Web services."

• [March 06, 2002] "Additional XML Security URIs." By Donald E. Eastlake 3rd (Motorola). IETF Internet-Draft. Reference: 'draft-eastlake-xmldsig-uri-02.txt'. January 2002; expires: July 2002. ['Distribution of this draft is unlimited. It is intended to become an Informational RFC and will probably also be published as a W3C Note. Comments should be sent to the author or the XMLDSIG working group'] Abstract: "A number of algorithm and keying information identifying URIs intended for use with XML Digital Signatures and XML Encryption are defined." From the introduction: "XML Digital Signatures have been standardized by the joint IETF/W3C XMLDSIG working group. The Proposed Standard is specified in RFC 3075 and a Draft Standard version is pending before the IESG [XMLDSIG-D]. Canonical XML, which is used by many digital signatures, has been standardized by the W3C and is documented in Informational RFC 3076. In addition, XML Encryption and Exclusive XML Canonicalization are currently being standardized by the W3C. All of these standards and recommendations use URIs to identify algorithms and keying information types. This document is intended to be a convenient reference list of URIs and descriptions for algorithms in which there is substantial interest but which can not or have not been included in the main documents for some reason. Note in particular that raising XML digital signature to Draft Standard in the IETF requires remove of any algorithms for which there is not demonstrated interoperability from the main standards document. This requires removal of the Minimal Canonicalization algorithm, in which there appears to be continued interest, to be dropped from the standards track specification. It is included here..."

• [October 18, 2001]   Last Call Working Drafts from W3C XML Encryption Working Group.    A posting from Joseph Reagle (W3C XML Encryption Chair) announces the publication of 'last call' working draft specifications from the XML Encryption Working Group. The last call period for the three WDs is 3 weeks, ending on November 9, 2001. From the document abstracts: (1) XML Encryption Requirements 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. (2) XML Encryption Syntax and Processing 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. (3) Decryption Transform for XML Signature specifies the 'decryption transform', which enables XML Signatures verification even if both signature and encryption operations are performed on an XML document." [Full context]

• [June 27, 2001]   First Public Working Draft for W3C XML Encryption Syntax and Processing.    The W3C XML Encryption Working Group has released a first public working draft for XML Encryption Syntax and Processing. The formal model for syntax is provided in W3C XML Schema notation. The working draft "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. 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 an entire XML document, the EncryptedData element may become the root of the new document. And when encrypting arbitrary data, the EncryptedData element may become the root of a new XML document or become a child element in an application-chosen XML document." An experimental namespace URI is provided: xmlns:enc='http://www.w3.org/2001/04/xmlenc#'; the WD specification also makes use of the XML Signature namespace and its schema definitions, xmlns:ds='http://www.w3.org/2000/09/xmldsig#'. [Full context]

• [April 20, 2001]   Requirements Specification for XML Encryption Published by W3C.    The W3C XML Encryption Working Group has released an initial working draft specification for XML Encryption Requirements. The draft 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." Coordination with the several related applications is specified, including W3C XML Signature, W3C XML Protocols, OASIS XML-Based Security Services TC (SSTC), and Synchronized Multimedia Integration Language (SMIL). XML Encryption in the W3C context implies "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 mission of the W3C 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 intended recipient to decrypt it." [Full context]

• [June 21, 2001] XML Encryption Syntax and Processing. Posted to the mailing list xml-encryption@w3.org. WG Working Draft xx-June-2001. Edited by Donald Eastlake and Joseph Reagle. Contributions by Takeshi Imamura, Blair Dillaway, Jim Schaad, and Ed Simon. Abstract: "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." Introduction [excerpt]: "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 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..."

• [May 21, 2001] "Decryption Transform for XML Signature." 10-May-2001. W3C draft document edited by Takeshi Imamura Hiroshi Maruyama as part of the W3C XML Encryption Working Group activity. "This document specifies the 'decryption transform', which enables XML Signatures verification even if both signature and encryption operations are performed on an XML document." Status: "This is a proposal being staged for publication and has (as of yet [2001-05-21]) no W3C status or standing." Excerpt: "Since encryption operations applied to part of the signed content after a signature operation cause a signature not to be verifiable, it is necessary to decrypt the portions encrypted after signing before the signature is verified. The 'decryption transform' proposed in this document provides a mechanism; decrypting only signed-then-encrypted portions (and ignoring encrypted-then-signed ones). A signer can insert this transform in a transform sequence (e.g., before Canonical XML or XPath) if there is a possibility that someone will encrypt portions of the signature. The transform defined in this document is intended to propose a resolution to the decryption/verification ordering issue within signed resources. It is out of scope of this document to deal with the cases where the ordering can be derived from the context. For example, when a ds:DigestValue element or a (part of) ds:SignedInfo element is encrypted, the ordering is obvious (without decryption, signature verification is not possible) and there is no need to introduce a new transform..." See: (1) XML Encryption Working Group, and (2) "XML and Encryption."

• [December 22, 2000] "XML Encryption Syntax and Processing." Version 1.0. 15-December-2000. By Blair Dillaway, Barbara Fox, Takeshi Imamura, Brian LaMacchia, Hiroshi Maruyama, Jim Schaad, and Ed Simon. ['We respectfully submit the attached specification as a suggested starting point for the XML Encryption Working Group effort. This work builds on earlier papers and on-going discussions. We look forward to comments and continuing discussions to resolve the open issues identified in this document.'] "This document specifies how to encrypt data in an XML-conformant manner. It describes how to perform fine-grained, element-based encryption of fragments within an XML Document as well as encrypt arbitrary binary data and include it an XML document. The technical requirements upon which this specification is based are summarized in Section 2. Subsequent Sections describe the XML Encryption syntax, processing rules, and XML Encryption schema along with selected examples of using this technology."

• [October 03, 2001] "XML Security for Multipart MIME: Multipart/Signed and Multipart/Encrypted." IETF Network Working Group, Internet Draft. Reference: 'draft-fhirsch-xml-mime-security-00'. October 1, 2001. Expires: April 1, 2002. By Frederick Hirsch (Zolera Systems). Abstract: "This draft defines how XML Digital Signatures and XML Encryption may be used with Multipart MIME security to provide MIME integrity and confidentiality. It extends RFC 1847 by defining application/signature+xml and application/encryption+xml protocols for the Multipart/Signed and Multipart/Encrypted MIME types. Although non-XML content may be signed or encrypted based on XML signing and encryption, additional capabilities are available for XML MIME content. This draft defines a signature transform parameter for partial signing or manipulation of XML MIME content as well as processing rules in addition to the XML Digital Signature and XML Encryption processing rules." From the Introduction: "RFC 1847 defines a general mechanism for security multiparts in MIME, defining the Multipart/Signed and Multipart/Encrypted types. This mechanism uses a protocol parameter to specify the signature or encryption mechanism. Multipart/Signed enables the first MIME part to contain arbitrary MIME content and the second to contain a signature over that content. Common mail applications currently use application/x-pkcs7-signature as the signing protocol, creating a PKCS#7 signature in the signature part. Multipart/Encrypted uses the first part to contain encryption control information, and the second part encrypted content. An alternative to Multipart/Encrypted is to pass a single MIME part containing encrypted content using using application/x-pkcs7-mime, as done by common mail applications. XML DIGITAL SIGNATURE and XML ENCRYPTION recommendations enable signing and encryption of arbitary content as well as providing advanced support for XML content. This includes the ability to sign or encrypt portions of XML, reference multiple objects in a signature and include metadata information with signed or encrypted content. XML signatures support multiple signatures, useful when content is routed for approvals. Both XML Signatures and Encryption support inclusion of the signature or encrypted content in the orginal XML document, creating a close binding. Signatures may also be separate from the signed content, especially useful when the content is large or binary and would interfere with XML processing of the signature. Likewise, encrypted cipherdata may be included in an XML encrypted element or managed separately. Combining the XML security mechanisms with Multipart MIME security enables MIME applications to benefit from XML security as well as enabling XML security to use a defined mechanism for handling multiple parts. This draft extends the existing Multipart MIME security mechanism by defining two new protocol parameters to be used with RFC 1847, application/signature+xml and application/encryption+xml. These names follow the XML naming convention defined in RFC 3023, XML MEDIA TYPES. This draft defines these parameters and a minimal set of processing rules..." Also in text format.

• [March 26, 2001]   New Java Specification Requests for XML Digital Signature and XML Digital Encryption APIs.    Two new JSRs (Java Specification Requests) have been published relating to Java APIs for XML digital signature and encryption, proposed for work under the Java Community Process. The Specification Leads are Anthony Nadalin (IBM) and Sean Mullan (Sun). JSR-000105 for XML Digital Signature APIs will "define a standard set of APIs for XML digital signatures services. The XML Digital Signature specification is defined by the W3C; this proposal is to define and incorporate the high level implementation independent Java APIs." JSR-000106 for XML Digital Encryption APIs will "define a standard set of APIs for XML digital encryption services. XML Encryption can be used to perform fine-grained, element-based encryption of fragments within an XML Document as well as encrypt arbitrary binary data and include this within an XML document. Today there is no standard set of APIs for XML digital encryption services." [Full context]

• [September 21, 2000] Joseph Reagle Jr. (W3C Policy Analyst, IETF/W3C XML-Signature Co-Chair) issued an announcement for a W3C XML-Encryption Workshop. The workshop is hosted by XCert and will be held Thursday, November 2, 2000 in Lafayette/San Francisco, CA. Workshop participants need not belong to W3C member organizations. Rationale: "If XML is to become the language of trusted Web applications (e.g., electronic commerce) it needs standard mechanisms for digitally signing and encrypting XML entities. Furthermore, this mechanism must be fully functional in environments where only XML tools are available. While the joint IETF-W3C Working Group is completing a XML Digital Signatures specification, its charter expressly precludes work on encryption. Consequently, this Workshop will focus on (1) the requirements for XML encryption, (2) the proposals being discussed on the public XML Encryption list as potential starting points for a specification and (3) the structure of a possible W3C activity to advance such a specification to Recommendation." Topics appropriate for the workshop include: "(1) Scope of encryption: should the scope apply to elements only, or any Information Set Item? How should the scope of encryption be described/identified: should the data model be based on on a simple ad-hoc representation or the complete Information Set? (2) Should the data model be represented via URIs or an XML instance using RDF Schema or XSet? (3) KeyInfo: Given that encryption keys might encrypt content or other keys, in what way must the Signature KeyInfo be extended to handle the common Encryption applications? (4) Digital Signature 'awareness' and syntax alignment: to what degree can XML-Encryption use use similar syntax and algorithm identifiers? (5) Schema design: how will encryption portions of an XML instances affect that instances XML schema validity? (6) Algorithm, modes, and formats: which algorithms and formats MUST be supported? (7) Parser impact: will parser have to either post-process or be 'callback equipped' to avoid re-parsing of an entire document after a portion has been decrypted? (8) What rat holes can be identified as out of scope?..." See further the draft agenda.

• [May 04, 2001]   Experimental Implementation for W3C XML Encryption Specification.    A posting from Takeshi Imamura (Tokyo Research Laboratory, IBM Research) reports on the availability of an experimental implementation of [W3C] XML Encryption Syntax and Processing Version 1.0. Support is implemented in the updated version of the XML Security Suite from alphaWorks. The IBM XML Security Suite "provides security features such as digital signature, element-wise encryption, and access control to Internet business-to-business transactions. The new experimental support for the W3C XML Encryption proposal enables one to encrypt/decrypt arbitrary binary data, an XML element, or its content. The XML Schema definition of XACL [XML Access Control Language] syntax is introduced." Also featured in the IBM implementation is W3C/IETF XML-Signature support conforming to the new Candidate Recommendation of 19-April-2001. [Full context]

• [November 08, 2000] Minutes W3C XML-Encryption Workshop W3C workshop, San Francisco, CA 2 November 2000

• [October 30, 2000] "XML-Encryption Requirements." By Joseph Reagle (W3C). Draft 2000-October-06. "This is rough draft intended to start discussion in preparation of the XML Encryption Workshop. This document has no standing whatsoever. [It represents] 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 [strawman], C2000 [Crypto 2000 XML Encryption BoF] 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..." [cache 2000-10-30]

• [August 10, 2000] W3C XML Encryption Mailing List - 'xml-encryption@w3.org'. "This list is for discussion about XML encryption and related (potential) IETF or W3C activity. The purpose of this list is to foster the development of a community of interest and a set of design issues and requirements that might prompt a BOF or workshop on the topic. This discussion list is public, it is not moderated, and it is not part of an chartered activity of the IETF or W3C. Appropriate content for this list includes discussion of requirements, dependencies, and technical proposals; and drafts of specifications, code, charters and calls for participation. Inappropriate materials include commercial advertisements and announcements that are not immediately relevant to XML encryption. (e.g., general announcements about XML or cryptographic conferences or books.) Please feel free to introduce yourself to the list expressing your own interest or any issues that you think are relevant." The list maintainer is Joseph Reagle (IETF/W3C XML-Signature Co-Chair). To subscribe, send a request to xml-encryption-request@w3.org.

• [February 13, 2001]   XKMS Mailing List and Interest Group Meeting.    Philip Hallam-Baker (VeriSign, Inc.) posted an announcement for a new mailing list to support the work of anyone interested in the development/interoperability/standardization of XKMS. The "XML Key Management Specification (XKMS)" specification defines protocols "for distributing and registering public keys, suitable for use in conjunction with the proposed standard for XML Signature developed by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) and an anticipated companion standard for XML encryption." An XKMS interest group meeting will be held in Cambridge MA on March 01, 2001, coordinated with meetings of the W3C XML Encryption Working Group [the March 1st XML Encryption FTF] and the OASIS XML Security Services Technical Committee. [Full context]

• [November 02, 2000] "Note on XML Encryption." By Takeshi Imamura and Hiroshi Maruyama (IBM Research, Tokyo Research Laboratory). Revised: November 01, 2000. "Consider a situation where two parties communicate encrypted contents each other. There are some scenarios as follows: (1) An originator sends content-encryption keys (or their identifiers) and contents encrypted with them to one or more recipients. For example, when encrypting an e-mail before sending it. (2) An originator sends content-encryption keys first, and then sends contents encrypted with them. For example, when doing SSL-like communications on the application level, or broadcasting encrypted movies to specific receivers. (3) An originator sends only content-encryption keys, while he stores contents encrypted with them on public sites. For example, users buy content-encryption keys first, and they download encrypted music when needed..."

• [October 05, 2000] See previous item for revision. "Note on XML Encryption." By Takeshi Imamura and Hiroshi Maruyama (IBM Research, Tokyo Research Laboratory; Email: {imamu, maruyama}@jp.ibm.com). With 14 references. "Hiroshi "Maruyama and I tried roughly designing the <'EncryptionInfo> element for algorithm and keying information, based on "Specification of Element-wise XML Encryption.". This note illustrates how the element works. We welcome any ideas or comments. Thanks in advance." Posted by Takeshi Imamura (Tokyo Research Laboratory IBM Japan, Ltd.)

• [November 07, 2000] "XML Encryption and Access Control. A comparison and a 2nd encryption model. Draft 29.10.2000. From Christian Geuer-Pollmann (Institute for Data Communications Systems, University of Siegen). Prepared for the W3C XML Encryption Workshop. "...ideas about how XML Encryption and the rich functionality of server-based XML Access Control could be brought together within a single model." [cache]

• [November 07, 2000] Encryption Proposal [Slides]. Presentation slides used at the recent [November 2000] W3C XML Encryption Workshop. From Takeshi Imamura (Tokyo Research Laboratory IBM Research).

• [November 07, 2000] "Requirements and Goals for the Design of an 'XML Encryption Standard'." From Gerald Huck and Arne Priewe. "The following tries to identify some major requirements and also non-requirements for the definition of an XML Encryption Standard (XES), and XML Encryption Language (XEL) for representing encrypted data..."

• [August 10, 2000] "XML Encryption Syntax and Processing." From the W3C public XML Encryption list. "This strawman proposal describes how the proposed W3C XML Encryption specification might look and work should the W3C choose to charter an XML Encryption Work Group. Though it is conceivable that XML Encryption could be used to encrypt any type of data, encryption of XML-encoded data is of special interest. This is because XML's ability to capture the structure and semantics of data unleashes new applications for the area of encryption. To this end, an important design consideration is to not encrypt more of an XML instance's structure and semantics than is necessary. For example, suppose there is an XML instance containing a list of customers including their names, addresses, and credit card numbers. A contracted marketing employee may be entrusted to see the names and addresses but must not see the credit card number. If an application knows it should just be decrypting the content of <name> elements, the XML instance needs to maintain its structure identifying what is a 'name' and what isn't. Otherwise the application would have to decrypt the other data just to find out what it was supposed to be decrypting in the first place which is problematic from both a security and performance point of view. So what level of granularity is needed? XML's document model provides access to a number of node types including elements, attributes, processing instructions, comments, and text nodes. However, because elements and attributes are the nodes intended for defining structure and semantics, the XML Encryption model (illustrated in the following examples) restricts itself to handling those. .. The centerpiece of XML Encryption is the <EncryptedNode> element. It has an attribute, NodeType, which indicates the type of node that was encrypted: element, element content, attribute, or attribute value. The encrypted node appears as a base64-encoded string which forms the content of the <EncryptedNode> element. . ." Contacts: Ed Simon and Brian LaMacchia. Note on the discussion list: "This list is for discussion about XML encryption and related (potential) IETF or W3C activity. The purpose of this list is to foster the development of a community of interest and a set of design issues and requirements that might prompt a BOF or workshop on the topic. This discussion list is public, it is not moderated, and it is not part of an chartered activity of the IETF or W3C." [cache]

• 'XML Security page'. XML security, encryption. Maintained by Christian Geuer-Pollmann (Universität Siegen).

• [August 24, 2000] Minutes of Crypto 2000 XML Encryption BoF, Santa Barbara. August 24, 2000. "Reason for starting [a W3C] XML Encryption WG: Now that the XML signature work (XMLDsig) is mostly complete, the time has come to look at XML encryption. Encryption is the second building block for security protocols." See "XML Encryption BoF at Crypto 2000."

• [August 10, 2000] "Design and Implementation of an Access Control Processor for XML Documents." By Ernesto Damiani, Sabrina De Capitani di Vimercati, Stefano Paraboschi, and Pierangela Samarati. Paper presented at the Ninth International World Wide Web Conference, Amsterdam, Netherlands, 15-19 May 2000. Also published in Computer Networks Volume 33, Number 1-6 (June 2000), pages 59-75. "More and more information is distributed in XML format, both on corporate Intranets and on the global Net. In this paper an Access Control System for XML is described allowing for definition and enforcement of access restrictions directly on the structure and content of XML documents, thus providing a simple and effective way for users to protect information at the same granularity level provided by the language itself." See the diagrams in the paper for the conceptual architecture: "A central authority uses a pool of XML DTDs to specify the format of information to be exchanged within the organization. XML documents instances of such DTDs are defined and maintained at each site, describing the site-specific information. The schema-instance relationship between XML documents and DTDs naturally supports the distinction between two levels of authorizations, both of them allowing for fine grained specifications. Namely, we distinguish: 1) Low-level authorizations, associated to XML documents, providing full control on authorizations on a document-by-document basis; 2) High-level authorizations, associated to XML DTDs, providing organization-wide and department-wide declarations of access permissions. Centrally specified DTD-level authorizations can be mandatory, stating impositions of the central authority to lower organizational levels where XML documents are created and managed, usually by means of a network of federated Web sites. This technique allows for easy, centralized modification of access permissions on large document sets, and provides a general, abstract way of specifying access authorizations. In other words, specifying authorizations at the DTD level cleanly separates access control specified via XML markup from access control policies defined for the individual datasources (e.g., relational databases vs. file systems) which are different from one another both in granularity and abstraction level. Each departmental authority managing a Web site retains the right to define its own authorizations (again, at the granularity of XML tags) on individual documents, or to document sets by means of wild cards. In our model local authorities can also define authorizations at the DTD level; however such authorizations only apply to the documents of the local domain. . . The approach proposed is focused on enforcing and resolving fine grained authorizations with respect to the data model and semantics. Although presented in association with a specific approach to authorization specification and subject identification, as supported in the current prototype, its operation is independent from such approaches and could then be applied in combination with different admninistrative policies. For instance, it can be combined with the treatment of roles and of authentication/authorization certificates. We are currently exploring such extensions." Also in PDF. [cache]

• [August 25, 2000] "XML Access Control: A Fine-Grained Access Control System for XML Documents." Project model description, summary: "Web-based applications greatly increase information availability and ease of access, which is optimal for public information. The distribution and sharing by the Web of information that must be accessed in a selective way, such as the one involved in Electronic Commerce transactions, requires the definition and enforcement of security controls, ensuring that information will be accessible only to authorized entities. Different approaches have been proposed that address the problem of protecting information in a Web system. However, these approaches typically operate at the file system level, independently from the data that have to be protected from unauthorized accesses. The eXtensible Markup Language (XML), a markup language promoted by the World Wide Web Consortium (W3C), that is expected to become the standard language for the exchange of information in Internet, represents an important opportunity to solve the problem. We present an access control model to protect information distributed on the Web that, by exploiting XML's own capabilities, allows the definition and enforcement of access restrictions directly on the structure and content of the documents. The result is a flexible and powerful security system offering a simple integration with current solutions. . . The application to XML data of the latest advancement of public-key cryptography has remedied most of the security problems in communication; commercial products are becoming available providing fine-grained security features such as digital signatures and element-wise encryption to transactions involving XML data as a way to meet authenticity, secrecy and non-repudiation requirements in XML-based transactions. The objective of our work is to complete this picture, exploiting XML's own capabilities to define and implement an authorization model for regulating access to XML documents. The rationale for our approach is defining an XML markup for a set of security elements describing the protection requirements of XML documents. Our security markup can be used to provide both instance level and schema level authorizations at the granularity of XML elements. Taken together with a user's identification and its associated group memberships, as well as with the support for both permissions and denials of access, our security markup allows to easily express different protection requirements with support of exceptions. The enforcement of the requirements stated by the authorizations produces a view on the documents for each requester; the view includes only the information that the requester is entitled to see. A main feature of our model is that it smoothly accommodates the needs of both organization-wide policy managers and single document authors, automatically taking both into account to define who can exercise which access privileges on a particular XML document. Our notion of subject comprises identity and location; identity can include information about group or organization membership. The granularity of objects may be as fine as single elements or even attributes within XML documents. . . Our processor takes as input a valid XML document requested by the user, together with its XML Access Sheet (XAS) listing the associated access authorizations at the instance level. The processor operation also involves the document's DTD and the associated XAS specifying schema level authorizations. The processor output is a valid XML document including only the information the user is allowed to access. To provide a uniform representation of XASs and other XML-based information, the syntax of XASs is given by the XML DTD . . ." See provisionally: http://131.175.16.43:8090/XML-AC/. Example: Hospital example. Contact: smendog@tin.it. Principals: (1) ERNESTO DAMIANI [Università di Milano, Dipartimento di Scienze] dell'Informazione, (2) SABRINA DE CAPITANI DI VIMERCATI [Università di Brescia, Dipartimento di Elettronica per l'Automazione], (3) STEFANO PARABOSCHI [Politecnico di Milano, Dipartimento di Elettronica e Informazione], (4) PIERANGELA SAMARATI [Università di Milano, Dipartimento di Scienze dell'Informazione].

• "Adding Access Control to Distributed Invocations via XML." A Position Paper. By Ernesto Damiani.

• [August 10, 2000] "XML fine-grained access control: a manifesto." From Ernesto Damiani. Updated 2000-08-10. "Below is our argument why there needs to be both research and standardization of XML/RDF security technologies. If you are interested, please contact us and join us in proposing a IETF BoF and/or a W3C Workshop." See "XML Fine-Grained Access Control: a Manifesto," by Ernesto Damiani. [cache]

• [August 26, 2000] "Specification of Element-wise XML Encryption." August [14,] 2000. By Takeshi Imamura and Hiroshi Maruyama. ['We are now designing another syntax and semantics of XML Encryption. Because our proposal is strongly influenced by Cryptographic Message Syntax (CMS) and XML Signature, it is a little different from what Ed and Brian proposed. But our design philosophy is similar to theirs, and so we think both would be merged so well.' Posting from Takeshi Imamura (Tokyo Research Laboratory, IBM Japan, Ltd.)] "This document specifies processing rules for encrypting specified portions of an XML document, syntax for representing encrypted parts, and processing rules for decrypting them. The encryption can be applied to multiple elements in an XML document, each of which is contained in another element. There are three formats: embedded, embedding, and detached types. The first two manage encrypted contents and information about the encryption operation together. The last one manages them separately." [cache]

• [August 10, 2000] "Element-Wise XML Encryption." By Hiroshi Maruyama and Takeshi Imamura (IBM Research, Tokyo Research Laboratory). April 19, 2000. "When transmitting data over the Internet, in most cases the standard encryption protocols such as IPSec and SSL are good enough for achieving confidentiality during the transmission. Secure mails such as Pretty Good Privacy (PGP) and S/MIME can be used for encrypting data even after the message is received and stored in a file system. These methods are to encrypt an XML document as a whole. However, there are situations in which certain parts of an XML document need to be encrypted and the rest should be in clear text. A few motivating examples are shown below. . ." [The motivation of XML encryption originally came from the needs for transcoding, where an intermediary ('transcoding proxy') modifies the contents according to the client's profile, such as the screen size of the client device and the end-user's preference. However, it turned out through many discussions with customers, we found that it is common that some part of a document need access control and encryption is the natural way to achieve such access control. Based our experiences in XML parser, XML signature, and customer engagements, we wrote a short paper on the requirements and design considerations of XML encryption.]

• [August 10, 2000] "Overview of IBM XML Security Suite." By Satoshi Hada (IBM Tokyo Research Laboratory). 2000/3/27. See the IBM web site for details. ['The XML Security Suite provides security features such as digital signature, element-wise encryption, and access control to Internet business-to-business transactions. As of 07/25/2000, it supports Xerces-J1.1 and latest working draft. DOMHASH implementation has conformed to RFC 2803, and new GUI-based sample programs for ASN.1/XML Translator and Element-wise Encryption libraries.']

• "Specifying and Enforcing Access Control Policies for XML Document Sources." By E. Bertino, S. Castano, E. Ferrari, and M. Mesiti. In World Wide Web Journal, Volume 3, Number 3 [2000]. "The Web is becoming the main information dissemination means in private and public organizations. As a consequence, several applications at both internet and intranet level need mechanisms to support a selective access to data available over the Web. In this context, developing an access control model, and related mechanism, in terms of XML (eXtensible Markup Language) is an important step, because XML is increasingly used as the language for representing information exchanged over the Web. In this paper, we propose access control policies and an associated model for XML documents, addressing peculiar protection requirements posed by XML. A first requirement is that varying protection granularity levels should be supported to guarantee a differentiated protection of document contents. A second requirement arises from the fact that XML documents do not always conform to a predefined document type. To cope with these requirements, the proposed model supports varying protection granularity levels, ranging from a set of documents, to a single document or specific document portion(s). Moreover, it allows the Security Administrator to choose different policies for documents not covered or only partially covered by the existing access control policies for document types. An access control mechanism for the enforcement of the proposed model is finally described."

• [August 10, 2000] "XML Document Security and e-Business Applications." By Michiharu Kudo (Tokyo Research Laboratory, IBM Japan Ltd.) and S. Hada. Paper to be presented at CCS '00: [7th ACM Conference on Computer and Communication Security 2000, November 1-4, 2000, Athens, Greece. Note in this connection the comments by Michiharu Kudo on the W3C XML Encryption discussion list: "The idea of XML fine-grained access control is very interesting. Our team in Tokyo Research Lab has been interested and involved in several aspects of XML security such as digital signature, element-wise encryption, and access control on XML document as well. Someone may say that standardization for digital signature and encryption on XML is more essential compared to that of XML access control. Yes, however, it is often the case that the XML document such as e-contract contains multi-level security information and the access to that document must be controlled e.g., sub-portion of the original XML may have a digital signature that must be protected from the anonymous read access. Or when the access comes from the specific department, access is allowed but access must be logged. For these purposes, it is nice to have a fine-grained access control policy specification language for XML document, and also reasonable to provide such a language defined in XML. Thus we designed XACL (XML Access Control specification Language) and implemented a prototype system for e-commerce applications. However, there could be various language definitions, while they have many issues that could be shared in common. Thus I think that it is very good to propose this to some standardization unit as a first step." See: "XML access control language (XACL)." - "The XML Access Control Language (XACL) is centered around a subject-privilege-object oriented security model in the context of a particular XML document. This means, by writing rules in XACL a policy author is able to define who can exercise what access privileges on a particular XML document. The notion of subject comprises identity and role, with identity possibly including information about group or organization membership. The granularity of object is as fine as single elements within this document. The set of possible privileges currently consists of five types (read, write, create, delete, clone), but is not limited to these. In addition to subject, privilege and object, a condition can be added to the rule. By specifying enforcement conditions, temporal conditions and data-dependent conditions, more flexible rules can be written."

• [August 10, 2000] "Securing XML Documents." By Ernesto Damiani, Sabrina De Capitani di Vimercati, Stefano Paraboschi, and Pierangela Samarati. Proceedings of EDBT 2000, Konstanz, Germany, March 2000. Published as pages 121-135 (with 20 references) in Lecture Notes in Computer Science, Number 1777. "Web-based applications greatly increase information availability and ease of access, which is optimal for public information. The distribution and sharing by the Web of information that must be accessed in a selective way requires the definition and enforcement of security controls, ensuring that information will be accessible only to authorized entities. Approaches proposed to this end level, independently from the semantics of the data to be protected and for this reason result limited. The eXtensible Markup Language (XML), a markup language promoted by the World Wide Web Consortium (W3C), represents an important opportunity to solve this problem. We present an access control model to protect information distributed on the Web that, by exploiting XML's own capabilities, allows the definition and enforcement of access restrictions directly on the structure and content of XML documents. We also present a language for the specification of access restrictions that uses standard notations and concepts and briefly describe a system architecture for access control enforcement based on existing technology. [This work was supported in part by the INTERDATA and DATA-X - MURST projects and by the Fifth (EC) Framework Programme under the FASTER project.]" See also: "Design and Implementation of an Access Control Processor for XML Documents." [alt URL] [cache]

• [August 10, 2000] "XML Access Control Systems: A Component-Based Approach." By Ernesto Damiani, Sabrina De Capitani di Vimercati, Stefano Paraboschi, Pierangela Samarati. Paper to be presented at the Fourteenth Annual IFIP [International Federation for Information Processing] WG 11.3 Working Conference on Database Security, Amsterdam, The Netherlands, August 21-23, 2000. See IFIP WG 11.3

• "XML and how to secure it." By Kevin Townsend. In ZDNet IT Week (May 22, 2000). "The eXtensible Markup Language's enormous potential as an enabling technology for e-commerce will only be realised when its inherent security weaknesses are eliminated. The Internet is as insecure as ever, and XML will do nothing to improve it. In fact, the temptation to intercept and alter an XML document containing vital data en route from one banking application to another will lure many an Internet vandal. There are two primary requirements: encryption to keep confidential information private; and digital signatures to provide authenticity, integrity and non-repudiation. The encryption side is not too difficult. The only important point is that any encryption should be a well-known, tried and tested algorithm that is specifically resistant to known plain-text attacks. The point here is that published schemas will contain data about the tags used in specific XML documents, and the tags themselves can be quite long. These could be used to provide enough known plain text for an attack. The better-known encryption algorithms are fairly resistant to such attacks, and it should not be a problem if recognised standards are followed. . . it is not as simple as it may seem. Digitally signing an email message involves person A creating a hash of the message itself and then encrypting the hash value with their own private key before sending it to person B. B knows A's public key and can decrypt the hash. He knows that only A could have sent it because only A's public key will decrypt it. B then recreates a new hash value from the message and compares it with the value sent by A. If it is the same, it proves that only A could have sent the message and nobody has tampered with it. The message has been digitally signed and can be considered safe. But we cannot necessarily apply the same principles to an XML document. For example, the XML document concerned could be a form. In this case the issuing application may wish to sign parts of the document, but will need to allow the user to legitimately tamper with the document by filling it in. Clearly, if we attempted to sign the whole document, any hash value would be altered by the user's additions. We need therefore to be able to sign just parts of the document, and it this an altogether more complex task. Work on such a standard has reached the working draft stage and leading PKI vendors are now developing XML security products that are based on standards."

• See also: XML Digital Signature (IETF/W3C)

• See also: Digital Signatures for Internet Open Trading Protocol (IOTP)

• See also: XML Encoding of SPKI Certificates

• See also: Digital Receipt Infrastructure Initiative

• See also: Digest Values for DOM (DOMHASH)

• See also: Signed Document Markup Language (SDML)