SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
|
Contents
The XML Signature Working Group is a joint Working Group of the IETF and W3C. The chairs are Donald Eastlake 3rd and Joseph Reagle Jr. The goal of this working group "is to develop an XML compliant syntax used for representing the signature of Web resources and portions of protocol messages (anything referencable by a URI) and procedures for computing and verifying such signatures." See the mailing list archives for current/past discussion.
[November 11, 2002] W3C Publishes XML-Signature XPath Filter 2.0 as W3C Recommendation. The XML-Signature XPath Filter 2.0 specification produced by the IETF/W3C XML Signature Working Group has been released in its final publication stage as a W3C Recommendation. The Working Group "believes the specification is sufficient for the creation of independent interoperable implementations as demonstrated in the Interoperability Report. The XML Signature Recommendation (XML-Signature Syntax and Processing) defines standard means for specifying information content to be digitally signed, including the ability to select a portion of an XML document to be signed using an XPath transform. The XML-Signature XPath Filter 2.0 specification describes a new signature filter transform that, like the XPath transform, provides a method for computing a portion of a document to be signed. In the interest of simplifying the creation of efficient implementations, the architecture of this transform is not based on evaluating an XPath expression for every node of the XML parse tree, as defined by the XPath data model. Instead, a sequence of XPath expressions is used to select the roots of document subtrees -- location sets, in the language of XPointer -- which are combined using set intersection, subtraction and union, and then used to filter the input node-set."
[February 14, 2002] XML-Signature Published as a W3C Recommendation. The IETF/W3C XML Signature Working Group has produced a 'final' specification for XML Signature, and has issued XML-Signature Syntax and Processing as a W3C Recommendation. XML digital signatures "provide integrity, message authentication, and signer authentication services." The accompanying Interoperability Report identifies at least ten (10) implementations, with at least two interoperable implementations over every feature. The Recommendation "specifies XML syntax and processing rules for creating and representing digital signatures. XML Signatures can be applied to any digital content (data object), including XML. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature element. More specifically, this specification defines an XML signature element type and an XML signature application; conformance requirements for each are specified by way of schema definitions and prose respectively. This specification also includes other useful types that identify methods for referencing collections of resources, algorithms, and keying and management information." [Full context]
[August 24, 2001] IETF/W3C XML-Signature Syntax and Processing Specification Advanced to Proposed Recommendation. Public comment is invited through September 17, 2001 on the Proposed Recommendation release of XML-Signature Syntax and Processing. Issued by the IETF/W3C XML Signature Working Group as a joint IETF and W3C draft, the XML digital signature specification provides for integrity, message authentication, and signer authentication services. The PR document "specifies XML syntax and processing rules for creating and representing digital signatures. XML Signatures can be applied to any digital content (data object), including XML. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature element. More specifically, this specification defines an XML signature element type and an XML signature application; conformance requirements for each are specified by way of schema definitions and prose respectively. This specification also includes other useful types that identify methods for referencing collections of resources, algorithms, and keying and management information. The XML Signature is a method of associating a key with referenced data (octets); it does not normatively specify how keys are associated with persons or institutions, nor the meaning of the data being referenced and signed. Consequently, while this specification is an important component of secure XML applications, it itself is not sufficient to address all application security/trust concerns, particularly with respect to using signed XML (or other data formats) as a basis of human-to-human communication and agreement. Such an application must specify additional key, algorithm, processing and rendering requirements." [Full context]
[November 02, 2000] W3C Candidate Recommendation. As part of the XML Digital Signature Activity, the IETF/W3C XML Signature Working Group has published a 'W3C Candidate Recommendation' specification for XML-Signature Syntax and Processing. Reference: W3C Candidate Recommendation 31-October-2000, edited by Donald Eastlake, Joseph Reagle, and David Solo. The 'XML Signature' joint Working Group of the IETF and W3C has been chartered "to develop an XML compliant syntax used for representing the signature of Web resources and portions of protocol messages (anything referencable by a URI) and procedures for computing and verifying such signatures." The CR document "specifies XML digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. Digital signatures are created and verified using cryptography, the branch of applied mathematics concerned with transforming messages into seemingly unintelligible forms and then back again. Digital signatures are created by performing an operation on information such that others can confirm that a holder of a secret performed the operation and that the signed information has not subsequently changed. In a symmetric key system, both the sender and receiver need to be privy to the secret. In the public key cryptographic system, the holder of the private (secret) key signs information, but anyone with access to the public key can confirm that the signature is valid. The novel feature of public key cryptography is that knowledge of the public key used to confirm signatures does not reveal information about the private key itself." The W3C CR updates the previous last call working draft of 2000-10-12. The duration of Candidate Recommendation will last approximately three months (until January 31 2001); after which it should proceed to Proposed Recommendation. Implementations: The specification already has significant implementation experience as demonstrated by its Interoperability Report. "We expect to meet all requirements of that report within the three month Candidate Recommendation period. Specific areas where we would appreciate further implementation experience are: (1) XPath is RECOMMENDED. Signature applications need not conform to [XPath] specification in order to conform to this specification. However, the XPath data model, definitions (e.g., node-sets) and syntax is used within this document in order to describe functionality for those that want to process XML-as-XML (instead of octets) as part of signature generation. It appears all known implementations are satisfying the functional requirements by implementing XPath, consequently should we make it MANDATORY? (2) Minimal canonicalization (defined by this specification) is RECOMMENDED. There are no implementations of this algorithm: should we make it OPTIONAL or even remove it? [...]
[October 12, 2000] The IETF/W3C XML Signature Working Group has issued an updated Last Call Working Draft for the XML-Signature Syntax and Processing specification. Reference: W3C Working Draft 12-October-2000, edited by Donald Eastlake, Joseph Reagle, and David Solo. The document "specifies XML digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature element. More specifically, this specification defines an XML signature element type and an XML signature application; conformance requirements for each are specified by way of schema definitions and prose respectively. This specification also includes other useful types that identify methods for referencing collections of resources, algorithms, and keying and management information. The XML Signature is a method of associating a key with referenced data (octets); it does not normatively specify how keys are associated with persons or institutions, nor the meaning of the data being referenced and signed. Consequently, while this specification is an important component of secure XML applications, it itself is not sufficient to address all application security/trust concerns, particularly with respect to using signed XML (or other data formats) as a basis of human-to-human communication and agreement. Such an application must specify additional key, algorithm, processing and rendering requirements." Document status: This WD represents an "update to the second last call version, with an abbreviated last call termination date of October 20, 2000 (5 weeks in total). This update includes minor editorial changes, reference to the latest Canonical XML, as well as an adoption of the latest XML Schema specification. Barring substantive comment, we will request Candidate Recommendation status as soon as possible following the Canonical XML request. However, we do wish to ensure that readers are aware of following three substantive changes in the second last call: (1) We've changed the Reference Processing Model (section 4.3.3.1). to permit the presentation and acceptance of XML node-sets between Transforms (and resulting from some URI References) when appropriate; we accomplish this by heavily relying upon the XPath specification but still do NOT require a conformant XPath implementation. (2) We've revised the treatment of pre-pended algorithm object identifier within the encoded RSA SignatureValue by the PKCS1 algorithm (section 6.4.2). (3) We've revised the X509Data element (section 4.4.4) to clarify the treatment of certificate 'bags' and CRLs within that structure."
[September 21, 2000] A last-call working draft for XML-Signature Syntax and Processing has been issued by the joint W3C/IETF XML Signature Working Group. Reference: W3C Working Draft 18-September-2000, edited by Donald Eastlake, Joseph Reagle, and David Solo. Also published as 'draft-ietf-xmldsig-core-09.txt'. This second last call WD ends on November 5, 2000; "barring substantive comment, the WG will request Candidate recommendation status as soon as possible, following the Canonical XML request." The WD document "specifies XML digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. . . XML Signatures can be applied to any digital content (data object), including XML. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature element. More specifically, this specification defines an XML signature element type and an XML signature application; conformance requirements for each are specified by way of schema definitions and prose respectively. This specification also includes other useful types that identify methods for referencing collections of resources, algorithms, and keying and management information. The XML Signature is a method of associating a key with referenced data (octets); it does not normatively specify how keys are associated with persons or institutions, nor the meaning of the data being referenced and signed. Consequently, while this specification is an important component of secure XML applications, it itself is not sufficient to address all application security/trust concerns, particularly with respect to using signed XML (or other data formats) as a basis of human-to-human communication and agreement. Such an application must specify additional key, algorithm, processing and rendering requirements." Formal models are provided by the XML schema and XML DTD; see also RDF Data Model. [cache]
[June 01, 2000] XML-Signature Syntax and Processing. W3C Working Draft 01-June-2000. Also: IETF Internet Draft draft-ietf-xmldsig-core-07.txt. Edited by Donald Eastlake (Motorola), Joseph Reagle (Massachusetts Institute of Technology), and David Solo (Citigroup). Abstract: "This document specifies XML digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere." Detail: "This document specifies XML syntax and processing rules for creating and representing digital signatures. XML Signatures can be applied to any digital content (data object), including XML. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature element. This specification also defines other useful types including methods of referencing collections of resources, algorithms, and keying information and management." Status: "This specification of the IETF/W3C XML Signature Working Group follows the XML Signature Last Call and attempts to address all last call comments sent to the list and those issues discussed at the April meeting. This is the version being forward to the IESG and W3C Director for consideration as a Proposed Draft and Candidate Recommendation."
[May 11, 2000] An updated working draft document on XML-Signature Syntax and Processing has been issued jointly by the W3C and IETF. References: W3C Working Draft 10-May-2000; IETF Internet Draft draft-ietf-xmldsig-core-06.txt. Edited by Donald Eastlake, Joseph Reagle, and David Solo. This WD updates the 'WD-xmldsig-core-20000228' version: "this specification of the IETF/W3C XML Signature Working Group follows the XML Signature Last Call and attempts to address all last call comments sent to the list and those issues discussed at the April meeting. This version should be the last before the document is proposed as a Proposed Draft and Candidate Recommendation. Consequently, it still has a few editorial marks [underlined and/or in red] and things that must be done before it can be advanced..." Abstract: "This document specifies XML digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere... [the document] specifies XML syntax and processing rules for creating and representing digital signatures. XML Signatures can be applied to any digital content (data object), including XML. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature document. This specification also defines other useful types including methods of referencing collections of resources, algorithms, and keying information and management."
[March 01, 2000] Last Call W3C Working Draft XML-Signature Syntax and Processing. The IETF/W3C XML Signature Working Group has published a last call working draft for XML-Signature Syntax and Processing. Reference: W3C Working Draft 28-February-2000, edited by Donald Eastlake, Joseph Reagle, and David Solo. The document is published simultaneously as an IETF Internet Draft. "The W3C last call ends March 27, 2000; the IETF last call should substantially overlap but may not exactly coincide with this period. While the Working Group feels the design meets our requirements we especially welcome comments on the following topics: security concerns, URI/IDREF usage, XPath, DTD/schema specification, and implementation experience." Description: "This document specifies XML syntax and processing rules for creating and representing digital signatures. XML Signatures can be applied to any digital content (data object), including XML. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature document. This specification also defines other useful types including methods of referencing collections of resources, algorithms, and keying information and management. XML Signatures are be applied to arbitrary digital content (data objects) via an indirection. Data objects are digested, the resulting value is placed in an element (with other information) and that element is then digested and cryptographically signed. The specification uses both XML Schemas and DTDs."
[February 09, 2000] The W3C and IETF have released a revised working draft for the jointly-authored document XML-Signature Syntax and Processing. References: W3C Working Draft 08-February-2000; IETF Internet Draft draft-ietf-xmldsig-core-05.txt; edited by Donald Eastlake, Joseph Reagle, and David Solo. Abstract: "This document specifies XML digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere." It "specifies XML syntax and processing rules for creating and representing digital signatures. XML Signatures can be applied to any digital content (data object), including XML. An XML Signature may be applied to the content of one or more resources: enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature document. The specification also defines other useful types including methods of referencing collections of resources, and key management and algorithm definitions." The document represents "a public Working Draft of the IETF/W3C XML Signature Working Group. This version follows from the January face-to-face meeting. [The editors] hope to issue an institutional (IETF/W3C) Last Call within four weeks. This version includes and XML Schema definition and a DTD; both of which are fairly mature but may contain bugs. Please send comments to the editors and cc: the list.
[October 15, 1999] The W3C and IETF have released a revised working draft of an XML-Signature Requirements specification. Edited by Joseph Reagle Jr., this document is published simultaneously as a W3C WD (W3C Working Draft 14-October-1999) and as an IETF document (draft-ietf-xmldsig-requirements-02.txt). As per the charter, the goal of the working group responsible for the articulating the XML-Signature Requirements is "to develop a XML syntax used for representing signatures on digital content and procedures for computing and verifying such signatures. Signatures will provide data integrity, authentication, and/or non-repudiatability." The working draft document "lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. This Working Draft of XML Signature Requirements is a very stable result of this Working Draft having been advanced through W3C Last Call. Relatively small changes have been made to clarify the stated requirements during that period. This document will now be advanced as an IETF Informational RFC." Note, in this connection, that "The U.S. House Judiciary Committee has approved a bill designed to encourage electronic commerce by recognizing digital signatures as having the same legally binding status as a handwritten signature." [InfoWorld news article].
[October 20, 1999] A new W3C working draft on the XML digital signatures has been published as XML-Signature Core Syntax, and released simultaneously as an IETF draft, 'draft-ietf-xmldsig-core-00.txt'. W3C reference: W3C Working Draft 20-October-1999, edited by Joseph Reagle and David Solo. The XML Signature Working Group is a joint Working Group of the IETF and W3C. The goal of this working group "is to develop an XML compliant syntax used for representing the signature of Web resources and portions of protocol messages (anything referencable by a URI) and procedures for computing and verifying such signatures." This WD document represents the first public draft of the core specification [for the XML Digital Signature] which provides "the core signature syntax and processing rules of a XML signature application. The WD specification "provides a mechanism for applying digital signatures to XML documents and other Internet resources. The structure allows for both embedded and detached signatures. An embedded signature can include the signature within the signed object or embed the signed object within the signature. A detached signature allows the signature to be independent of the object. The processing structure allows for switching between embedded and detached signatures without invalidating the signature. In addition to the basic signature document type, this document also defines other useful types including a methods of referencing multiple resources and key management and algorithm definitions. This draft covers most of the topics the final specification will cover; however parts of the text and syntax within this specification are subject to change (and may be incorrect or inconsistent.)" Other relevant documents are referenced from the W3C's main XML Signature Web page.
[November 23, 1999] A revised working draft document XML-Signature Core Syntax and Processing has been published simultaneously as a W3C Working Draft and an IETF Internet Draft ('draft-ietf-xmldsig-core-02.txt'). References: W3C Working Draft 19-November-1999, edited by Donald Eastlake, Joseph Reagle, and David Solo. The WD constitutes an editorial revision of the W3C Working Draft 20-October-1999 under the same title. This working draft document "specifies the syntax and processing rules for the encoding of digital signatures using XML. Such signatures can provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or locatable elsewhere." [...] This document describes the proposed syntax and processing rules for the XML Digital Signature specification. This specification provides a mechanism for applying digital signatures to XML documents and other Internet resources and encoding those signatures as XML. The structure allows for both embedded and detached signatures. An embedded signature can include the signature within the signed object or embed the signed object within the signature. A detached signature allows the signature to be independent of the object. The processing structure allows for switching between embedded and detached signatures without necessarily invalidating the signature. This document also defines other useful types including methods of referencing collections of resources, and key management and algorithm definitions. XML digital signatures are very flexible and may be used to apply signatures to any type of resource. The resource(s) being signed may be included within the signature, outside the signature in the same document, or completely outside of the document. XML digital signatures are represented by the Signature element which has the following structure: <Signature>(SignedInfo) (SignatureValue) (KeyInfo)? (Object)* </Signature>. This is a public WG Draft that follows the November IETF meeting. Consequently it includes a editoral changes and recrafting though no major design changes. This version includes the experimental use of XML Schema and XML entity references. The XML schema declarations within the specification may contain errors, though the complete WG schema definition does validate to the Schema DTD. We expect the final draft will include a DTD and schema."
[August 20, 1999] Last Call Working Draft for XML-Signature Requirements.
The W3C has issued a last-call working draft document XML-Signature Requirements (W3C/IETF Working Draft 1999-August-20), available also from the IETF. The requirements document "lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination." The document has been created by the working group in an effort to "develop a XML syntax used for representing signatures on digital content and procedures for computing and verifying such signatures. Signatures will provide data integrity, authentication, and/or non-repudiatability. This last call XML Signature Requirements working draft is not expected to be advanced to Recommendation. Instead, this Last Call designation is: (1) a representation of WG consensus, (2) an invitation for comments that will affect the future course of the technical specification, and (3) an opportunity to identify and obtain commitments regarding WG dependencies." Comments on the draft may be sent to the editor, Joseph Reagle Jr.
[June 25, 1999] The first Public Working Draft of the IETF/W3C XML-Digital Signature Working Group Requirements document has now been published. The document is XML-Signature Requirements (W3C Working Draft 1999-June-23); the editor is Joseph Reagle Jr. (W3C). The WD content is based on the working group's Charter, the XML-Signature Workshop, Richard D. Brown's IETF draft [Digital Signatures for XML], and the DSIG mailing list discussion. The DSIG working group's mission is "to develop an XML compliant syntax used for representing signatures on Web resources and portions of protocol messages (anything that can be referenced by a URI) and procedures for computing and verifying such signatures. Signatures will provide data integrity, authentication, and/or non-repudiatability." The WD abstract: "This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination." The draft has been "published prior to the June 25 IETF deadline for consideration at the IETF in Oslo as an IETF-draft and W3C Working Draft. The first draft of a Working Group consensus version should be produced by July [1999]."
XML-DSig '99 is a W3C Signed XML Workshop (April 15-16, 1999). Several other efforts referenced in the following sections also relate to XML and digital signatures.
[March 30, 1999] Several position papers submitted in connection with the W3C Signed XML Workshop (XML-DSig '99) are now available online. The W3C event will be held April 15 - 16, 1999 at the DoubleTree Guest Suites Hotel, Boston, Massachusetts. The goal of the XML-DSig workshop, according to the published Call for Participation , "is to explore current work on XML, metadata, and machine readable semantics in the context of digital signatures. A result of this workshop may be a W3C activity that produces a specification for assuring the authenticity and integrity of Web data."
[July 12, 2005] Final Release of the Java XML Digital Signature API Specification (JSR 105). Developers from Sun, IBM, and other companies have announced the final release of Java XML Digital Signature API Specification (JSR 105) Version 1.0, produced under the Java Community Process (JCP). The purpose of this Java Specification Request is "to define a standard Java API for generating and validating XML signatures. The APIs for XML digital signatures services of JSR 105 implement the W3C XML-Signature Syntax and Processing Recommendation, and provide for support of the W3C XML-Signature XPath Filter 2.0 and Exclusive XML Canonicalization Version 1.0 Recommendations. JSR 105 was developed by members of the JSR 105 Expert Group under the direction of Specification Leads Anthony Nadalin (IBM) and Sean Mullan (Sun Microsystems), who continue jointly in the role of JSR 105 Maintenance Lead. The Java Community Process under which which JSR 105 was developed is a standards framework which "produces high-quality specifications in 'Internet time' using an inclusive, consensus building approach that produces a specification, a reference implementation (to prove the specification can be implemented), and a technology compatibility kit (a suite of tests, tools, and documentation that is used to test implementations for compliance with the specification). JCP participants include the international Java community, working to develop and evolve Java technology specifications." JSR 105 has been approved in a Final Approval Ballot with votes from by Apache Software Foundation, Apple Computer, Inc., BEA Systems, Fujitsu Limited, Hewlett-Packard, IBM Corp., Intel Corp., IONA Technologies PLC, JBoss, Inc., Nortel Networks, SAP AG, and Sun Microsystems, Inc. The Java XML Digital Signature API Specification supports software development projects that need to use the JSR 105 API to generate and validate XML signatures. It is also designed for use by Java programmers "who want to create a concrete implementation of the JSR 105 API and register it as a cryptographic service of a JCA provider. A cryptographic service provider is a package or set of packages that supply a concrete implementation of a subset of the Java 2 SDK Security API cryptography features." [December 7, 2004] "Introducing XML Canonical Form. Making XML Suitable for Regression Testing, Digital Signatures, and More." By Uche Ogbuji (Principal Consultant, Fourthought, Inc). From IBM developerWorks (November 07, 2004). "XML's heritage lies in the document world, and this is reflected in its syntax rules. Its syntax is looser than that of data formats concerned with database records. An XML parser converts an encoded form of an XML document (the encoding being specified in the XML declaration) to an abstract model representing the information in the XML document. The W3C formalized this abstract model as the XML Infoset, but a lot of XML processing has to focus on the encoded source form, which allows a lot of lexical variance: Attributes can come in any order; whitespace rules are flexible in places such as between an element name and its attributes; several means can be used for representing characters, and for escaping special characters, and so on. Namespaces introduce even more lexical flexibility (such as a choice of prefixes). The result is that you can have numerous documents that are exactly equivalent in XML 1.0 rules, while being very different under byte-by-byte comparison of the encoded source. The W3C addresses this problem with the XML Canonicalization spec (c14n), which defines a standard form for an XML document that is guaranteed to provide proper bit-wise comparisons and thus consistent digital signatures... Canonical XML is an important tool to keep at hand. You may not be immediately involved in XML-related security or software testing, but you'll be surprised at how often the need for c14n pops up once you are familiar with it. It's one of those things that helps cut a lot of corners that you may have never thought of avoiding in the first place..." [June 14, 2004] "Additional XML Security URIs." By Donald E. Eastlake 3rd (Motorola Laboratories). IETF Internet Draft. Reference: 'draft-eastlake-xmldsig-uri-07.txt'. 20 pages. See the 2004-06-11 announcement for the Last Call review of this Internet Draft as a Proposed Standard: "Last Call: 'Additional XML Security URIs' to Proposed Standard... The IESG plans to make a decision in the next few weeks, and solicits final comments on this action; please send any comments to the IESG at ietf.org or ietf at ietf.org mailing lists by 2004-07-09..." Summary: XML Digital Signatures, Canonicalization, and Encryption have been standardized by the W3C and by the joint IETF/W3C XMLDSIG working group. All of these are now W3C Recommendations and IETF Informational or Standards Track documents. All of these standards and recommendations use URIs (RFC 2396) to identify algorithms and keying information types. This document is 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 required remove of any algorithms for which there was not demonstrated interoperability from the main standards document. This required removal of the Minimal Canonicalization algorithm, in which there appears to be continued interest, to be dropped from the standards track specification..." IETF source URL: http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-07.txt. [June 14, 2004] "Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures." By Simon Blake-Wilson (BCI), Gregor Karlinger (Federal Staff Office for IT Strategies/Federal Chancellery), Tetsutaro Kobayashi (NTT Laboratories), and Yongge Wang (University of North Carolina at Charlotte). IETF Internet Draft. Reference: 'draft-blake-wilson-xmldsig-ecdsa-09.txt'. March 2004, expires Sept 2004. Appendix A: Aggregate XML Schema; Appendix B: Aggregate DTD. This document specifies how to use ECDSA (Elliptic Curve Digital Signature Algorithm) with XML Signatures. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference... The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic curve analogue of the DSA (DSS) signature method (FIPS186-2). It is defined in the ANSI X9.62 standard... Like DSA, ECDSA incorporates the use of a hash function. Currently,the only hash function defined for use with ECDSA is the SHA-1 message digest algorithm (FIPS-180-1). ECDSA signatures are smaller than RSA signatures of similar cryptographic strength. ECDSA public keys (and certificates) are smaller than similar strength DSA keys, resulting in improved communications efficiency. Furthermore, on many platforms ECDSA operations can be computed faster than similar strength RSA or DSA operations. These advantages of signature size, bandwidth, and computational efficiency may make ECDSA an attractive choice for XMLDSIG implementations..." IETF source URL: http://www.ietf.org/internet-drafts/draft-blake-wilson-xmldsig-ecdsa-09.txt. [July 30, 2003] "Understanding XML Digital Signature." By Rich Salz. In Microsoft MSDN Library (July 2003). ['This article looks at the XML Digital Signature specification, explaining its processing model and some of its capabilities. It provides a low-level understanding of how the WS-Security specification implements its message security feature. The author surveys the XML DSIG specification using the schema definition to describe the features that are available and the processing that is required to generate and verify an XML DSIG document. He starts with the basic signature element (ds:SignedInfo), looks at how it incorporates references to application content to protect that content, and looks at part of the ds:KeyInfo element to see how an application can verify a signature, and perhaps validate the signer's identity. These three aspects provide the most basic and low-level components of protecting the integrity of XML content.'] "Digital signatures are important because they provide end-to-end message integrity guarantees, and can also provide authentication information about the originator of a message. In order to be most effective, the signature must be part of the application data, so that it is generated at the time the message is created, and it can be verified at the time the message is ultimately consumed and processed. SSL/TLS also provides message integrity (as well as message privacy), but it only does this while the message is in transit. Once the message has been accepted by the server (or, more generally, the peer receiver), the SSL protection must be 'stripped off' so that the message can be processed. As a more subtle point, SSL only works between the communication endpoints. If I'm developing a new Web service and using a conventional HTTP server (such as IIS or Apache) as a gateway, or if I'm communicating with a large enterprise that has SSL accelerators, the message integrity is only good up until the SSL connection is terminated. As an analogy, consider a conventional letter. If I'm sending a check to my phone company, I sign the check -- the message -- and put it in an envelope to get privacy and delivery. Upon receipt of the mail, the phone company removes the envelope, throws it away, and then processes the check. I could make my message be part of the envelope, such as by gluing the payment to a postcard and mailing that, but that would be foolish. An XML signature would define a series of XML elements that could be embedded in, or otherwise affiliated with, any XML document. It would allow the receiver to verify that the message has not been modified from what the sender intended. The XML-Signature Syntax and Processing specification (abbreviated in this article as XML DSIG) was a joint effort of the W3C and the IETF. It's been an official W3C Recommendation since February 2002. Many implementations are available..." [June 03, 2003] Public Review Draft for the Java XML Digital Signature API Specification. A Public Review Draft has been issued for JSR 105 Java XML Digital Signature API Specification on May 29, 2003 under the Community Process. The Public Review period closes on June 29, 2003. The purpose of this Java Specification Request is "to define a standard Java API for parsing, generating, and validating XML signatures." The API consists of five packages that support a DOM-independent implementation of XML-Signature Syntax and Processing and related W3C Recommendations. The W3C XML Digital Signature specification defines "XML syntax and processing rules for creating and representing digital signatures. The XML Signature is a method of associating a key with referenced data; it does not normatively specify how keys are associated with persons or institutions, nor the meaning of the data being referenced and signed. While the W3C specification is an important component of secure XML applications, it [of itself] is not sufficient to address all application security/trust concerns, particularly with respect to using signed XML (or other data formats) as a basis of human-to-human communication and agreement. Such an application must specify additional key, algorithm, processing and rendering requirements and developers must give consideration to their application threat models." [March 28, 2003] XACML XML DSig Profile Supports Authentication of XACML Schema Instances. The OASIS Extensible Access Control Markup Language (XACML) TC has published a draft XACML XML DSig Profile specifying the use of the W3C XML-Signature Syntax and Processing Standard in providing authentication and integrity protection for XACML schema instances -- policies, authorization decision requests, and authorization decision responses. The draft profile attempts to be consistent with the SAML profile wherever possible. A normative section of the draft profile specifies guidelines for the construction of XACML schema instances that are to be signed. These guidelines apply to XMLDSig digital signatures as well as to other digital signature formats. Another section describes the formats for an XMLDSig <Reference> element that references an XACML schema instance. The OASIS XACML TC has been chartered to "define a core schema and corresponding namespace for the expression of authorization policies in XML against objects that are themselves identified in XML." [February 21, 2003] "XML Advanced Electronic Signatures (XAdES)." Edited by Juan Carlos Cruellas (UPC), Gregor Karlinger (IAIK) Krishna Sankar Cisco). W3C Note 20-February-2003. Version URL: http://www.w3.org/TR/2003/NOTE-XAdES-20030220/. Latest version URL: http://www.w3.org/TR/XAdES/. "XAdES extends the IETF/W3CXML-Signature Syntax and Processing specification into the domain of non-repudiation by defining XML formats for advanced electronic signatures that remain valid over long periods and are compliant with the European "Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures" [EU-DIR-ESIG] (also denoted as "the Directive" or the "European Directive" in the rest of the present document) and incorporate additional useful information in common uses cases. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (repudiates) the validity of the signature. An advanced electronic signature aligned with the present document can, in consequence, be used for arbitration in case of a dispute between the signer and verifier, which may occur at some later time, even years later. This note adds six additional forms to XMLDSIG: (1) XML Advanced Electronic Signature (XAdES): Provides basic authentication and integrity protection and satisfies the legal requirements for advanced electronic signatures as defined in the European Directive but does not provide non-repudiation of its existence; (2) XML Advanced Electronic Signature with Time-Stamp (XAdES-T): Includes time-stamp to provide protection against repudiation; (3) XML Advanced Electronic Signature with complete validation data (XAdES-C): Includes references to the set of data supporting the validation of the electronic signature (i.e., the references to the certification path and its associated revocation status information). This form is useful for those situations where such information is archived by an external source, like a trusted service provider. (4) XML Advanced Electronic Signature with eXtended validation data (XAdES-X): Includes time-stamp on the references to the validation data or on the ds:Signature element and the aforementioned validation data. This time-stamp counters the risk that any keys used in the certificate chain or in the revocation status information may be compromised. (5) XML Advanced Electronic Signature with eXtended validation data incorporated for the long term (XAdES-X-L): Includes the validation data for those situations where the validation data are not stored elsewhere for the long term. (6) XML Advanced Electronic Signature with archiving validation data (XAdES-A): It includes additional time-stamps for archiving signatures in a way that they are protected if the cryptographic data become weak..." [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..." [October 16, 2002] OASIS Members Propose Digital Signature Services Technical Committee. Representatives from five OASIS corporate members (Entrust, Datum, NIST, webMethods, TIBCO) have proposed the creation of a new Digital Signature Services Technical Committee to develop techniques to support the processing of digital signatures. According to the proposal, the OASIS DSS technical committee will "define an interface for requesting that a web service produce and/or verify a digital signature on a given piece of data and techniques for proving that a signature was created within its private key validity period. The TC will develop a protocol for a digital signature creation web service. Providing digital signatures via such a web service facilitates policy-based control of the provision of the signatures. The TC will also develop a protocol for a centralized digital signature verification web service that can verify signatures in relation to a given policy set. Finally, the TC will develop an XML-based protocol to produce cryptographic time stamps that can be used for determing whether or not a signature was created within the associated public key's validity period or before revocation. This is required as part of the signature verification algorithm." Robert Zuccherato of Entrust Inc. will serve as the DSS TC Chair. [Full context] [October 08, 2002] Entrust Announces New Secure Transaction Platform and Proposed Security Standards. Announcements from Entrust on 2002-10-07 outline a comprehensive vision and product delivery roadmap for web services security, to be offered through the Entrust Secure Transaction Platform. "Developed using open industry standards, these services initially include: (1) the Entrust Identification Service, designed to enable validation of federated and non-federated identities across a spectrum of standards-based identification methods, including digital certificates and UserID/passwords. This capability enhances Web services application security by managing multiple identification methods; it also allows organizations to centrally specify which identities are accepted for Web services transactions; (2) The Entrust Entitlements Service, which implements the Security Assertion Markup Language (SAML) standard protocol that enables applications to validate that an identity has a right to interact with specific Web services; (3) The Entrust Verification Service, which supports accountability and integrity for more trusted transactions through centralized digital signature and time stamping capabilities, implemented using standards-compliant XML Digital Signatures." Entrust announced that it has submitted a set of related security standards proposals for Web services to OASIS. "These standards proposals specify open, XML protocols for digital signature and timestamping services operating in a Web services context." [Full context] [July 29, 2002] Exclusive XML Canonicalization from IETF/W3C XML Signature Working Group Becomes W3C Recommendation. The IETF/W3C Exclusive XML Canonicalization specification has been advanced to a W3C Recommendation, signifying that it is "stable, contributes to Web interoperability, and has been reviewed by the W3C Membership, who are in favor of supporting its adoption by academic, industry, and research communities. The specification augments the previously published Canonical XML Recommendation to better enable a portion of an XML document (fragment) to be as portable as possible while preserving the digital signature. It works in combination with the XML-Signature Syntax and Processing Recommendation produced jointly by W3C and the IETF in February 2002, representing cross-industry agreement on an XML-based language for digital signatures. Exclusive XML Canonicalization provides a method of serializing an XML fragment into a portable and canonical form. This functionality, when combined with XML Signature, is critical for electronic commerce because it ensures the integrity of documents and protocol messages that travel between multiple XML processors." [Full context] [October 17, 2002] "Yes, You Can Secure Your Web Services Documents, Part 2. XML Signature Ensures Your XML Documents' Integrity." By Ray Djajadinata. In Java World (October 11, 2002). ['In the first installment of this two-part series, Ray Djajadinata discussed the foundation of confidentiality for WS-Security: XML Encryption. In this second installment, he introduces XML Digital Signature, a standard that handles a document's integrity. He explains the standard, what you should know about it, and shows how to write XML Signature code using an implementation currently available: IBM XML Security Suite.'] "In this article, we look closer at the integrity part of the equation: XML Signature, which turns out to be a bit more complicated than its confidentiality counterpart... The main difference between XML Signature and other digital signature standards such as PKCS#7 (Public-Key Cryptography Standard #7) is that it is XML-aware. That is, with XML Signature, not only can you sign arbitrary digital content as a whole, but you can also sign just specific parts of XML documents. This proves useful when parts of XML documents can be moved, copied, encrypted, signed, and verified in any order, which is quite likely to happen as we move more towards shuffling around XML messages instead of binary payload over the wire. However, as you will see later, XML awareness doesn't come free. Compared to XML Signature, XML Encryption is relatively straightforward. You select some nodes to encrypt, and that's basically it. You decrypt the ciphertext with the correct key, and you retrieve the plaintext -- as simple as that. Not so with XML Signature! XML Signature is more complicated because signatures need to be verified correctly... As of now, XML Signature is already more developed than its cousin XML Encryption. The official Java API for XML Signature should be coming out soon, so be on the look out; JavaOne 2002 featured a high-level overview of the API, and from the look of it, I gather it will be quite easy to learn and use. For example, the API features a class called XMLSignatureMarshaller, which converts XML Signatures to/from XML. If this is not the template feature we've come to know, I don't know what is. The API also includes Transforms, URIDereferencer, and so on, whose names, after reading this article, should clue you in to their functionalities. Last but not least, XML Signature operates under the assumption that key distribution and registration has already been handled. This article's examples are trivial -- we created the key and then used it to verify the signatures. In the real world, things are definitely more complicated. Keys must be registered and distributed properly, and trust relationships must be established. XKMS (XML Key Management Specification), related to Java Specification Request 104, tries to address these issues. In any case, many new and interesting things are emerging from XML security, and with its strong tie to Web services security, you can bet an official Java API will follow soon..." See also Part 1, "XML Encryption Keeps Your XML Documents Safe and Secure." [October 07, 2002] "Designing Web Services with XML Signatures." By Mark Young. In Web Services Journal Volume 2, Issue 10 (October 2002), pages 10-12. "XML signatures apply digital signatures to XML documents. Digital signatures let parties that exchange data ensure the identity of the sender and the integrity of the data. This last item is a benefit that physical signatures can't provide. Digital signatures don't have the legal status that physical signatures have, at least not yet. Over the last few years this has been changing, as the federal government and many state governments have moved to accept digital signatures as legally binding for some applications, where they identify the sender and provide nonrepudiation (the signer can't deny ever having signed). Since Web services that use SOAP exchange XML documents, they can include XML signatures. Web service developers who produce Web services with XML signatures will be able to realize the benefits of those signatures, and may be able to use them in place of physical signatures where the legal community has agreed they are binding. Putting XML signatures into a Web service, however, is not trivial. In this article I'll provide some background on XML signatures, and then explore how you can incorporate them into your Web services. I'll develop an example Web service, written in Java for Apache Axis, that uses an XML signature, to illustrate how it can be done..." [July 29, 2002] XML-Signature XPath Filter 2.0. By John Boyer (PureEdge Solutions Inc.), Merlin Hughes (Baltimore Technologies Ltd.), and Joseph Reagle (W3C). W3C Candidate Recommendation 18-July-2002. Version URL: http://www.w3.org/TR/2002/CR-xmldsig-filter2-20020718/. Latest version URL: http://www.w3.org/TR/xmldsig-filter2/. The W3C XML-Signature XPath Filter 2.0 was advanced to Candidate Recommendation status on 18-July-2002. Produced by the IETF/W3C XML Signature Working Group, this Candidate Recommendation "defines an alternative to the XPath transform of the XML Signature Recommendation [XML-DSig]. The goal is to: (1) more easily specify XPath transforms and (2) more efficiently process those transforms." From the abstract: "XML Signature recommends a standard means for specifying information content to be digitally signed and for representing the resulting digital signatures in XML. Some applications require the ability to specify a subset of a given XML document as the information content to be signed. The XML Signature specification meets this requirement with the XPath transform. However, this transform can be difficult to implement efficiently with existing technologies. This specification defines a new XML Signature transform to facilitate the development of efficient document subsetting implementations that interoperate under similar performance profiles.... The specification incorporates the resolution of all last call issues. The WG considers the specification to be very stable and invites implementation feedback during this period. The specification presently has three interoperable implementations as shown in the Interoperability Report; [the WG will] try to obtain one more, but otherwise will advance after the Candidate Recommendation period after three weeks (closing 08-August-2002)." [April 26, 2002] IETF/W3C XML Signature Working Group Issues XML-Signature XPath Filter 2.0. The IETF/W3C XML Signature Working Group has released an initial public working draft for XML-Signature XPath Filter 2.0. The specification "defines an alternative to behaviour of the XPath transform of the W3C XML Signature Recommendation. The goal is to: (1) more easily specify XPath transforms, and (2) more efficiently process those transforms... [the document] describes a new signature filter transform that, like the XPath transform, provides a method for computing a portion of a document to be signed. In the interest of simplifying the creation of efficient implementations, the architecture of this transform is not based on evaluating an XPath expression for every node of the XML parse tree (as defined by the XPath data model). Instead, the XPath expression in this transform is used to identify a set of nodes that, along with all nodes having an ancestor in the identified set, is used to transform the input node set by set intersection, subtraction, or union." Since the specification has already received a large amount of discussion and implementation within the Working Group, the WG members hope to move the specification "to and through Last Call and then Candidate Recommendation very quickly." [Full context] [March 27, 2002] "Donald Eastlake on XML Digital Signatures. An Interview With One of the Specification's Pioneers." By Larry Loeb [and Donald Eastlake]. From IBM developerWorks, XML Zone. March 2002. ['In this exclusive developerWorks interview, XML Digital Signatures pioneer Donald Eastlake responds to Larry Loeb's recent article on the topic by clarifying a number of issues about how this technology is used. Note from Larry Loeb: In a recent article on XML Digital Signatures, I questioned their utility and usefulness. Since the proposal has just been recommended for passage into general usage, I decided it was time to check back on the topic again. This time, I talked with Donald Eastlake, the editor of the XML Digital Signature (XMLDSIG) RFC, and someone who should know something about the subject, since he has been intimately involved with XML specifications since the effort began in the 1990s. He has also served on IETF efforts too numerous to list. His responses appear unedited, except for minor grammatical changes.'] Eastlake on real world use of XML digital signatures: "I believe there will be a full spectrum of usage but two areas of particular prominence seem likely: documents and messages. While these sometimes blend into each other, documents tend to be longer lived and the signatures on them tend to indicate human approval of all or part of the document, although they may also have time stamp signatures affixed automatically. Messages tend to be transient and would more commonly have authentication automatically affixed and removed. Of course, a message could include one or more documents, in the sense I'm using the word here, in its content... Documents are most likely to use public key techniques while messages, depending on the application, could use public key or symmetric secret key techniques. Documents are more likely to be something "important" like a mortgage or court filing. But if XML digital signatures are widely used for messages, messages could be several orders of magnitude more numerous." Article also in PDF format. [August 24, 2001] XML-Signature Syntax and Processing. W3C Proposed Recommendation 20-August-2001. Issued by the IETF/W3C XML Signature Working Group. "Specifies XML digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere." Cache DTD and W3C XML Schema. See the news item. [March 21, 2001] W3C/IETF Canonical XML Specification Published as a W3C Recommendation. W3C has announced the release of Canonical XML Version 1.0 as the first W3C Recommendation produced jointly by the W3C/IETF XML Signature Working Group. The Canonical XML specification "adds another critical piece to the Extensible Markup Language (XML) family of technologies under development at W3C, which began with the XML 1.0 Recommendation." The new specification "defines a method for serializing XML documents such that it eliminates incidental variances in their syntax as permitted by XML 1.0. This functionality is necessary to XML Signatures which requires documents to be consistently serialized for digital signature processing, so that these incidental variances do not invalidate the signature... Digital signatures provide integrity, signature assurance and non-repudiatability over Web data. Such features are especially important for documents that represent commitments such as contracts, price lists, and manifests. XML Signatures have the potential to provide reliable XML-based signature technology. However, various processors may introduce incidental changes into a document over the course of its processing. Canonical XML 1.0 provides a method of serializing an XML document into its canonical form. If two documents have the same canonical form, then the two documents are logically equivalent within the context of this specification. This relationship combined with XML Signature is critical for electronic commerce because it ensures the integrity of documents and protocol messages that travel between multiple XML processors." By publishing Canonical XML as a W3C Recommendation, the W3C consortium and its Director certify that the specification "is stable, contributes to Web interoperability, and has been reviewed by the W3C Membership, who are in favor of supporting its adoption by academic, industry, and research communities." [Full context] [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] [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. [September 21, 2001] "Enabling XML security. An introduction to XML encryption and XML signature." By Murdoch Mactaggart (IBMDev@TextBiz.com). From IBM developerWorks. September 2001. "XML is a major enabler of what the Internet, and latterly Web services, require in order to continue growing and developing. Yet a lot of work remains to be done on security-related issues before the full capabilities of XML languages can be realised. At present, encrypting a complete XML document, testing its integrity, and confirming the authenticity of its sender is a straightforward process. But it is increasingly necessary to use these functions on parts of documents, to encrypt and authenticate in arbitrary sequences, and to involve different users or originators. At present, the most important sets of developing specifications in the area of XML-related security are XML encryption, XML signature, XACL, SAML, and XKMS. This article introduces the first two. XML has become a valuable mechanism for data exchange across the Internet. SOAP, a means of sending XML messages, facilitates process intercommunication in ways not possible before, while UDDI seems to be fast becoming the standard for bringing together providers and users of Web services; the services themselves are described by XML in the form of WSDL, the Web Services Description Language. Without XML, this flexibility and power would not be possible and, as various people have remarked, it would be necessary to invent the metalanguage. The other area of rapid growth is that of security. Traditional methods of establishing trust between parties aren't appropriate on the public Internet or, indeed, on large LANs or WANs. Trust mechanisms based on asymmetric cryptography can be very useful in such situations, but the ease of deployment and key management, the extent of interoperability, and the security offered are, in reality, far less than the enthusiastic vendors of different Public Key Infrastructures (PKI) would have us believe. There are particular difficulties in dealing with hierarchical data structures and with subsets of data with varying requirements as to confidentiality, access authority, or integrity. In addition, the application of now standard security controls differentially to XML documents is not at all straightforward. Several bodies are actively involved in examining the issues and in developing standards. The main relevant developments here are XML encryption and the related XML signature, eXtensible Access Control Language (XACL), and the related Security Assertion Markup Language (SAML -- a blending of the formerly competing AuthML and S2ML). Each of these is driven by OASIS, and XML Key Management Specification (XKMS). This article introduces XML encryption and XML signature... SAML is an imitative driven by OASIS that attempts to blend the competing specifications AuthML and S2ML, and to facilitate the exchange of authentication and authorisation information. Closely related to SAML, but focusing more on a subject-privilege-object orientated security model in the context of a particular XML document, is the eXtensible Access Control Markup Language, also directed by OASIS and variously known (even within the same documents) as XACML or XACL. By writing rules in XACL, a policy author can define who can exercise what access privileges for a particular XML document, something relevant in the situations cited earlier. XKMS, now being considered by a W3C committee, is intended to establish a protocol for key management on top of the XML signature standard. With SAML, XACL, and other initiatives, XKMS is an important element in the large jigsaw that makes up security as applied to XML documents. Its immediate effect is to simplify greatly the management of authentication and signature keys; it does this by separating the function of digital certificate processing, revocation status checking, and certification path location and validation from the application involved -- for example, by delegating key management to an Internet Web service." [August 13, 2001] "An Introduction to XML Digital Signatures." By Ed Simon, Paul Madsen, Carlisle Adams. From XML.com. August 08, 2001. ['How to understand and create XML-aware digital signatures.] "The very features that make XML so powerful for business transactions (e.g., semantically rich and structured data, text-based, and Web-ready nature) provide both challenges and opportunities for the application of encryption and digital signature operations to XML-encoded data. For example, in many workflow scenarios where an XML document flows stepwise between participants, and where a digital signature implies some sort of commitment or assertion, each participant may wish to sign only that portion for which they are responsible and assume a concomitant level of liability. Older standards for digital signatures provide neither syntax for capturing this sort of high-granularity signature nor mechanisms for expressing which portion a principal wishes to sign. Two new security initiatives designed to both account for and take advantage of the special nature of XML data are XML Signature and XML Encryption. Both are currently progressing through the standardization process. XML Signature is a joint effort between the World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF), and XML Encryption is solely W3C effort. This article presents a brief introduction to the XML Signature specification and the underlying cryptographic concepts... As XML becomes a vital component of the emerging electronic business infrastructure, we need trustable, secure XML messages to form the basis of business transactions. One key to enabling secure transactions is the concept of a digital signature, ensuring the integrity and authenticity of origin for business documents. XML Signature is an evolving standard for digital signatures that both addresses the special issues and requirements that XML presents for signing operations and uses XML syntax for capturing the result, simplifying its integration into XML applications." [February 09, 2001] IBM and Microsoft Submit Specification for SOAP Security Extensions. The W3C acknowledged submission of a note by International Business Machines Corporation and Microsoft Corporation for SOAP Security Extensions: Digital Signature. Reference: W3C NOTE 06-February-2001, by Allen Brown (Microsoft), Barbara Fox (Microsoft), Satoshi Hada (IBM), Brian LaMacchia (Microsoft), Hiroshi Maruyama (IBM). Submitted by David Fallside (IBM) and David Turner (Microsoft Corporation). Document abstract: "This document specifies the syntax and processing rules of a SOAP header entry to carry digital signature information within a SOAP 1.1 Envelope." Rationale: "The motivation for this Note is to propose a standard way to use the XML Digital Signature syntax to sign SOAP 1.1 messages. We define a SOAP header entry <SOAP-SEC:Signature> for this purpose. We also propose the definition of an extensible namespace for adding security features to the SOAP header. By extensible we mean that new elements can be added to the schema overtime but elements in the schema will not change. It is our intention that other security features, such as confidentiality of SOAP 1.1 messages, will be added within this namespace as appropriate standards, such as forthcoming XML Encryption, become available. What we specifically defer to another Note or working group is the definition of an authentication protocol for SOAP. By 'protocol', we mean any expectation of processing by the recipient of a signed/encrypted message." According to the text of the submission, "The co-submitters of this specification believe strongly in the need for standardized protocols to support interoperable interactions with remote Web-based services. Although there are a number of similar efforts underway, we feel the W3C is well suited to co-ordinate work in this area. We propose the formation of a new working group within the existing XML Protocol Activity or the inclusion of this activity in the XML Protocol Working Group to continue the evolution of this proposal. It is essential that security be part of the interoperability goals within XML messaging." Joseph Reagle (W3C Team Contact for the XML Signature Working Group) supplied this explanation and disposition in the W3C Staff comment: "The SOAP-SEC submission specifies how to use XML Signature with SOAP via envelop headers. First, it imports two optional envelop headers for use in SOAP-SEC: 'actor' can be used to indicate the recipient of a header element; 'mustUnderstand' indicates whether an application must attempt validation of the enclosed Signature. While the example provided is of a detached signature, (<Signature> is a sibling of the element signed), enveloping and enveloped signatures are permitted, where <Signature> is an ancestor or descendant respectively. XML Signature can work with arbitrary content, but its use with these SOAP headers might be of interest to the XML Protocol Working Group as a usage scenario for mandatory/optional signature validation over messages. Second, the submission defines a global attribute 'ID' in the SOAP-SEC namespace that is defined to always be of type ID. This can be used by applications as a referent of a Signature to unambiguously identify and reference elements. W3C Working Groups, especially XML Signature, might consider generalizing and standardizing this approach for use by all XML applications. This submission will be referred to the attention of the XML Protocol Working Group and the XML Signature Working Group email lists for the reasons stated above." See also: Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP). "This document covers how digital signatures may be used with XML documents to provide authentication and tamper-proof protocol messages specifically for Version 1.0 of the IOTP protocol. The reader should recognize that an effort towards general XML digital signatures exists but is unlikely to produce its final result in time for IOTP Version 1.0. Future versions of IOTP will probably adopt by reference the results of this general XML digital signature effort. . . The Internet Open Trading Protocol (IOTP) provides a payment system independent interoperable framework for Internet commerce as documented in [RFC 2801]. All IOTP messages are XML documents. XML, the Extensible Markup Language [XML], is a syntactical standard promulgated by the World Wide Web Consortium. XML is intended primarily for structuring data exchanged and served over the World Wide Web. Although IOTP assumes that any payment system used with it provides its own security, there are numerous cases where IOTP requires authentication and integrity services for portions of the XML messages it specifies." [cache] See XML Messaging. - [May 19, 1999] "Report on W3C signed-XML99 Workshop." [WWW8: XML-DSig] By Joseph M. Reagle. Presentation Slides. From the Eighth International World Wide Web Conference (WWW8), Toronto, Canada. May 1999. [local archive copy]
[October 06, 2000] "B2B is ideal test bed for XML Digital Signatures." By James Kobielus. In Network World (October 02, 2000). "We can now take for granted the notion that electronic signatures, under U.S. law, may be as legal and binding as the pen-and-paper variety. The new Electronic Signatures in Global and National Commerce Act has removed legal impediments to potential acceptance of various electronic techniques for signing commercial contracts and other agreements...Digital signatures deliver critical authentication, tamperproofing and nonrepudiation services for legally enforceable transactions, so it's only a matter of time before they're adopted everywhere in the business-to-business arena. But it's doubtful that many business-to-business trading communities will rush to implement digital signatures without a flexible, general-purpose standards framework for applying and validating signatures on electronic documents. Fortunately, the standards community is well along in defining such a framework: XML Digital Signatures (XML-DSig). XML-DSig is a set of draft specifications that has considerable industry support where it counts: early vendor implementation and ongoing interoperability testing. What's most important, the XML-DSig framework is application-independent and supports signing of any content type, XML or non-XML, as long as that content can be addressed across the Internet, extranet or intranet via uniform resource identifiers (URI). XML-DSig defines procedures for binding cryptographic signatures to one or more URI-addressable local or network resource and for validating those signatures. XML-DSig also specifies an XML syntax for defining signature blocks that can be embedded in all content types. We will start to see commercial implementations of XML-DSig early next year. During this time frame, the World Wide Web Consortium and Internet Engineering Task Force, which are jointly shepherding the XML-DSig initiative, are expected to finalize and then ratify the standards."
|
 | Receive daily news updates from Managing Editor, Robin Cover.
 |
|
