Movatterモバイル変換

|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 CandidateRecommendation to Proposed Recommendation status, the XKMS Working Group (WG)had to give enough implementation experience to satisfy the PR entrancecriteria. The method adopted by the WG was to create anXKMSAssertions and Test Collection. This document ennumerate all theassertions on the XKMS specification, specify tests for these assertions or,otherwise, give rationale as to why an assertion could not be tested. Thetests were grouped into four categories: X-KISS, X-KRSS, Compound, andOptional, corresponding to the two basic XKMS services, combining multiplerequests, and finally, tests for optional features, respectively.

2. Modifications to ProposedRecommendation Entrance Criteria

The following Entrance Criteria were proposed in the XKMS CandidateRecommendationannouncement (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 andSoap 1.2/1.1 bindings, As a result of the feedback received, theSecurity Binding sections was made more concise and clear and nowlists a number of security considerations and how these considerationscould be taken into account by the XKMS payload security features, theTLS ones, or by a combination of both of these. Although there were nospecific tests for the payload security bindings, all of the XKMSfeatures on which these bindings depend were included in one or moreof the tests. The TLS bindings were not tested as the developers feltit was out of scope for the XKMS interoperability test; TLS securityproperties have already been tested and discussed in other fora and areindependent from XKMS.

During the CR period, the WG further refined the two serverimplementation exit criteria to request that there are at least twoservers that are contacted by two or more clients. Likewise, the WGadded an extra criteria requesting that there be at least one clientthat contacts two different servers. The WG felt these refinementsgave a better proof of interoperability.

3. Summary of the Interoperability Tests Results

The Working Group defined a total of 36testscenarios (18 X-KISS, 14 X-KRSS, 1 Compound, 3 Optional). The results aresummarized inAppendix A. Two clients (VM, GA)implemented all the tests. An additional client (TL) implemented reportedsuccess on all the tests, except for the Optional ones as ourreporting rules didn't allow for a developer to reportresults against his own server. Two servers (TL, SQL Data) supported all thetests except for the Optional ones. Only one server (TL ) supported theOptional tests. Both servers were tested against two clients at least. Thesetests satisfy the interoperability entrance criteria to ProposedRecommendation.Appendix A gives a breakdown of thetests.

3.1 Outstanding Interoperability Issues

The Working Group received a total of 43issues. Allbut three suggested changes to the XKMS specification which wereaccepted by the WG (see the Changelog of theXKMSspecification and itsbindings).

The Working GroupG declined the following three issues, the first two as beingdeliberately not addressed and the third one as being out of scope ofthe 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 aprocess of deploying aliveXKMS 2.0 service. It will go live in a couple of months. The ExchangeNetwork is a web service network that links information systems in the stategovernments and federal government agencies, and allows automated and securedata exchanges between Network Node (the service endpoint). The projectstarted about 3 years ago, currently there are 32 states participating inlive data exchanges, many more are in the development and testing stage. Thegoal is to have all 50 states to join the Exchange Network. It is perhaps thelargest web service network in the US.

The Exchange Network has a centralized security service - NetworkAuthentication and Authorization Services (NAAS), the idea is to have a liveXKMS service and move toward public key authentication with signedauthentication 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: InteroperabilityResults Matrix

How the table was constructed

XKMS client developers were asked to report their success or failure ofrunning the tests described in the theXKMSAssertions and Test Collection document against a number of XKMS serversusing an onlinequestionnaire,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 summaryof thequestionnaireresults from the point of view of the entrance criteria. Only the clientsand servers that were reported as succesful in the XKMS CR test suite reportwere taken into account. Some developers built both client and servers. Inthose cases, only the tests of those clients against other servers were takeninto account.

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

X-KISS

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

We had four server implementations, of which two (TL, SQL) implemented allthe tests and were contacted by at least two different clients each. We hadup 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 theREQUIRED entrance criteria as stated above: at least two client and twoserver implementations of each feature; for each feature, at least twoservers contacted by at least two different clients; there should be at leastone client that contacts two different servers.

We had two server implementations (TL, SQL); both of them implemented allthe tests and were contacted by at least two different clients each. We hadup 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 REQUIREDentrance criteria as stated above: at least two client and two serverimplementations of each feature; for each feature, at least two serverscontacted by at least two different clients; there should be at least oneclient that contacts two different servers.

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

OPTIONAL

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

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