W3C XML Key Management Activity 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 Key Management Specification (XKMS) is designed to meet two sets of requirements. These are, to facilitate the deployment of Public Key Infrastructure (PKI) generally by allowing a simple client to make use of sophisticated PKI functionality and to provide PKI support for XML applications in particular in a manner that is consistent with the XML architectural approach.

XKMS consists of two protocols, the XML Key Information Service Specification and the XML Key Registration Service Specification. These protocols build upon elements defined in the XML Signature specification and anticipate the use of the XML Encryption specification. A new working group needs to be chartered to develop a Key Management specification. This proposal explains the need for a Key Management specification from market and technical perspectives, identifies a number of interested companies and recommends that a W3C working group begin in September 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).

The X-KISS specification defines a protocol for a Trust service that resolves public key information contained in XML-SIG 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. A key 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.

The X-KRSS specification 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 future needs of future XML based applications such as cryptographically enhanced Web Services.

Public Key Infrastructure (PKI)

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 since to serve its purpose the PKI must reflect the complexity and subtly of real world trust relationships. Requiring that the configuration information is managed into client applications has caused deployment issues for some PKI clients.

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 PKI trust service that provides an XML interface to an underlying PKI. This achieves the following benefits:

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. There thus exists a niche for which XML based Trust Services are the only acceptable technology as yet proposed. 
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 "Participants - Team" below.
What is the scope of the work?
See Section "Proposed Scope" above.
What are initial timetables?
See Section "Duration and Milestones" below
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 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. Although this deployment is taking place on the basis of the W3C technical note, this note is based on SOAP 1.1 and not on XML Protocol.
    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 members of the group who may have filed as yet undeclared IP claims would be required to make a formal disclosure, thus clarifying the IPR 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. This Briefing Package calls for the creation of an Activity with a single Chartered WG at it's outset. 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 XKMS 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.

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.