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.
The XML Key Management Specification (XKMS) is designed to meet two sets of
requirements. The first requirement is to facilitate the deployment of public
key management services by allowing a simple client to make use of
sophisticated functionality (such as Public Key Infrastructure (PKI)). The
second requirement is to then provide this support for XML applications in a
manner that is consistent with the XML
and XML Signature
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.
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 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. 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 Technlogy
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 subtleties 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 public key management trust service that provides an XML
interface to an underlying PKI. This achieves the following benefits:
Very small client footprint.
XML syntax greatly simplifies implementation.
Trust relationships between enterprises may be configured at the
enterprise level.
Deployment of new PKI features does not require deployment of new
clients.
- 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:
- The primary vendors of PKI infrastructure
- The Primary vendors of XML based Web services infrastructure
- 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?
- Yes.
-
- 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 "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?
- No.
-
- 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.
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.
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.
See the Duration and
Milestones in the proposed charter.
See the Participants section
in the proposed charter.
See the Intellectual Property section
in the proposed charter.
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.