W3C XML Key Management Working Group Proposal

Summary | Context | Background | Proposal | Resources | Timeline | IPR

This briefing package was created in conformance with the W3C Process Document and Guidebook for Working Group Chairs.

1. Executive Summary

The XML Signature and XML Encryption Activities focus 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). However, this requirement should be satisfied in a manner that is consistent with the XML and XML Signature architectural approach.

The XML Key Management Specification (XKMS 1.0), which was submitted as a W3C Note, builds upon elements defined in the XML Signature specification and anticipates the use of the XML Encryption specification to satisfy these requirements. A new working group should be chartered to create an XML Key Management Recommendation on the basis of the XKMS submission. This proposal explains the need for such an activity from market and technical perspectives, identifies a number of interested companies and recommends that a W3C working group begin in December 2001.

2. Context

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

X-KISS defines a protocol for a Trust service that resolves public key information contained in XML Signature elements. The X-KISS protocol allows a client of such a service to delegate part or all of the tasks required to process <ds:KeyInfo> elements. An objective of the protocol design is to minimize the complexity of application implementations by allowing them to become clients and thereby to be shielded from the complexity and syntax of the underlying PKI used to establish trust relationships. The underlying PKI may be based upon a different specification such as X.509/PKIX, SPKI or PGP.

X-KRSS defines a protocol for a web service that accepts registration of public key information. Once registered, the public key may be used in conjunction with other web services including X-KISS.

Securing XML Applications

XKMS is designed to take full advantage of and provide full support to other XML applications. It is not merely a traditional PKI design recast in XML syntax.

XKMS is designed to leverage existing XML specifications including XML Signature, XML Encryption and those in development such as XML Protocol/SOAP. XKMS also anticipates the needs of future XML based applications such as cryptographically enhanced Web Services.


Public Key cryptography permits secure communication to be established between any parties provided only that each has trustworthy knowledge of the public key of the other. Public Key Infrastructure (PKI) based on digital certificates provides a means of exchanging trustworthy public key information. Configuration of a PKI is perceived to be a complex task because it must reflect the complexity and subtleties of real world trust relationships: requiring that the configuration information to be managed by client applications has caused hampered deployment.

A Trust Service solves the client deployment problem by shielding the client from the complexity of the underling PKI. This ensures that all clients in the enterprise support the full range of PKI features and removes the need for the client to support each new PKI feature.

XKMS is a public key management trust service that provides an XML interface to an underlying PKI. This achieves the following benefits:


While the specified feature-set of the XKMS submission largely satisfies the requirements of the submitting Members, the specification would benefit from further coordination with the XML, XML security, and XML Protocols, wider review and continued implementation.

3. Background

What is the market within the area of the proposal? Who or what group wants this (providers, users, etc.)?
The primary application of the proposal would be in the deployment of trusted Web Services. The most immediate demand for such services arises from the Financial Services industry and from supply chain management and integration applications. In the longer term any form of widely based collaboration will require such services.
Amongst W3C members support for XKMS comes from:
What community will benefit from this activity?
The two principal communities which are served are:
    1)    All users of Web services that require security enhancements
    2)    Users of Public Key Infrastructure
More concretely there is considerable interest from the Financial Services community, particularly money center banks who are members of the Identrus consortium. There is also considerable interest from the US Federal Government whose plans to deploy a PKI for use by Federal government agencies are likely to be significantly impacted by the availability of trust services.
Are members of this community part of W3C now?
Will they join the effort?
The XKMS submission was supported by VeriSign, Microsoft, webMethods, Baltimore Technologies, Citigroup, Hewlett-Packard, IBM, IONA Technologies, PureEdge and Reuters Limited. In that submission the companies of the submitters stated that they intend to participate in both a workshop and working group to standardize XKMS. In addition employees of Bank of America, Entrust, Identrus and Sun Microsystems attended the XKMS workshop and have expressed interest in participating.
Who or what currently exists in the market?
Is the market mature/growing/developing a niche?
The PKI market continues to expand rapidly, principally through the deployment of X.509v3/PKIX based infrastructure. The implementation demands of this infrastructure have required substantial modification to meet the demands of constrained devices such as hand held wireless data devices and embedded systems. 
As the deployment of PKI encounters new requirements that require changes to the underlying specifications the need to decouple the client implementation from the infrastructure implementation increases. XKMS addresses this requirement. 
Many developers now consider XML to be the 'native' data format of their application or platform. There is thus a substantial demand for a PKI interface that is based on XML.
What competing technologies exist?
Without a comprehensive standard for applying cryptographic enhancements to XML protocol messages many applications are likely to adopt layering of XML Protocol over SSL. While this provides a degree of security it does not permit the fine grained security mechanisms specified by XML Signature and Encryption to be utilized.
    Each PKI technology specifies a means of registering and using cryptographic keys by a client. No existing technology provides a comprehensive means by which PKI processing requirements may be delegated in their entirety to a Trust Service.
