Transliterate: to write or spell (words, letters, etc.) in corresponding characters of another alphabet.
—Webster's New World Dictionary
Zolera Systems is a company developing products that provide security services to Web and XML based applications. When we started, we would describe our first offering as a "security appliance" in order for us to be understood. In the subsequent twelve months, we have seen an amazingly rapid evolution of technologies such as SOAP and WSDL, such that we can now use the term "web service" and no further explanation is needed.
Our corporate background includes a great deal of experience with comprehensive secure distributed infrastructures; Zolera staff have played key roles in the evolution of OSF DCE and the Identrus global public key infrastructure. We have a high level of expertise, much mailing list and work group contribution and serious interest in seeing XKMS evolve through an open standards process.
Since we provide signature and encryption web services, key management is an important issue for us. Since we are targeting the web services environment, service-oriented key management is of great interest. A well-delineated specification could be a core technology for some of our products and is of great architectural interest; we would much rather use an open specification than "build" a proprietary one.
Our view toward XKMS is positive - we strongly advocate the simplification of client requirements to obtain trust services and XKMS is in line with this view. We also believe that a service definition allows much complexity to be hidden as part of the service, including traditional PKI processing such as certificate chain processing, and bridging of security domains. XKMS offers much to simplify the client perspective, and eventually the backend. In the future certifciates may become much simpler given the service architecture - there is no need to issue certificates with keyUsage and extendedKeyUsage extensions when this information may be managed by a trust service.
We are concerned, however, that XKMS will be viewed as a panacea. Complex issues which have impacted PKI deployment, such as costs, key and certificate lifecycle management and liability concerns do not go away by defining an XML service interface. Likewise, replicating existing standards may hinder rather than enhance deployment. LDAP is becoming widely deployed, so replicating this functionality in XKMS may be counter productive. Likewise, the assertion definitions which will extend XKMS may replicate some W3C efforts. We need to understand this better, but are concerned about the creation of redundant standards. Over the years, the PKI community has defined many standard protocols and data definitions. The IETF PKIX Working Group, just by itself has over twenty working drafts and over a dozen RFC's, for a combined total of 2.5Megabytes -- who can keep up? And that does not count the ongoing efforts of ISO, national standards bodies and governments, etc. We do not want to increase this deluge unnecessarily, but rather ensure as much reuse as possible.
XKMS must do more than just replace ASN1 complexity with XML complexity, it must also address some of the hard problems that PKI hasn't touched. XKMS must do more than provide an LDAP fetch or OCSP like status response - it must include techniques which allow responses from a non-trusted party to be useful. We want to avoid the need to build trust into browsers, as has been the case with trusted roots in browsers for SSL. The "just trust us" orientation is currently pervasive, and it must be reduced - XKMS could make it worse.
Along these lines, we note some specific XKMS issues:
It is not insignificant that XKMS does not have the vocabulary to assert that "this key can be used for XKMS responses." In fact, section 2.4 offers warnings, but no solutions, about how clients can rely on the responses it gets. We would like to see any W3C activity start to address this. It is no longer sufficient for companies to become trusted just because they had enough money to buy themselves a slot in the user's browser.
Clients do not have to verify, or even be aware of, certificate chains. This is a compelling argument; it makes sense to centralize (and cache) chain evaluation, provided the client provides enough context to make it possible to determine the chain; XKMS does not appear to allow for such context in its schema.
Including an optional "Nonce" element in all request- response definitions may be necessary to improve the trust associated with XKMS.
The last point raises a major issue - that of managing the relationship of related efforts with different organizations, XKMS and SAML. It is essential that these standards be coherent - organizationally this is an issue. This is related to our concern that the XKMS family (including the assertion standards within Oasis) fit within the evolving W3C framework, especially with assertions and XML Query.
To summarize, Zolera Systems is strongly supportive of the XKMS effort, but wants to ensure that trust is not required to be "wired" into the client as occured with browser root certificates, suggesting the need for trust management requirements. Zolera Systems is also concerned about the relationship of the W3C efforts and the related Oasis efforts - this may require early action to avoid later issues. Overall we believe these efforts are in a positive direction, and Zolera Systems looks forward to participating in the evolution of XKMS.