XML Key Management Services
W3C Activity Proposal, DRAFT
Introduction
There is substantial interest in deploying Web Services layered on XML
Protocol and described in a service description format expressed in XML.
Existing Remote Procedure Call (RPC) specifications are broad in scope but in
practice limited to relatively narrow applications that are confined within a
single administrative domain. An important goal of the Web Services initiative
is to support applications that act across organizational boundaries. Such
services need a considerably more comprehensive security infrastructure than is
possible by simply layering an RPC mechanism over a Transport Layer security
protocol such as SSL or TLS.
There is a general consensus in the network security community that Public
Key Infrastructure is the technology of choice for meeting these objectives.
There is also a widespread perception that PKI implementation places too heavy a
burden on PKI enabled applications.
XKMS is designed to shield the client from the complexity of an underlying
PKI. XKMS is a Web service that provides an interface to a PKI in the terms that
most directly map to the use of a PKI by an application, namely registration,
location and validation of the cryptographic keys themselves.
XKMS provides an interface to an underlying PKI but does not introduce trust
semantics of its own. XKMS is thus backward compatible with traditional X.509
based PKI and forward compatible with possible future PKI proposals such as a
PKI expressed through the Semantic Web.
XKMS is an example of a Trusted Web
Service. The principal requirements for specification of a standard compliant
version of XKMS are common to the specification of any trusted service. These
include:
- Specification of a standard means
of binding cryptographic enhancements to XML Protocol Messages
- Specification of a standard means
of describing necessary cryptographic enhancements as part of a Web Service
description.
XML Key Management Service Specification
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.
Both protocols are defined in terms of structures expressed
in the XML Schema Language, protocols employing the Simple Object Access
Protocol (SOAP) v1.1 [SOAP] and relationships among messages defined by the Web
Services Definition Language v1.0 [WSDL]. Expression of XKMS in other compatible
object encoding schemes is also possible.
Standardization of XKMS would at a minimum require the specification of XKMS
layers on the W3C final recommendations for XML Schema, XML Signature, XML
Encryption and XML Protocol.
Requirements for Standardizing XKMS
As currently specified XKMS is layered on Simple Object Access Protocol
(SOAP). Clearly a standardized version of XKMS must layer on industry standards
and thus a standardized version of XKMS must layer on XML Protocol.
In addition the XKMS standard does not fully specify the manner in which XML
Signature is used to authenticate an XKMS message, although use of the proposed
specification for XML Signing of SOAP messages is strongly indicated. Nor is any
mechanism described by which a trusted key for a Web service may be obtained. A
fully specified version of XKMS would therefore refer to specifications that
describe:
- The cryptographic enhancement of XML Protocol Messages
- Description of cryptographic enhancements in a Web Service Description.
In addition to being required for standardization of XKMS, the need for
specification of a standard means of achieving these goals is common to the
specification of all types of Web Service that are to rely on the cryptographic
enhancements described in XML Signature and XML Encryption.
Lot of stuff here
The proposed scope of the working group consists of specifying a means of
interfacing a client to a PKI through a Web Service and related specifications
to apply cryptographic enhancements to Web Services.
XKMS PKI Interface over XML Protocol [Reword, SOAP today, XP Tommorow]
The XKMS 1.1 Specification leverages
SOAP and the XML Signature KeyInfo element to describe a complete client
interface to a PKI.
XKMS 1.1 specifies protocols for distributing and registering public keys,
suitable for use in conjunction with the proposed standard for XML Signature
[XML-SIG] developed by the World Wide Web Consortium (W3C) and the Internet
Engineering Task Force (IETF) and an anticipated companion standard for XML
encryption. 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).
Extensions to XKMS 1.
The XKMS 1.1 Specification specifies a minimal PKI interface designed to
shield the client from the complexity of the underlying PKI. Commentators on the
XKMS specification have suggested additional application scenarios, some of
which may require extension of or further refinement of XKMS.
One scenario of particular interest is the XKMS 'referral' scenario in which
an XKMS service acts as a proxy, routing and relaying requests to the
appropriate responder. A very important specific implementation of the XKMS
referral scenario is the 'four corners' model. Many financial services are based
on a four corners model in which the principals in a transaction (e.g. the buyer
and seller) are both represented by a different agent (in the case of credit
card transactions the issuing and acquiring banks).
Out of Scope
The following topic areas are out of scope:
- Design of new cryptographic algorithms and/or protocols.
- Issues of Non Repudiation, including but not limited to 'technical
non-repudiation' and 'contractual non-repudiation'.
- Sources of Trusted Time.
- Protocols and data structures for establishing inter-domain trust,
including but not limited to 'cross-certification'.
- Expression of existing PKI data structures in XML.
- Specification of inter-domain trust semantics.
- Authorization and Authorization Assertions.
- Attribute Certificates.
- Knowledge representation syntax.
Answers to W3C Activity Proposal Questions
- 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.
- 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 are generally considered to be incompatible with the
demands of constrained devices such as hand held wireless data devices and
embedded systems. 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.
- for W3C/IETF coordination.
- The Security Services Technical Committee of OASIS is
currently working on an XML protocol 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.
- 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.
- 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?
- There is no master plan for providing cryptographic enhancements to XML
Protocol messages or Web Services.
- 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?
- It is possible that the XML Protocol or Web Services WG could address all
or part of the subject matter. This would be an acceptable outcome but not the
preferred outcome. Both groups have a wide scope but do not have development
of a security architecture as their principal focus.
- 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 to the Working Group(s) established for
co-ordination of Web Services and XML Protocol.
The principal authors of the XKMS protocol have entered into a memorandum of
understanding under which all Intellectual Property Rights the parties may have
acquired would on formation of a W3C working group to standardize XKMS be made
available to all implementers of the protocol under a non-discriminatory royalty
free license.
The principal constraints on the development of XKMS and related
specifications is the dependence on XML Protocol and WSDL. The milestones set
out below assume that the XML Protocol WG meets the milestones already specified
and that a WSDL WG is chartered in the near future.
- July 2001
- XKMS Workshop
- August 2001
- Working Group face-to-face meeting
- September 2001
- Proposed Recommendation for XKMS and Cryptographic
Enhancements to XML Protocol
- December 2001
- Recommendation for XKMS and Cryptographic Enhancements to XML Protocol
- April 2002
- Proposed Recommendation for description of cryptographic enhancements to
Web Services.
- June 2002
- Proposed Recommendation for description of cryptographic enhancements to
Web Services.
- August 2002
- WG terminates work
W3C Activities
XML and XML derived activities have become a strategic
technology in W3C and elsewhere. Each deliverable of any Working Group must
satisfy the dependencies from other W3C Working Groups before it can advance to
Candidate Recommendation.
- XML Activity
- The XKMS Working Group will be represented in the XML Coordination Group to coordinate
with other activities represented in this group. In particular, the following
activities are concerned:
- XML Schema WG
- The XML Schema specifications are currently Working Drafts in Last Call.
The serialization functionality developed by the XML Protocol Working Group
will be based on XML Schema.
- XML Linking WG
- XPointer and XLink are both in last call for Candidate Recommendation
- XML Protocol
- XML Protocol has issued a draft requirements document.
- XML Signature
- XML Signature is a Candidate Recommendation.
- XML Encryption
- XML Encryption has issued a draft requirements document.
- Web Services
- [WG not yet chartered but expected to be].
- RDF Schema WG
- The RDF schema specification is also currently a
Candidate Recommendation.
At the current time, there are no known dependencies on the
work produced by the Working Group.
The XML Protocol Working Group should liaise with at least
the following groups outside W3C:
- IETF
- The Working Group will cooperate closely with the IETF on
the use of XKMS to interface to a PKIX conformant PKI. In addition the Working
Group will cooperate closely with IETF Working Groups that may develop
profiles for making use of XKMS (e.g. S/MIME, TLS, IPSEC, DNSSEC)
- IETF-SACRED
- The Working group will liaise with the IETF SACRED group with the
objective of harmonizing the SACRED protocol layer with the X-KRSS roaming
operation.
- ebXML
- The Working Group will liaise via cross-participation with
the Transport, Routing and Packaging project team within ebXML (electronic
business XML). ebXML is a joint activity of UN/CEFACT (the United Nations body
responsible for UN/EDIFACT), the international EDI standard, and OASIS
(Organization for the Advancement of Structured Information Standards).
- SAML
- The Working Group will liaise via cross-participation with the OASIS
Security Services Technical Committee developing the Security Assertions
Markup Language Specification.
- WAP Forum
- The Working group will liaise via cross-participation with the WAP Forum.
- European Telecommunications Standards Institute
- The Working group will consider the impact of the ETSI XML Advanced
Electronic Signatures proposal.
This section describes the expectations and requirements of Staff, Member,
and Public commitment necessary for this Working Group to be started -- and
eventually succeed. The actual roles (chair, author, editor, contributor,
implementor) and definitions are be defined by W3C Process and derivation of the
XML Signature Working
Group Contributor Policies.
Contributors to this working group are expected to commit to 15% (6 hours a
week). Commitments for Author and Editor positions are 25% and 35%
respectively.
W3C Team commitment
The working group would have a W3C staff contact. It is expected the staff
contact commitment (including requirements management and participation in any
WGs that must be coordinated with) will take 20% of staff time
W3C Member commitment
This is a public working group and anyone may contribute to the Working
Group. However, at the outset of the Activity, the interested W3C member
organizations are expected to identify one or more individual contributors to
the Working Group and the level of contribution at which they are willing to
participate.
Public contributors are welcome to commit to the completion of any action
item or to the fulfillment of the roles described in the Contributor Policies.
Note, materials sent to the public list are part of the W3C site and subject to
W3C policies
and licenses. The W3C holds the copyright of all Working Group deliverables
(e.g., specifications).
TBS
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 and XML Encryption Working Group. An XKMS 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 above.
See the Participants Team
statement above.
See the Intellectual
Property section above.