| XKMS home

XKMS Candidate Recommendation Implementation Report

Created: 12 Jan 2005

Last revised by $Author: kahan $ on $Date: 13 April 2005 - 19:02:22$

1. Introduction

In order to move forward the XKMS specification from Candidate Recommendation to Proposed Recommendation status, the XKMS Working Group (WG) had to give enough implementation experience to satisfy the PR entrance criteria. The method adopted by the WG was to create an XKMS Assertions and Test Collection. This document ennumerate all the assertions on the XKMS specification, specify tests for these assertions or, otherwise, give rationale as to why an assertion could not be tested. The tests were grouped into four categories: X-KISS, X-KRSS, Compound, and Optional, corresponding to the two basic XKMS services, combining multiple requests, and finally, tests for optional features, respectively.

2. Modifications to Proposed Recommendation Entrance Criteria

The following Entrance Criteria were proposed in the XKMS Candidate Recommendation announcement (you need a W3C member password to browse this link):

• Message processing mechanisms
  For each of the services defined by X-KISS and X-KRSS:
  • A minimum of two complete implementations for all the REQUIRED message processing mechanisms (Synchronous response)
  • A minimum of one complete implementation for all the RECOMMENDED and OPTIONAL message processing mechanisms (Asynchronous response, Two-Phase protocol)
• Message syntax
  • For each of the supported message processing mechanisms, a minimum of two complete implementations for all the REQUIRED and OPTIONAL elements and attributes defined in Section 3 for the Request and Response messages as well as for the Compound and Status requests (i.e, if an implementation doesn't support Asynchronous processing of messages, it doesn't need to support the Status request elements either, but it does have to return a Result code such as Receiver.Refused)
• X-KISS protocol set
  • A minimum of two complete implementations for each of the following X-KISS Services: Locate and Validate
  • A minimum of two complete implementations for all the REQUIRED elements and attributes described in X-KISS message set
  • A minimum of one complete implementation for all the OPTIONAL elements and attributes described in the X-KISS message set
• X-KRSS protocol set
  • A minimum of two complete implementations for each of the following X-KRSS services: Register, Reissue, Revoke, and Recover
  • A minimum of two complete implementations for all the REQUIRED elements and attributes described in X-KRSS message set
  • A minimum of one complete implementation for all the OPTIONAL elements and attributes described in the X-KRSS message set
• Bindings
  • A minimum of two complete implementations supporting HTTP Transport and Soap 1.2 encapsulation
  • A minimum of two complete implementations supporting Exclusive Canonicalization together with XML Signature
  • A minimum of one complete implementation supporting of each of the following security enhancements: Payload Authentication (levels I and II), TLS Bindings (levels I-III)
• Interoperability Matrix
  • The WG will create an interoperability matrix with test cases and document how implementations satisfy those tests. The role of this matrix will be to enumerate each feature of the XKMS protocol and specify which features exist in which implementations and whether iinteroperability has been demonstrated or not, as proof that we are satisfying the entrance criteria

The Working Group succesfully tested all of the HTTP Transport and Soap 1.2/1.1 bindings, As a result of the feedback received, the Security Binding sections was made more concise and clear and now lists a number of security considerations and how these considerations could be taken into account by the XKMS payload security features, the TLS ones, or by a combination of both of these. Although there were no specific tests for the payload security bindings, all of the XKMS features on which these bindings depend were included in one or more of the tests. The TLS bindings were not tested as the developers felt it was out of scope for the XKMS interoperability test; TLS security properties have already been tested and discussed in other fora and are independent from XKMS.

During the CR period, the WG further refined the two server implementation exit criteria to request that there are at least two servers that are contacted by two or more clients. Likewise, the WG added an extra criteria requesting that there be at least one client that contacts two different servers. The WG felt these refinements gave a better proof of interoperability.

3. Summary of the Interoperability Tests Results

The Working Group defined a total of 36 test scenarios (18 X-KISS, 14 X-KRSS, 1 Compound, 3 Optional). The results are summarized in Appendix A. Two clients (VM, GA) implemented all the tests. An additional client (TL) implemented reported success on all the 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 (TL, SQL Data) supported all the tests except for the Optional ones. Only one server (TL ) supported the Optional tests. Both servers were tested against two clients at least. These tests satisfy the interoperability entrance criteria to Proposed Recommendation. Appendix A gives a breakdown of the tests.

3.1 Outstanding Interoperability Issues

The Working Group received a total of 43 issues. All but three suggested changes to the XKMS specification which were accepted by the WG (see the Changelog of the XKMS specification and its bindings).

The Working GroupG declined the following three issues, the first two as being deliberately not addressed and the third one as being out of scope of the specification. All the reviewers agreed to the Working Groups responses:

• Issue 316-bl-1: Clarification: Multiple answers for a QueryKeyBinding with both KeyInfo and UseKeyWith elements?
  • Context: If I have a QueryKeyBinding both a KeyInfo and a set of UseKeyWith elements, and the two constructs refer to different keys (or sets of keys), I assume the resultant response is implementationdependant? (I.e. union vs. intersection of keys found under the two sets of conditions.)
  • Resolution: This issue is deliberately not addressed. The union vs. intersection result could be influenced by who's asking, from where, about whom, with which UseKeyWith, etc. A responder could treat all such cases as an error for validate and doing a union for locate! It could be confusing for fairly naive implementations, but otherwise won't represent implementation problems.
