OASIS EKMI Coup D'état

First, some quick acronym definitions before I go acronym crazy...
OASIS - Organization for the Advancement of Structured Information Standards
EKMI - Encryption Key Management Infrastructure
KMIP - Key Management Interoperability Protocol
TC - Technical Committe

Quick background: The EKMI TC was formed in 2007 to create standards around the topic of Encryption Key Management Infrastructure, or EKMI for short. EKMI is the combined management of PKI and Symmetric Key Management Systems. The notion is that both types of systems deal with encryption keys (asymmetric and symmetric), and thus should be fully interoperable and managed jointly. Contrary to some reports, EKMI is not just an XML protocol. The goal of the EKMI TC was nothing short of developing a standard for securely managing any type of encryption key.

The controversy: In February 2009, several major vendors, including IBM, HP, and RSA, announced that they were chartering a new OASIS TC - KMIP. Ironically, some of the people chartering this new TC had been members (though not regular participants) in the EKMI TC as well as the (dysfunctional) IEEE P1619.3 standards committee. By all appearances, the KMIP charter has significant overlap with the EKMI charter, and it is not clear at all why the TC was allowed to go forward, except that under OASIS charter rules due diligence is not required. In essence, a group of vendors can get together and launch their own charter without determining whether or not there is overlap or congruence with existing OASIS TCs. The OASIS argument is that competition is good, but this seems to fly in the face of the OASIS mission, which is to drive "the development, convergence and adoption of open standards for the global information society."

The effect: Coup d'état. For whatever reason, the vendors have opted to develop their own standard outside of the normal standards process. If you look at the KMIP TC site, you will find that their charter is quite extensive and details documents that are already released. What this means is that, rather than engage the EKMI TC and put forward a proposal, these vendors instead have opted to buy their own OASIS TC and subsequent OASIS standard. Moreover, the effect is to destroy the open-source initiative represented by the EKMI TC. These vendors have mobilized their extensive PR resources (see here and here) to drive immediate adoption of their standard, avoiding real input altogether.

Further commentary: What's particularly interesting here is that, while the IEEE P1619.3 committee was not apparently getting anywhere, the EKMI TC was making progress. A Community Standard had just been released and active discussions were underway for developing a reference architecture and audit guidelines. What is most perplexing is that these vendors never engaged the EKMI TC. No conversations were held about the scope and objectives of the EKMI TC, and no effort was made to work with the group. While the KMIP TC claims in their press releases that their efforts do not overlap with the EKMI TC (see here), nothing could be further from the truth. In fact, it seems that they don't even know what work the EKMI TC was undertaking, describing it as an XML standard rather than what it truly was.

Perhaps the most disconcerting thing here is that the OASIS board allowed this to happen. The OASIS charter rules do not require proposers to first review existing committees in comparable areas to determine if it would be better to contribute to an existing effort rather than start a new one. Specifically, the KMIP formers - some of whom were members of the EKMI TC - did not bother to evaluate whether or not a TC already existed around the work they were doing. If they had, they would have found that there was significant (if not complete) overlap between their proposed charter and the EKMI TC charter. The proper and appropriate decision here would have been for these vendors to first join the EKMI TC and propose their standard under the EKMI TC. If the EKMI TC was not open to the proposed direction, then and only then should a new TC been formed. Unfortunately, dirty corporate politics has won out.

The cumulative result here is the effective undermining and eventual destruction of the EKMI TC. Despite voting to continue work on the EKMI TC, the chair of the EKMI TC has opted to call it quits. This person provided the base reference platform upon which the EKMI TC work was based (StrongKey) and provided the leadership that drove the TC forward. Without his leadership, this committee is as good as dead.

And, really, this is probably inevitable anyway. Rather than being required by OASIS to play nicely with others, these vendors behind the KMIP TC have launched what will become their de facto standard for key management. The KMIP standard will be integrated into the myriad key management platforms, allowing each vendor to make a case for their key management product, touting that it will interoperate with other vendors' clients or servers.

It's very disappointing to me that the EKMI TC is going the way it has. It's infuriating to me that the OASIS board has allowed a group of vendors to come in a steal the limelight and override all of the effort that's been put into the EKMI TC. The entire situation is patently unfair and, what's more important, it's wholly unnecessary. If these vendors had engaged the EKMI TC, they would have found a receptive audience for their proposed standard. Their contributions would have been welcomed and eagerly integrated. Moreover, if they were concerned about being led astray, they could have joined the EKMI TC and taken over, voting out the chair and installing their own. For these vendors to have made such a lame and obvious power play belies their greedy motives and shows just how pathetic and weak they really are on the international stage. This is a ploy worthy of Bill Gates and Microsoft - buying or driving out the competition rather than having to compete.

To those individuals and small companies who might consider initiating an OASIS standard, be forewarned! If you have a good idea, fully expect that a major vendor will run roughshod over your TC!

Let's all now take a moment of silence to mourn the inevitable passing of the EKMI TC...

About this Entry

This page contains a single entry by Ben Tomhave published on March 10, 2009 5:49 PM.

Stupidity at BestBuy.com was the previous entry in this blog.

Security in the Comics... is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Monthly Archives

Pages

  • about
Powered by Movable Type 6.3.7