The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
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
Created: June 30, 2005.
News: Cover StoriesPrevious News ItemNext News Item

W3C Publishes XML Key Management Specification (XKMS) 2.0 Recommendation.

Contents

The XKMS (XML Key Management Specification) Version 2.0 produced by members of the W3C XML Key Management Working Group has now been issued as a W3C Recommmendation in two parts: the main XML Key Management Specification (XKMS 2.0) document and the companion XML Key Management Specification (XKMS 2.0) Bindings. The primary XKMS document comprises two parts: the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS).

Advancement to a W3C Recommendation signifies a specification that, "after extensive consensus-building, has received the endorsement of W3C Members and the Director. W3C recommends the wide deployment of its Recommendations, which are similar to the standards published by other organizations." The XKMS Activity is managed as part of the W3C Technology and Society Domain.

The XML Key Management Specification Version 2.0, acccording to W3C's published announcement, is "part of the W3C XML Security Framework, which includes the XML Signature, XML Encryption, and Canonical XML Recommendations. XKMS, a cornerstone of Web applications security, adds public key management to the W3C XML Security Framework.

The XKMS specification defines key functionality essential for Web Services Security, as "Web applications and services security rely on interoperable components that make it possible to sign, seal, encrypt, and exchange electronic documents. All of these functions rely on management and processing of public keys. Before XKMS, these services lacked openly specified, non-proprietary interfaces (APIs). Today, XKMS offers an open, standards-based interface to key management services that has already demonstrated its utility in distributed enterprise security applications."

The XML Key Information Service Specification (X-KISS) section defines a protocol "to support the delegation by an application to a service of the processing of key information associated with an XML signature, XML encryption, or other usage of the XML Signature <ds:KeyInfo> element.

A key objective of the protocol design is to minimize the complexity of applications using XML Signature; by becoming a client of the XKMS service, the application is relieved of the complexity and syntax of the underlying PKI used to establish trust relationships, which may be based upon a different specification such as X.509/PKIX, SPKI or PGP."

The XML Signature specification itself, by design, "does not mandate use of a particular trust policy. The signer of a document is not required to include any key information but may include a <ds:KeyInfo> element that specifies the key itself, a key name, X.509 certificate, a PGP key identifier etc. Alternatively, a link may be provided to a location where the full <ds:KeyInfo> information may be found. The information provided by the signer may therefore be insufficient by itself to perform cryptographic verification and decide whether to trust the signing key, or the information may not be in a format the client can use."

The (X-KRSS) portion of the XKMS specification (XML Key Registration Service Specification) "defines a protocol to support the registration of a key pair by a key pair holder, with the intent that the key pair subsequently be usable in conjunction with the XML Key Information Service Specification or a Public Key Infrastructure (PKI) such as X.509. The key pair to which the information is bound may be generated in advance by the client or on request generated by the service. The Registration protocol may also be used for subsequent management operations including recovery of the private key and reissue or revocation of the key binding. The document specifies means of registering RSA and DSA keys and a framework for extending the protocol to support other cryptographic algorithms such as Diffie-Hellman and Elliptic Curve variants."

The defined XKMS protocol exchanges "consist of a sequence of either one or two request response pairs. XKMS protocol messages share a common format that may be carried within a variety of protocols. A binding to the SOAP message protocol is provided in Part II: Protocol Bindings. It is recommended XKMS implementers support SOAP over HTTP for interoperability purposes. XKMS is transport protocol agnostic however and MAY be layered over any SOAP transport. Implementers may also implement bindings to other protocols at their option."