What competing organizations exist?
This topic could also be of interest to the IETF giving their experience with cryptographic protocols and participation in the joint XML Signature Working Group. However, there is no similar proposal in the IETF, the IETF has not traditionally developed core XML specifications and the IETF PKIX working group in discussion on its mailing list has decided not to develop XML based interfaces to PKI.
    The Security Services Technical Committee of OASIS is currently working on the Security Assertion Markup Language (SAML) to support authorization and authentication. This group is not primarily focused on cryptographic mechanisms however and does not have a direct relationship to the development of XML Protocol. There is thus no overlap between the SAML Technical Committee and the proposed Working Group. 
    The OASIS XML Access Control Markup Language (XACML) Working Group is developing an extension of the SAML specification to address exchange of authorization policy information. No overlap is anticipated with this group either.
What Team resources will be consumed (technical and administrative)?
See Section "Resources" below.
What is the scope of the work?
See the "Scope" section in the Proposed Charter.
What are initial timetables?
See the "Duration and Milestones" in the Proposed Charter.
Is there a window of opportunity that cannot be missed?
Yes. The principal concern is that XML Protocol and WSDL may developed in a manner that does not permit the secure application of cryptographic enhancements and thus be unable to meet the needs of either XKMS or future trusted Web Services. In addition it is important that Web Services be able to rely on a comprehensive and secure interface to a mechanism for management of cryptographic keys, whether based on PKI or a Key Distribution Center.
    XKMS 1.0/1.1 has been rapidly adopted by the major PKI vendors and each of the principal vendors have announced deployment plans. In addition there is significant interest from the financial services industry and from government.
    Additionally, this work should complement the XML Signature, XML Encryption and XML Protocol work. It is important that XML Protocol toolkits from different vendors apply cryptographic enhancements in a consistent manner.
What intellectual property (for example, an implementation) must be available for licensing and is this intellectual property available for a reasonable fee and in a non-discriminatory manner?
No IPR is known to be needed for creating an XML Key Management Specification implementation or for applying XML Signature or XML Encryption to XML Protocol messages. However, some implementations may require algorithms that are patented or regulated by governments. See Section "Intellectual Property" below and question 6.4 from the RSA  FAQ on export controls. In addition there is no means of determining if other parties have filled patent claims that might affect XKMS in jurisdictions that do not publish claims prior to issue.
    A significant advantage of forming a working group is that any as yet undeclared patents are more likely to be publicly disclosed or offered under royalty free terms, thus clarifying the patent status of the specification.
How might a potential Recommendation interact and overlap with existing international standards and Recommendations?
In addition to complementing W3C XML Signature and Encryption, XKMS complements existing PKI standards such as X.509, PGP and SPKI. XKMS provides an architecture-neutral interface to a PKI.
    Some functionality of XKMS overlaps with proposals made to the IETF PKIX group. In particular the OCSP-X and SCVP proposals made to the PKIX group of the IETF support some, but not all of the functionality of X-KISS. The scope of the proposed PKIX protocols is limited to management of X.509v3 certificates and certificate chains and their syntax is based on ASN.1 and not XML. 
What organizations are likely to be affected by potential overlap?
We do not anticipate overlap with any other organization.
Is this activity likely to fall within the dominion of an existing group?
Should new groups be created?
Yes. An Activity with a single Chartered WG at its outset should be created. A deliverable of this WG will be charters for additional work if necessary, which will be sent to the W3C membership for review and approval.
How should they be coordinated?
The means of coordination will depend upon the structure of the Web Services working group(s). It is anticipated that the XML Key Management working group would be a separate working group reporting independently, but closely coordinating with the Working Group(s) established for co-ordination of Web Services and XML Protocol.

4. Current W3C Status

The W3C just held an XKMS Workshop to focus the (1) issues, (2) technical proposals and (3) scope of a potential Working Group and its deliverables such that any future activity can start on the strongest footing possible and move quickly. Otherwise there is no chartered activity at W3C.  A chartered activity would be part of the Technology and Society domain with strong coordination with the Architecture Domain. On the public list the requirements and proposals for XML Key Management continue to be refined.

5. Proposal: XML Key Management Activity

5.1 Proposed charter

See Proposed Charter.

5.2 Working Group and Its Members

This working group should be an activity of the Technology and Society Domain and if possible, maintain continuity with the XML Digital Signature Working Group. An XML Key Management Specification Working Group should be run as a public activity of the W3C: open to all participants willing to meet the participation requirements specified in its charter.

5.3 Proposed Timeline

See the Duration and Milestones in the proposed charter.

5.4 Resource statement

See the Participants section in the proposed charter. The 20% Staff Contact time will come from the decreasing commitment of the XML Signature Activity as it nears completion.

5.5 Intellectual Property

See the Intellectual Property section in the proposed charter.

5.6 Interested Organizations

The W3C public discussion list of XML Key Management Specification includes over 50 subscribers. The Yahoo XKMS developer list includes over 200 subscribers of whom 30 are actively developing XKMS applications. The W3C XML XKMS Workshop was fully subscribed with over 35 attendees.