W3C > XKMS WG

Request for Proposed Recommendation Status

Dear W3C Director,

WhereAs

• you chartered us to develop an XML Key Management Specification, with support of the W3C Membership
• we have developed a specification that meets our charter and requirements
• this specification has received wide review, within the Working Group and the community, and we have addressed the issues raised in this review with consensus on all
• we have implementation experience to validate the design

the XKMS Working group has decided (25 January, 2005) to request that you advance this specification to W3C Proposed Recommendation, per se http://www.w3.org/2004/02/02-transitions.html

Summary of PR request:

• Decision to advance:XKMS WG 25 January, 2005 meeting minutes
• Important changes to the document reported: see the changelog of the XKMS specification and its bindings from the Editor's draft
• Document satisfies group's requirements: No new changes.
• Dependencies with other groups met (or not): No new changes
• Document has received wide review: See report abstract here below.
• Issues have been formally addressed: All issues were satisfactorily closed. See the CR issues list.
• Objections have been reported: No objections were received
• Implementation information: See the CR implementation summary here below or the full report.
• Patent disclosures: no changes since CR. See the WG's Patent Disclosures page.

1. Titles, Abstracts, and Proposed Status

(note: Shivaram Mysore took over as Editor from the specification immediately after the CR publication)

Document Title: XML Key Management Specification (XKMS 2.0) Part-1

Document URI: http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-PUB/PR-PUB-xkms-part-1.html

Estimated Publication date: at most two weeks after receiving approval from the Director

Abstract:

This document specifies protocols for distributing and registering public keys, suitable for use in conjunction with the W3C Recommendations for XML Signature [XML-SIG] and XML Encryption [XML-Enc]. 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).

Proposed Status of This Document section:

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 document is a Proposed Recommendation (PR) of the W3C. This document has been produced by the XKMS Working Group (WG).

The W3C Membership and other interested parties are invited to review the document and send comments thru 3 June 2005 to [email protected], a mailing list with a public archive. Advisory Committee Representatives should consult their WBS questionnaires. After the review the Director will announce the document's disposition. This announcement should be expected no sooner than 14 days after the end of the review.

This is Part 1 of the W3C Proposed Recommendation for the XML Key Management Specification (XKMS Version 2.0). 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 services — the XML Key Information Service (X-KISS) and the XML Key Registration Service Specification (X-KRSS). 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.

This document is based on the XKMS Version 2.0 Candidate Recommendation of 5 April 2004. The Working Group has addressed all comments received, making changes as necessary. Feedback received during that review resulted in clarifications but no major changes. Evidence of interoperation between at least two implementations of this specification are documented in the Implementation Report.

This document has been produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy. Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.

Publication as a Proposed 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".

Document Title: XML Key Management Specification (XKMS 2.0) Bindings

Document URI: http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-PUB/PR-PUB-xkms-part-2.html

Estimated Publication date: two weeks after receiving approval from the Director

Abstract:

This document specifies protocol bindings with security characteristics for the XML Key Management Specification (XKMS).

Proposed Status of This Document section:

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 document is a Proposed Recommendation (PR) of the W3C. This document has been produced by the XKMS Working Group (WG).

The W3C Membership and other interested parties are invited to review the document and send comments thru 3 June 2005 to [email protected], a mailing list with a public archive. Advisory Committee Representatives should consult their WBS questionnaires. After the review the Director will announce the document's disposition. This announcement should be expected no sooner than 14 days after the end of the review.

This is Part 2 of the W3C Proposed Recommendation for the XML Key Management Specification (XKMS Version 2.0). This document covers different protocol bindings with security characteristics for the XML Key Management Specification. Part 1 of this specification covers the XKMS protocols and services. For background on this work, please see the XKMS Activity Statement.

This document is based on the XKMS Version 2.0 Bindings Candidate Recommendation of 5 April 2004. The Working Group has addressed all comments received, making changes as necessary. Feedback received during that review resulted in clarifications but no major changes. Evidence of interoperation between at least two implementations of this specification are documented in the Implementation Report.

This document has been produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy. Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.

Publication as a Proposed 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".

2. Summary of Review

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.

The Working Group defined a total of 36 test scenarios (18 X-KISS, 14 X-KRSS, 1 Compound, 3 Optional). The interoperability results succesffuly satisfied the entrance criteria to Proposed Recommendation. XKMS client developers were asked to report their success or failure of running the tests against a number of XKMS servers using an online questionnaire, that was open from 2004-09-14 to 2005-01-28. 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.

Two clients (VM, GA) implemented all the tests. An additional client (TL) 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. See the XKMS CR Implementation Report for more details.

The WG 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 WG 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 WG's 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.