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.
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.
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:
-
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. 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?
- 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.