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:
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.
The following topic areas should be out of scope:
The requirements of XKMS fall directly from the scope:
As stated the requirements are sufficiently clear and concise to permit the working group to proceed with standardization of XKMS without the need to engage in an explicit and separate 'requirements analysis' stage.
Such a requirements analysis would be required if the scope of XKMS was to be substantially widened, for example if the working group were to consider such topics as:
We submit that a protracted requirements analysis phase is not necessary or desirable for XKMS itself. Certain architectural components of the XKMS specification such as a means of signing XML protocol messages may require consideration of detailed requirements however.
Compatibility with XML infrastructure standards imposes the following architectural constraints
The scope of XKMS is confined to delegating the operations required to establish trust to a trust service. The means by which trust services establish trust amongst themselves (the inter-domain trust problem) is out of scope for XKMS. For this reason the Resource Description Framework (RDF) is not a constraint on the XKMS architecture but might be employed as a means of establishing trust between XKMS trust services.
A number of corrections have been proposed to the wording of the XKMS specification that provide clarification rather than changes to the specification.
At present the KRSS <Register> operation serves many purposes. Separation of these purposes into distinct operations would substantially improve the clarity of the specification, i.e.:
- <Registration>
- Register a public key.
- <Reissue>
- Reissue a public key.
- <Revoke>
- Revoke a previously registered key binding.
- <Roam>
- Obtain private key data from roaming infrastructure.
- <Recover>
- Obtain private key data from key recovery infrastructure.
The addition of a timestamp has been suggested by several reviewers. It is unclear whether such a feature should be added to the XKMS specification or be proposed as an extension to the XML Signature specification so that other applications could make use of the same approach.
XKMS 1.1 is layered over SOAP and WSDL. To become a normative standard these references to advisory specifications must be replaced by references to other normative standards.
As a trust service XKMS requires certain features which are not currently part of the XML Protocol scope. While XKMS could specify an ad hoc approach specific to its needs alone it is desirable that an approach capable of wider application be taken.
A standard means of applying the XML Signature and XML Encryption specifications to XML Protocol messages.
It is anticipated that this specification would largely follow the approach taken in SOAP Security Extensions-Digital Signature with such modifications as should prove necessary as a result of differences between the SOAP and XML Protocol specifications and the additional requirements of XML Encryption.
A standard means of specifying the cryptographic enhancements required to access a Web Service.
It is anticipated that the approach to this problem will leverage the XML Signature KeyInfo element to define cryptographic keys. A means of interacting with a Key Agreement service should be defined, but definition of new cryptographic algorithms is outside the scope.
XKMS is dependent on the XML Signature and Encryption specification to provide authentication and confidentiality services and to provide the syntax for identifying cryptographic keys.
XKMS 1.1 is specified as a SOAP 1.1 Web Service. A normative standard for XKMS must be aligned with the serialization and packaging mechanisms specified by XML Protocol.
In addition XKMS represents a specific type of Web Service, a Trust Service in which the protocol messages are enhanced by means of XML Signature and/or XML Encryption.
SAML specifies a protocol for communicating authorization and authentication data by means of Trust Assertions. XACML extends the SAML framework to address access control policy data.
XKMS addresses a different problem domain to SAML and XACML but the architectural approach is broadly compatible.
A large user base of X509, PKIX and S/MIME applications is deployed. In particular most major email messaging applications (Microsoft Outlook, Lotus Notes, Netscape Communicator) provide built in support for S/MIME.
A lightweight implementation of the S/MIME specification based on an XKMS Trust Service could allow constrained devices (e.g. handheld wireless devices) to interoperate with legacy S/MIME applications. An implementation note specifying the XKMS features required to support such a service would be a useful adjunct to the main XKMS specification.
The 'four corners' trust relationship model occurs in many financial services applications. The two principals in the transaction (e.g. a buyer and a seller) are each represented by a financial intermediary (e.g. the buyer's bank and the seller's bank) which has a specific fiduciary duty to the other parties.
There is considerable interest in using XKMS to support a four corners trust model amongst the financial services community. XKMS permits a direct mapping of the four corners model trust relationships to protocol messages.
Mechanisms for establishing inter-domain trust should be out of scope.
If XKMS were associated with a particular inter-domain trust model the objective of decoupling the client from the underlying PKI would be lost. It would (rightly) be assumed that XKMS was biased to favor a particular trust model.
Representation of inter-domain trust relationships is a complex task that has not been fully addressed by any existing PKI proposal. The need to standardize inter-domain trust models arises from the need for client interoperability and the limitation that applications can only rely on widely implemented PKI features. Transferring the task of managing inter-domain trust relationships to a Trust Service should not be coupled with the specification of new means to establish inter-domain trust since:
Practical applications of trust services on a wide scale are likely to require the specification of some means of Key Agreement by which a two public key holders establish a shared secret.
While such a facility is likely to be required for deployment of XKMS the history of developing key agreement protocols in working groups is not good. The range of architectural approaches appears to be large. Key agreement protocols are susceptible to a large number of subtle failures. As a result working groups that attempt to develop key agreement protocols are likely to end up inventing frameworks for negotiating key agreement mechanisms instead, introducing more complexity and more opportunity for failures caused by subtle errors.