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.

Bibliographic Information

• 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.