Developing a X-KRSS Web Service

In my last column I sketched out an alternative to WSDL. In my ongoing attempts to suggest useful ideas for others to implement, I now want to spend some time discussing an implementation of a real service. I'm going to look at XKMS, the XML Key Management Service. (A separate document specifies bindings to SOAP and HTTP.) This is a recommendation that has finished its W3C Last Call phase and is unlikely to see anything other than editorial changes at this point.

I chose XKMS for a couple of reasons. First, I think XKMS is, indirectly, very important. I believe that web services need end-to-end message integrity and privacy, which means that they need XML Digital Signature and XML Encryption. Those technologies, in turn, scale best when they use public key cryptography. Public key crypto needs a supporting infrastructure, PKI, to handle distribution and certification of keys, etc.

PKI has historically been very expensive and unwieldy, and XKMS seems to be the last best chance to get a reasonable infrastructure so that we can sign and encrypt our web service messages. Contrarily, the PKI industry has taken a real beating over the past few years, and there aren't many vendors out there.

Put another way, the spec isn't very big, and it covers a great deal and can really be seen as an enabling technology for general web services deployment. On the negative side, knowledge of cryptography is required, as is a crypto toolkit. Fortunately, with OpenSSL, the open source community has a world-class cryptographic toolkit available.

The second reason is that the XKMS specification itself is worth looking at. It's about 60 pages long, which puts it on the shorter side of the W3C page-count ruler. Within those pages it covers four message exchange styles, two services, and six operations. In addition, easily 10 percent of the document is message samples with a lot of base-64 encoded blobs.

Looking at the big picture, it seems like wrapping an XKMS front-end around OpenSSL is an interesting, and potentially very useful, thing to do.

Essential Reading

What Are Syndication Feeds
By ShelleyPowers

Syndication feeds have become a standard tool on the Web. But when you enter the world of syndicated content, you're often faced with the question of what is the "proper" way to do syndication. This edoc, which covers Atom and the two flavors of RSS--2.0 and 1.0--succinctly explains what a syndication feed is, then gets down to the nitty-gritty of what makes up a feed, how you can find and subscribe to them, and which feed will work best for you.

Read Online--Safari
Search this book on Safari:

Code Fragments only

What to implement?

The first phase of implementing a web service is no different than any other software project. You look at the requirements (or specification) and see what you can throw out.

In this case, we'll start with the message exchange styles. I used the term styles because they're not necessarily MEP's (patterns) in the SOAP 1.2 sense. Rather, XKMS defines synchronous and asynchronous. The synchronous model is what you expect: the response to a request contains the results of performing the requested operation. In asynchronous processing, the response indicates that the processing isn't completed. When it is, the XKMS server sends a second response, called a notification. The client then sends a "give me the results" request and then the server sends the operation results.

Before we put this on the "future release" list, we should understand why it might be necessary. In conventional PKI a Certification Authority is supposed to perform "due diligence" before signing a certificate. For an enterprise, this could mean checking employee records, academic enrollment, etc. High-value certificates could even require FBI-style background checks. While the chances of that happening are pretty unlikely, in order to model real-world certificate issuance, XKMS had to define a protocol that allowed off-line processing.

If only to avoid complexity, we're not going to implement that. The other reason is that there are probably very few clients -- I haven't seen a single one -- that can handle it.

The next messaging style is called "Two Phase Request". In this style, the server responds with a special status code and a string of random bytes or a nonce. The client now resends its request, along with the nonce. This exchange helps ensure the legitimacy of the client by having it prove it can read any replies it might get. This helps the server avoid expensive operations (such as verifying the digital signature on a certification request) if the client turns out to be a "l33t hax0r 0wn3d" zombie.

Our server is designed to run inside the enterprise behind suitable firewalls. While this isn't the strongest guarantee of safety -- internal nets do get cracked -- it does seem like it's "good enough" protection. Therefore, the second item to defer is the two phase request.

While we understand the need for these different styles, we've reasonably sure that they don't fit the 80/20 rule for us, so we can ignore them, at least for now. We're left with a simple request-response server with four operations divided into two services.

Prioritization

The next phase of web service development is also similar to other projects. We look at the remaining requirements and prioritize them. For primarily historical reasons, XKMS divides its operations into two services: the XML Key Information Service Speficiation (X-KISS) and the XML Key Registration Service Specification (X-KRSS). It's probably not coincidence that X-KISS is similar to the old admonition, "Keep it simple, stupid".

One of the major features of X-KISS is that a client can "pluck out" a dsig:KeyInfo element from an XML Digital Signature, stuff it in mostly-boilerplate XKMS wrapper, and send it off to the XKMS server. Depending on the boilerplate, the server will respond with the actual key used to do the signing or, alternately, information about the validity of the identity associated with the key. In other words, if you already have signed data, X-KISS will help you process it.

There are a couple of reasons why that's not the problem we need to solve. First, signed data almost always includes the signer's certificate, because historically it's been impossible to fetch it after the message has been recieved. Second, credential validation is a very hard problem, one that's very specific to individual deployments. Third, web service messages with digital signaturers are still fairly uncommon, and one of the biggest drawbacks is how hard (or expensive) it is to get keys. Therefore, we should focus on this problem first and deal with the others later. Again, web service development is the same as other software: in the second release we'll fix the problems caused by the first release.