Bibliographic Information

  • XML Key Management Specification (XKMS 2.0). Version 2.0. W3C Recommendation. 28-June-2005. Edited by Phillip Hallam-Baker (Verisign) and Shivaram H. Mysore. This version URL: http://www.w3.org/TR/2005/REC-xkms2-20050628/. Latest version URL: http://www.w3.org/TR/xkms2/. Previous version URL: http://www.w3.org/TR/2005/PR-xkms2-20050502/.

    Acknowledgments, from non-normative Appendix E: "Participants in the Working Group are (at the time of writing, and by alphabetical order): Guillermo Alvaro Rey (Trinity College Dublin), Stephen Farrell (Trinity College Dublin, Co-Chair), José Kahan (W3C, staff contact), Berin Lautenbach (Apache Software Foundation), Tommy Lindberg (Markup Security), Roland Lockhart (Entrust, Inc.), Vamsi Motukuru (Oracle Corp.), Shivaram Mysore (Co-Chair; Editor since 13 Apr 2004), Rich Salz (DataPower Technology, Inc.), Yunhao Zhang (SQLData Systems). Previous participants were: Daniel Ash (Identrus), Blair Dillaway (Microsoft), Donald Eastlake III (Motorola), Yassir Elley (Sun Microsystems), Jeremy Epstein (webMethods), Slava Galperin (Sun Microsystems), Phillip Hallam-Baker (VeriSign Inc, Editor until 13 Apr 2004), Loren Hart (VeriSign Inc.), Mack Hicks (Bank of America), Merlin Hughes (Baltimore), Frederick Hirsch (Nokia Mobile Phones), Mike Just (Treasury Board of Canada Secretariat), Brian LaMacchia (Microsoft), Pradeep Lamsal, Joseph Reagle (W3C, previous staff contact), Dave Remy (GeoTrust, Inc.), Peter Rostin (RSA Security Inc.), Ed Simon (XMLsec Inc.)

    The authors also acknowledge the extensive assistance provided in the design stage of this specification by David Solo (CitiGroup) and Barbara Fox (Microsoft), and the contributions of Dr. Paul Boisen (NSA), Alex Deacon, Dan Guinan, Marc Hayes, Jeremy Epstein (webMethods), Andrew Layman (Microsoft), Mingliang Pei (VeriSign).

  • XML Key Management Specification (XKMS 2.0) Bindings. Version 2.0. W3C Recommendation. 28-June-2005. Edited by Phillip Hallam-Baker (Verisign) and Shivaram H. Mysore. Version URL: http://www.w3.org/TR/2005/REC-xkms2-bindings-20050628/. Latest version URL: http://www.w3.org/TR/xkms2-bindings/. Previous version URL: http://www.w3.org/TR/2005/PR-xkms2-bindings-20050502/.

From the W3C Announcement

From the text of the announcement "World Wide Web Consortium Issues XML Key Management System (XKMS) 2.0 as a W3C Recommendation. XKMS 2.0 Adds Public Key Management to Web Applications, Web Services.":

XKMS 2.0 Makes PKI Work Better between Enterprises

XKMS 2.0 makes public key infrastructure (PKI) practical to implement in Web applications, including Web services. Standards-based key management enables one to communicate identity across applications and systems, including in Web services applications operating across different trust boundaries.

Traditionally, the common PKI operations (public key certificate management, localization, parsing, and validation operations) are difficult to integrate into existing applications because they add overhead and must be hard-coded for a given PKI. XKMS 2.0 improves PKI deployment by delegating those operations to a server by means of low overhead protocols. At the same time, it is open enough to be used with any public certificate format, chosen by developers to meet application requirements.

XKMS 2.0 Streamlines Enterprise-Level Applications

In real world scenarios, XKMS 2.0 systems streamline enterprise-level applications. All decisions as to the type of public key certificate format, revocation, and so on can be handled directly at the server and transparently to the applications themselves. This will not only help third parties provide PKI operations in an interoperable way, it will also allow companies to install their own XKMS 2.0 servers for applications pertaining to local intranets. Furthermore, enterprises running XKMS 2.0 servers can handle key exchange and management at the server level, rather than at the client level, which makes for a single point of coordination, rather than requiring clients within an enterprise to be aware of each other.

Security Experts, Industry Leaders Drive XKMS 2.0 Development

XKMS 2.0 was developed by the W3C XML Key Management Working Group, and included W3C Members DataPower, Microsoft, Nokia, Oracle, Sun Microsystems, VeriSign and webMethods, along with invited experts co-chairs Stephen Farrell and Shivaram Mysore, Guillermo Alvaro Rey, Berin Lautenbach, Tommy Lindberg, Roland Lockhart and Yunhao Zhang. For more information on implementation and support of the new Recommendation, please review the XKMS 2.0 testimonials.

Testimonials for XKMS 2.0 Recommendation

