In discussions about Web services security, a large elephant enters the room: Public Key Infrastructure. PKI is a foundation of the trust services to which the SAML (Security Assertions Markup Language) and Liberty Alliance specifications refer. It also enables the signing and encryption of parts of documents as described by the WS-Security spec. Long before the Web services revolution began, PKI deployment and use was lagging behind expectations. E-commerce drove the adoption of server-side certificates, but client-side certificates, which can authenticate users to Web sites as well as sign and encrypt e-mail, never caught on.
The emerging end-to-end style of Web services is going to force the issue. Channel security (that is, an HTTPS connection) won't be flexible enough for business documents that route through a chain of intermediaries, each responsible for signing, encrypting, or validating parts of those documents. Granular, item-level security is coming, and that's going to require more cryptographic keys, more certificate chains, and more people who know how to make all this stuff work.
Nobody pretends there is an easy way out of the dilemma. Nevertheless, the XKMS (XML Key Management Specification), originally sponsored by VeriSign Inc., Microsoft Corp., and webMethods Inc., takes important steps in the right direction. First and foremost, it pushes the logic of finding and validating certificates out of the client and into the cloud. XKMS is a Web service; if clients of that service can shed hard-coded certificate-processing logic, it will help in several ways. Mobile devices, in particular, could be streamlined. As VeriSign principal scientist Phillip Hallam-Baker points out, certificate processing is unwieldy both in terms of code (about 750KB) and data (VeriSign's Certificate Revocation List has grown to 3MB). Everyone would benefit from the dynamic nature of the service-oriented approach.
In addition to insulating clients from these kinds of flaws, XKMS promises to shield them from the vicissitudes of normal PKI evolution -- for example, the shift from batch-mode certificate checking using certificate revocation lists to real-time checking using the OCSP (Online Certificate Security Protocol). What XKMS doesn't do is offload core cryptographic operations, including key generation and signing, from the client. These are not the most burdensome functions, says Merlin Hughes, chief technical evangelist at Baltimore Technologies PLC, and delegating them wouldn't make sense anyway. "At some point you have to bootstrap the trust system," he notes, which means minimal cryptography capability in the client.
XKMS has two main parts. X-KRSS (XML Key Registration Service Specification) aims to unify several different ways of registering public key information. X-KISS (XML Key Information Service Specification) deals with finding, and optionally validating, certificates. In both cases, XKMS proposes to connect PKI to the Internet's core infrastructure. "The Internet does not run on an X.509 directory," says VeriSign's Hallam-Baker, "but rather on DNS." The nifty idea proposed in an appendix of the XKMS spec is to use SRV records in DNS servers to link the two systems.
XKMS is abstract enough to support alternative certification schemes such as PGP's (Pretty Good Privacy) Web of trust, or the linked local namespaces of SPKI/SDSI (Simple Public Key Infrastructure/Simple Distributed Security Infrastructure, or "spooky/sudsy"), an idea that influenced the design of Groove. These systems enable natural bottom-up trust, arising from ordinary discourse, as opposed to synthetic top-down trust rooted in institutional authorities.
It's encouraging that XKMS, at least in principle, supports these different models side by side. That openness, along with the virtues of a small client footprint and loosely coupled architecture, could help us navigate the troubled waters of identity management, a discipline with basic tenets that remain unclear. To play that helpful role, XKMS will have to be adopted first. For now, its fortunes are linked to those of PKI. In the wake of the PKI industry meltdown, nobody is wildly optimistic. But we do have PKI, we use it, and the near future of Web services does depend on it. Anything that can smooth PKI's rough edges is welcome.