• Issue 316-bl-2: Clarification: Multiple answers for a QueryKeyBinding with a single UseKeyWith item?
  • Context: If I have a QueryKeyBinding with a UseKeyWith item, and there are actually multiple applications defined for the key that is found, should the LocateResult have all the potential applications defined in the response UseKeyWith items, or just the intersection between those originally requested and the full list? (Again, I assume application dependant?)
  • Resolution: This issue is deliberately not addressed by the XKMS specification. Some keys can be shared across applications (e.g. S/MIME and TLS client auth), others might be mandated not to be so shared e.g. a VPN or SET cert (ok ignoring that SET is kind of dead-ish, but it did specifically mandate that its certs not be used for other apps.) It could be confusing for fairly naive implementations, but otherwise won't represent implementation problems.
    Some keys can be shared across applications (e.g. S/MIME and TLS client auth), others might be mandated not to be so shared e.g. a VPN or SET cert (ok ignoring that SET is kind of dead-ish, but it did specifically mandate that its certs not be used for other apps.)
• Issue 332-tl2: Editorial: dsig:PGPData element and "Trust computations"
  • Context: Due to the contradictory wording of Section '4.4.5 The PGPData Element' of XMLSIG it is not clear whether or not PGP packet types other than Key Material Packet's are allowed in a PGPKeyPacket. In order to support XKMS clients that want to perform "trust computations" themselves (as opposed to delegating this to an XKMS service), access to SignaturePackets and TrustPackets would be useful. This is an XMLSIG issue, but I thought it would be prudent to mention it here anyway.
  • Resolution: This issue was declined as the working group feels that this is a XML DSig issue. It has also been mentioned that this issue could be adressed as an XML DSig Errata.

3.2 Success Stories

The Environmental Information Exchange Network (EIEN)of the United States is in a process of deploying a live XKMS 2.0 service. It will go live in a couple of months. The Exchange Network is a web service network that links information systems in the state governments and federal government agencies, and allows automated and secure data exchanges between Network Node (the service endpoint). The project started about 3 years ago, currently there are 32 states participating in live data exchanges, many more are in the development and testing stage. The goal is to have all 50 states to join the Exchange Network. It is perhaps the largest web service network in the US.

The Exchange Network has a centralized security service - Network Authentication and Authorization Services (NAAS), the idea is to have a live XKMS service and move toward public key authentication with signed authentication messages, at least between Network Nodes:

1. Users generate a pair of keys and register them in the central XKMS service (there is an approval process, off course).
2. Users construct an Authenticate message and sign the message using a registered key, the KeyInfo element will contain a unique key name.
3. When an authentication message is received, NAAS will validate the key through the XKMS XKISS, and verify the signature. The user is considered authenticated if both the key and authentication message are valid.

3.3 Advisory Interoperability Data

Two of the interoperability participants prepared and contributed a set of XKMS messages that were exchanged during the XKMS CR interoperability phase. These messages are to be seen as advisory, rather than normative.

• Tommy Lindberg's (Markup Security) XKMS message set (zip file)
• Vamsi Motukuru's (Oracle) XKMS message set (zip file)

Appendix A: Interoperability Results Matrix

How the table was constructed

XKMS client developers were asked to report their success or failure of running the tests described in the the XKMS Assertions and Test Collection document against a number of XKMS servers using an online questionnaire, that was open from 2004-09-14 to 2005-01-28 (you need to have a W3C member or public password in order to browse that link). The following table is a summary of the questionnaire results from the point of view of the entrance criteria. Only the clients and servers that were reported as succesful in the XKMS CR test suite report were taken into account. Some developers built both client and servers. In those cases, only the tests of those clients against other servers were taken into account.

The following information was reported directly by the developers. It does not necessarily represent the latest state of any given implementation over this or later specifications.

X-KISS

The WG defined 18 tests. These tests and their results satisfy the REQUIRED entrance criteria as stated above: at least two client and two server implementations of each feature; for each feature, at least two servers contacted by at least two different clients; there should be at least one client that contacts two different servers.

We had four server implementations, of which two (TL, SQL) implemented all the tests and were contacted by at least two different clients each. We had up to seven client implementations of which three implemented all the tests (TL, GA, VM).

X-KRSS

The WG defined 14 tests. These tests and their results satisfy the REQUIRED entrance criteria as stated above: at least two client and two server implementations of each feature; for each feature, at least two servers contacted by at least two different clients; there should be at least one client that contacts two different servers.

We had two server implementations (TL, SQL); both of them implemented all the tests and were contacted by at least two different clients each. We had up to four client implementations of which three implemented all the tests (TL, GA, VM). The remaining client implemented all the tests except for one (XKRSS-T13).

COMPOUND

The WG defined one test. This test and its result satisfy the REQUIRED entrance criteria as stated above: at least two client and two server implementations of each feature; for each feature, at least two servers contacted by at least two different clients; there should be at least one client that contacts two different servers.

Two servers (TL, SQL) and three clients (VM, TL, GA) implemented the tests.

OPTIONAL

The WG defined three tests. These tests and their results satisfy the OPTIONAL entrance criteria as stated above: at least one client and one server implementations of each feature.

One server (TL) and two clients (VM, GA) implemented all the tests.