These testimonials are in support of W3C issuance of XKMS 2.0 as a W3C Recommendation, from DataPower, Oracle Corporation, and XMLsec Inc.

  • DataPower's XS40 XML Security Gateway has long supported XKMS since early 2003. As the most widely deployed XML Web services security gateway among the Global 1000 and large government agencies, our extensive experience has demonstrated that XML Web services are a highly effective way to offer application security as a service to achieve 'separation of concerns' best practices and reduce the complexity of Web services security. In this way, XKMS 2.0 aims to improve PKI deployments and simplify application security by moving digital-signature handling and encryption out of the applications themselves and provide PKI as an easy-to-use service instead.

           — Rich Salz, Chief Security Architect, DataPower

  • XKMS provides PKI integration capabilities that will facilitate and accelerate the adoption of Web services. Oracle was pleased to provide a reference implementation for the XKMS 2.0 specification; we look forward to supporting the specification in Oracle Application Server as XKMS gains widespread deployment.

           — Donald Deutsch, Vice President, Standards Strategy and Architecture, Oracle Corporation

  • In 2002, the W3C's release of the XML Signature and XML Encryption Recommendations led the way in making it much easier, thanks to XML, to integrate cryptography into applications. However, until now, application developers still had to use challenging, non-XML protocols for the key management aspects of cryptography. Now thanks to the W3C XML Key Management Specification (XKMS) Version 2.0 Recommendation which defines straight-forward XML messages and protocols for key management, the last major hurdle to fully enabling XML-based data security has been removed. As a past participant of the W3C XKMS working group, XMLsec congratulates the W3C on its release of the XKMS 2.0 Recommendation.

           — Ed Simon, President and CEO, XMLsec Inc.

About the World Wide Web Consortium (W3C)

The W3C was created to lead the Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability. It is an international industry consortium jointly run by the MIT Computer Science and Artificial Intelligence Laboratory (MIT CSAIL) in the USA, the European Research Consortium for Informatics and Mathematics (ERCIM) headquartered in France and Keio University in Japan. Services provided by the Consortium include: a repository of information about the World Wide Web for developers and users, and various prototype and sample applications to demonstrate use of new technology. To date, nearly 400 organizations are Members of the Consortium. For more information see http://www.w3.org/.

Requirements Background

As presented in the May 2003 XML Key Management (XKMS 2.0) Requirements, XML-based public key management "should be designed to meet two general goals. The first is to support a simple client's ability to make use of sophisticated key management functionality. This simple client is not concerned with the details of the infrastructure required to support the public key management but may choose to work with X.509 certificates if able to manage the details . The second goal is to provide public key management support to XML applications that is consistent with the XML architectural approach. In particular, it is a goal of XML key management to support the public key management requirements of XML Encryption, XML Digital Signature, and to be consistent with the Security Assertion Markup Language (SAML)."

Requirements published in the XML Key Management Working Group Charter specified that the XKMS PKI Interface "must be simple and build upon the <ds:KeyInfo> element specified by XML Signature, and that the XML Key Management Activity be coordinated with and use the deliverables of the XML Protocol, XML Schema, XML Signature and XML Encryption activities." Further, all required, recommended, and optional features of the specification must be implemented in at least two independent implementations before being advanced to Proposed Recommendation; these features, and their specification, must be able to interoperate in a secure fashion. Security and privacy concerns must be addressed by the specification."

As described in the Implementation Report, the XKMS Working Group concluded the Candidate Recommendation (CR) interoperability phase that started 14 September 2004. Thirty-six test scenarios were specified with a total of seven client implementations and four server implementations, implementing all or part of the tests. Two clients implemented all the tests. An additional client reported success on all tests except for the Optional ones as our reporting rules didn't allow for a developer to report results against his own server. Two servers supported all the tests except for the Optional ones. Only one server supported the Optional tests. Both servers were tested against at least two clients. These tests satisfied the interoperability entrance criteria to Proposed Recommendation (PR)..."

Related Recommendations: W3C XML Security Framework

  • XML Signature. W3C Recommendation 12-February-2002. "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. 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..."

  • XML Encryption. W3C Recommendation 10-December-2002. "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. 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.

  • Canonical XML. W3C Recommendation 18-July-2002. IETF/W3C XML Signature Working Group.

    "The XML Recommendation specifies the syntax of a class of objects called XML documents. The Namespaces in XML Recommendation specifies additional syntax and semantics for XML documents. It is normal for XML documents and subdocuments which are equivalent for the purposes of many applications to differ in their physical representation. For example, they may differ in their entity structure, attribute ordering, and character encoding...

    The goal of this Canonical XML specification is to establish a method for serializing the XPath node-set representation of an XML document or subset such that: (1) The node-set is minimally affected by any XML context which has been omitted; (2) The canonicalization of a node-set representing well-balanced XML [XML-Fragment] will be unaltered by further applications of exclusive canonicalization; (3) It can be determined whether two node-sets are identical except for transformations considered insignificant by this specification under XML and Namespaces in XML..."

Principal References
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Bottom Globe Image

Document URI: http://xml.coverpages.org/ni2005-06-30-a.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org