XML Key Management (XKMS)

Public Key Infrastructure (PKI) provides the much-required foundation for managing public and private keys used in cryptographic processes. Explore XKMS specifications and how they correlate with PKIs in Web service communications.

Like this article? We recommend

Like this article? We recommend

With the growth of XML-related technologies and Web services, the need for
evolving standard XML-based methodologies for keys exchange and verification
became imperative. With parallel developments in encryption (XML encryption) and
signing (XML digital signatures), evolution of an XML-based PKI was imminent.
Subsequent efforts by the industry resulted in an XML-supportive Public Key
Infrastructure equivalent, and a generic specification set for the same, called
the XML Key Management Specifications (XKMS).

Pioneered by a bunch of companies such as Microsoft, VeriSign, webMethods,
IBM, HP, Citicorp, and Reuters, XKMS is now a W3C-recommended specification. The
principal vision is to evolve "an XML application/protocol that allows a
simple client to obtain key information (values, certificates, management or
trust data) from a Web service."

For its success, XKMS has to fully complement and support other major XML
security specifications such as XML encryption and XML digital certificates.
Thus, XKMS is evolving as a standard protocol specification for distributing,
registering, and managing public keysto be made use of with XML signatures
and encryption.

To make use of XKMS in day-to-day Web service transactions, we need an
XKMS-compliant Web service provider that implements the specifications using its
technologies. Industry leaders in Public Key Infrastructure provisioning are the
first batch to release XKMS-compliant services to the market; they usually
develop an XKMS-compliant layer on the top of their existing/proven Public Key
Infrastructure.

An XKMS-compliant serviceoften called a trust
servicetypically provides the following services:

Key (Pair) Registration service: Clients can register both their public
and private keys. Because many parties prefer to retain their private keys to
themselves, the registration of private keys is only optional. Once registered,
the service provider manages the key life cycle.

Key Location service: Authorized clients can retrieve the registered
public key of a given identity in order to establish a secure Web service
communication with the identity.

Key Validation service: Clients can verify the validity of a registered
public key, whether it has expired or been revoked.

The benefits of XKMS service to the communicating Web services can be
summarized as follows:

It shields Web services from the complexities of verifying and managing
public keys.

It makes the underlying PKI transparent to transactions. In other words,
the Web services are completely unaware of the specific PKI implementation
details, and are not affected by the changes made at the infrastructure
level.

Standard syntax and formats result in consistent methodologies for key
registration, updating, renewal, verification, and exchange.

Public Key Infrastructure Basics

Public Key Infrastructure, or PKI, is a comprehensive system that maintains
and manages public cryptographic keys and certificates. PKI is the vital piece
that enables flawless encryption and digital signing across the enterprise for a
wide variety of applications.

Cryptography makes use of a key paircalled public and private
keysfor encryption processes. The public key should be made available to
any genuine requestor who wants to establish a secure communication with the
owner of keys. This key exchange necessitates a certain level of trust between
the requestor and key owner. For example, the requestor must confirm that the
owner is, indeed, who he claims he isand that his public key is authentic
and trustworthy. Similarly, the key owner should protect his public key against
malicious requests.

This level of trust can be established only by maintaining a pool of
identities for all those who are involved in the private transaction. Each user
should be assigned an identity token, which contains a unique name for each
useralong with the public key and other relevant information.

Extending this concept over the Internet, identities obviously need to be
maintained and accessed across the network. This has necessitated the need for
third-party intervention: Certification Authorities (CAs) issue and manage
identity tokens in the form of digital certificates.

A Certification Authority is usually a commercial entity that issues digital
certificates to requesting parties (for example, ABC Company) based on certain
criteria.

These certificates typically contain the following information:

A unique identifier (name and attributes) for the user in a specific
format (called Distinguished Name, or DN)

The public key of the user

The validity period of the certificate issued

Permitted operations for which the key can be used

Once ABC has registered itself with an authorized CA, its public key
information is available from the CA. Anybody across the Internet who wants to
have secure communication with ABC's Web site, for example, can get a copy
of the certificate from the CA and establish a secure connection. Before sending
a copy of the certificate to the requesting Web site, the CA usually signs the
certificates digitally. This is to ensure that the certificate is indeed coming
from a trusted source (that is, the CA), and that the certificate is not
tampered with while in transit.

It is an obvious implication that both the registered and the requesting
parties will fully rely on the Certification Authority and its business process
to secure their communication. Thus, the CAs act as trusted agents between the
key owner and requestor in the overall Public Key Infrastructure.

Examples of certification authorities include VeriSign and Entrust. Different
service providers have introduced different PKI flavors in the market:
X.509/PKIX, SPKI, and PGP Key Identification. X.509 is probably the most widely
used specification.