The XML Key Management Specification went into a 2.0 Version in June of 2005. The idea behind XKMS had always been to enable Web services security by providing a mechanism for signing, sealing, encrypting and exchanging electronic
XML Signature and XML Encryption both rely on the Public Key Infrastructure, or PKI, to help handle encryption and decryption, digital signing and sealing, and to verify identity of users or integrity for documents. Existing PKI implementations available include X.509, PGP, Simple Public Key Infrastructure (SPKI) and Public Key Infrastructure X.509 (PKIX) among others. It might seem logical to ask which implementation to use, but that isn't a truly general solution because it interoperates only with like PKI implementations. Nor are pairwise interoperability solutions sufficiently general to allow arbitrary partners with equally arbitrary PKI implementations to interoperate at will or at need.
It's an ugly problem, but XKMS sidesteps the issue by absolving clients of PKI management through delegation to a trusted third party. The trusted third party actually handles XKMS services, but also manages the PKI interface for client applications. Thus, XKMS delivers the following key capabilities that cut through the serpentine labyrinth of options that PKI implementations pose:
- XMKS creates an abstract layer between an application and the PKI provider, which turns PKI implementations into easily-switched selections that impose no need for modifying the application that calls them.
- XKMS shields applications from the details of PKI syntax and semantics, allowing them to use a simple XML-based protocol to talk to the XKMS service instead.
- XKMS moves the complexity from client applications to underlying infrastructure and helps keep those applications smaller and cleaner. In turn, this makes them usable even on mobile devices and other non-traditional computing platforms.
- Using XKMS also makes applications more transport, platform and vendor neutral by removing PKI dependencies and specifics from the applications themselves.
XKMS itself consist of two sub-specifications:
- One is used to register public keys and is called the XML Key Registration Service Specification, or XKRSS. Clients can generate public/private key pairs and register them with the service provider. Alternately, XKMS can generate a key pair for the client, register the public key itself and deliver the private key to the client for its own use. The XKMS can even store the private key on the client's behalf, but always keeps a backup should the client lose its copy. As with other key registration and handling services XKRSS can register, reissue, revoke and recover keys.
- The other assists with retrieval of data based on key information, known as the the XML Key Information Service Specification (aka XKISS). It defines a protocol that permits applications to delegate processing of key information associated with an XML signature, XML encryption or other use of the XML Signature
element by passing that information to an XKMS service provider (you basic trusted third party) and letting it handle the nitty-gritty details. XKISS can resolve or locate elements (which establishes that the key exists, but does not check its trustworthiness or validity), but it can also validate elements which also ensures that the key binding information is trustworthy.
XKMS thus promises to make working with digital signatures, encryption and other key-based information labels or exchanges much easier for developers and clients than it has ever been before. It should be quite interesting to see what fruit begins to drop from this potentially fecund tree.
For more good information on XKMS please consult:
- Robin Cover's XML Key Management Specification home page provides a great overview and pointers to all key XKMS documents and specifications.
- Manish Verma, "XML Security: The XML Key Management Specification", IBM DeveloperWorks, January 27, 2004, provides a great overview of the intent behind and capabilities of XKMS along with detailed programming examples of how to use the APIs in code.
About the author
Ed Tittel is a full-time writer and trainer whose interests include XML and development topics, along with IT Certification and information security topics. E-mail Ed with comments, questions, or suggested topics or tools for review.
This was first published in January 2006