Update 2005-05-12: The W3C XML Key Management WG released a Proposed Recommendation for the XKMS specification version 2.0, including "XML Key Management Specification (XKMS 2.0)" and "XML Key Management Specification (XKMS 2.0) Bindings." XKMS specifies protocols for distributing and registering public keys, suitable for use with the XML-Signature and XML Encryption Recommendations. The Bindings document defines different protocol bindings with security characteristics. Publication as a W3C Recommendation in June 2005 is anticipated. See details in the news story "W3C Proposed Recommendation for XML Key Management Specification (XKMS 2.0)."
[April 06, 2004] The W3C XKMS Working Group has addressed Last Call issues relating to the April 18, 2003 XKMS Working Draft and has now approved publication of Candidate Recommendations for XML Key Management Specification (XKMS 2.0) and XML Key Management Specification (XKMS 2.0) Bindings.
The XKMS Candidate Recommendation period will last for at least six months in order for the WG to collect implementation feedback and evaluate implementation experience. This W3C Working Group was chartered to "to develop a specification of an XML application/protocol that allows a simple client to obtain key information (values, certificates, management or trust data) from a web service."
The main XKMS Part-1 document "specifies protocols for distributing and registering public keys, suitable for use in conjunction with the standard for XML Signatures defined by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF), and the companion standard for XML encryption." XKMS Part-1 defines two service specifications. The XML Key Information Service Specification is a protocol designed "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." The XML Key Registration Service Specification is a protocol designed "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. These protocols do not require any particular underlying public key infrastructure but are designed to be compatible with such infrastructures."
XKMS Part-2 specifies protocol bindings with security characteristics for the XML Key Management Specification (XKMS) as defined in Part-1.
XML Key Management Specification (XKMS 2.0). Version 2.0. W3C Candidate Recommendation 5-April-2004. Edited by Phillip Hallam-Baker (VeriSign). Version URL: http://www.w3.org/TR/2004/CR-xkms2-20040405/. Latest version URL: http://www.w3.org/TR/xkms2/. Previous version URL: http://www.w3.org/TR/2003/WD-xkms2-20030418/.
XML Key Management Specification (XKMS 2.0) Bindings. Version 2.0. W3C Candidate Recommendation 5-April-2004. Edited by Phillip Hallam-Baker (VeriSign). Version URL: http://www.w3.org/TR/2004/CR-xkms2-bindings-20040405/. Latest version URL: http://www.w3.org/TR/xkms2-bindings/. Previous version URL: http://www.w3.org/TR/2003/WD-xkms2-bindings-20030418/.
About the W3C XML Key Management Specification (XKMS)
"The completed W3C XML Signature and XML Encryption Activities focused on the processes of signature and encryption, not on how a cryptographic key, necessary to these processes, is actually obtained. Consequently, there is a requirement that simple XML-based clients be able to securely obtain keys, including those from pre-existing Public Key Infrastructures (PKI). The role of the XML Key Management (XKMS) Activity is to satisfy these requirements in a manner that is consistent with the XML and XML Signature architectural approach...
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). This specification provides requirements for XML key management consistent with these goals, including requirements on the XML key management specification, server implementations and the protocol messages...
XML key management services will primarily be of interest to clients that intend to communicate using XML-based protocols bound to SOAP. It may be that such clients will not have sufficient ASN.1 capabilities in which case the benefits of offloading the parsing of certificates and other traditional PKI structures (e.g. CRLs or OCSP responses) is clear. Clients which possess such capabilities and have no preference to work with XML-based protocols may opt to use non-XML-based protocols defined by PKIX, for example..." [adapted from the Activity Statement and Requirements document]
XKMS Candidate Recommendation Proposed Recommendation Entrance Criteria
A test suite for the XKMS 2.0 CR specifications will be created during the CR period. In order to exit the Candidate Recommendation phase, the following criteria must be satisfied:
* Message processing mechanisms For each of the services defined by X-KISS and X-KRSS: o A minimum of two complete implementations for all the REQUIRED message processing mechanisms (Synchronous response) o A minimum of one complete implementation for all the RECOMMENDED and OPTIONAL message processing mechanisms (Asynchronous response, Two-Phase protocol) * Message syntax o 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 o A minimum of two complete implementations for each of the following X-KISS Services: Locate and Validate o A minimum of two complete implementations for all the REQUIRED elements and attributes described in X-KISS message set o A minimum of one complete implementation for all the OPTIONAL elements and attributes described in the X-KISS message set * X-KRSS protocol set o A minimum of two complete implementations for each of the following X-KRSS services: Register, Reissue, Revoke, and Recover o A minimum of two complete implementations for all the REQUIRED elements and attributes described in X-KRSS message set o A minimum of one complete implementation for all the OPTIONAL elements and attributes described in the X-KRSS message set * Bindings o A minimum of two complete implementations supporting HTTP Transport and Soap 1.2 encapsulation o A minimum of two complete implementations supporting Exclusive Canonicalization together with XML Signature o 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 o 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 interoperability has been demonstrated or not, as proof that we are satisfying the exit criteria.
- XML Key Management Specification (XKMS 2.0). Version 2.0. W3C Candidate Recommendation 5-April-2004.
- XML Key Management Specification (XKMS 2.0) Bindings. Version 2.0. W3C Candidate Recommendation 5-April-2004.
- XKMS Ver. 2 Candidate Recommendation Issues
- XML Key Management (XKMS 2.0) Requirements. W3C Note 05-May-2003.
- XKMS Pre-CR Implementation Intentions. Maintained by Jose Kahan, W3C Team Contact for the XKMS Working Group.
- XKMS Implementation Report
- Mail Archives for W3C public list 'email@example.com'. "This list is for discussion of the W3C XKMS Working Group. Appropriate topics for this list includes meeting announces and minutes, coordination with other activities, questions about the specifications, and (of course) technical proposals and discussion. Inappropriate materials include commercial advertisements and announcements that are not relevant to the immediate activities of the working group (e.g., questions about particular implementations and products, and general announcements about XML or cryptographic conferences or books.)"
- "XML Key Management Specification (XKMS)." W3C Note 30-March-2001. Submitted to W3C by VeriSign Inc, Microsoft Corporation, and webMethods Inc. as a suggestion for message packaging for the W3C XML Activity on XML Protocols; see the W3C Staff Comment.
- W3C XML Key Management Working Group Charter
- XML Key Management (XKMS) Activity Statement
- W3C XML Key Management Working Group web site
- Earlier XKMS news:
- XML-Signature Syntax and Processing. W3C Recommendation 12-February-2002.
- XML Digital Signature (IETF/W3C). - Local references.
- XML Encryption Syntax and Processing. W3C Recommendation 10-December-2002.
- XML and Encryption
- XML and Security Standards" - Reference listing.
- "XML Key Management Specification (XKMS)" - Main reference page.