Please see XKMS Implementations for a more up-to-date XKMS implementation report. [This note added 2003-09-17, no other modifications since 2003-07-30]
Dear W3C Director,
WhereAs
the XKMS Working group has decided (27 August, 2003) to request that you advance this specification to W3C Candidate Recommendation and call for implementation.
W3C Last Call Working Draft 18 April 2003 Phillip Hallam-Baker, editor.
This document specifies protocols for distributing and registering public keys, suitable for use in conjunction with the proposed standard for XML Signature and XML Encryption. The XML Key Management Specification (XKMS) comprises two parts — the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS).
This document specifies protocol bindings with security characteristics for the XML Key Management Specification (XKMS).
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is Part 1 of the W3C Candidate Recommendation for the XML Key Management Specification (XKMS Version 2.0), made available for public review by the XKMS Working Group. Part 2 of this specification covers different protocol bindings with security characteristics for XKMS. For background on this work, please see the XKMS Activity Statement.
Note that when first released on 18 April 2003, the XKMS specification consisted of two separate documents: XML Key Management Specification Version 2.0 and XML Key Management Specification Version 2.0 Bindings. In order to show their relationship, the Working Group decided to now refer to them as Part-1 and Part-2 of the XKMS Specification. This is just an Editorial modification and doesn't concern the content of those documents.
This document is based upon the XKMS Version 2.0 Working Draft of 18 April 2003 and feedback received during the review period (see the Disposition of Comments document). The XKMS Working Group believes that this specification addresses its Requirements and all of the Last Call issues.
The purpose of a W3C Candidate Recommendation is to gather implementation experience. The status of implementations will be tracked on the XKMS Working Group page. The XKMS CR period will last a minimum of six months (end of September, 2004) to ensure that enough time is given for providing implementation feedback. Note that the Conformance Section of these document may be improved following the experience gained during the CR period.
Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page in conformance with W3C policy.
Comments on this document should be sent to public-xkms-comments@w3.org, a mailing list with a public archive. General discussion of related technology is welcome in www-xkms@w3.org (archive).
Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than "work in progress".
The XKMS specification has undergone various changes as the WG carried out its work. All published drafts were handled via W3C's CVS web interface and earlier drafts may be inspected there. There were no radical changes to the specification during development and the specification continues to meet the requirements published by the WG.
The WG went through a formal last call process and addressed the received comments. Most of those comments were from other security related working groups (or, in the case of the IETF, active members of such groups). The WG agreed responses to the comments received and sent those back to the commenters.
None.
Currently, there are implementations based on a version of the XKMS specification as submitted by Verisign and others to W3C as a note. Many companies have committed to putting in resources for implementing this latest version. Entrust and Ascertia are working on X-KISS servers based on XKMS 2.0. Rich Salz is working on an Open Source X-KRSS server. Alexsey Sanin is extending his Open Source XML Security LIbrary (xmlsec) to support X-KISS client and servers. There's also the possibility that some of the tests done by these developers be contributed to build an XKMS test-suite. This has leads us to believe that once the exit criteria below are met, we will have sufficient implementation experience to validate the design and merit widespread deployment.
There is also a vast range of experience with PKI implementations, many of which can form the "backend" of XKMS server implementations. Similarly, there is a wide range of cryptographic library software available from which to build implementations (due to the fact the the XKMS specification invents no new cryptographic primitives).
The XKMS Specification describes two different protocol sets (X-KISS, X-KRSS), a message syntax, as well as three different message processing mechanisms (Synchronous, Asynchronous, Two-Phase Request, Compound Requests and Responses). Moreover, part 2 of the XKMS Specification describes different protocol bindings with security enhancements for the XKMS messages (HTTP, Soap/1.2, SSL/TLS). Soap/1.1 doesn't make part of these exit criteria anymore as Soap/1.2 became a W3C Recommendation in June 2003.
From this basis, we propose the following exit criteria, where one complete implementation stands for both a client and a server interoperable implementation (the client and server instances may in fact be separate implementations):
For each of the services defined by X-KISS and X-KRSS:
The WG will create an interoperability matrix for documenting which implementations support which XKMS features. The matrix will ennumerate each feature of the XKMS protocol, provide test cases and document whether implementations satisfy those tests. The resulting matrix will provide proof of satisfaction of the exit criteria.
None.