RE: [ekmi] [Fwd: KMIP TC Charter]

[Shahid Sharif <Shahid.Sharif@telus.com>]

Check out this news article regarding KMIP: http://www.bizjournals.com/boston/stories/2009/02/09/daily48.html 

-----Original Message-----
From: Arshad Noor [mailto:arshad.noor@strongauth.com] 
Sent: Tuesday, February 17, 2009 9:21 AM
To: ekmi
Subject: [ekmi] [Fwd: KMIP TC Charter]

I realized that it would be very difficult to conduct normal business in the EKMI TC as long as we have this "elephant" in the sitting room.

With this posting, I have made my position clear and believe that the KMIP TC charter is to the detriment of the EKMI TC's work - and to OASIS itself if this TC moves forward with the current charter.

I propose that we discuss this in this morning's TC meeting and the impact the KMIP TC has on our work.  For those who are in a position to publicly take a position on it, please do so on the oasis-charter-discuss@lists.oasis-open.org list.
You have until February 26th 11:45pm EST to do so.

Thanks.

Arshad

-------- Original Message --------
Subject: KMIP TC Charter
Date: Tue, 17 Feb 2009 06:14:45 -0800
From: Arshad Noor <arshad.noor@strongauth.com>
Organization: StrongAuth, Inc.
To: oasis-charter-discuss@lists.oasis-open.org

It is the position of this OASIS member that the creation of the Key Management Interoperability Protocol (KMIP) Technical Committee (TC) overlaps the charter of the Enterprise Key Management Infrastructure
(EKMI) TC to a degree that it will undermine the work of the EKMI TC completed over the last two years, and sow significant confusion in the marketplace.

Based on the list of sponsors of the KMIP TC, it appears that this is a splinter group that has broken off away the IEEE 1619.3 Working Group to build a key-management protocol for storage devices.  While the proposed KMIP TC charter claims - like the IEEE 1619.3 WG did - that their protocol may be used for users, network-devices, databases, applications and other non-storage devices, the makeup of the group of sponsors appears to indicate that the primary focus will continue to be on encrypting data in storage devices.

The proposed KMIP TC charter states:

"Similar work is currently underway in several other organizations:
* OASIS EKMI TC. We see KMIP TC as addressing a broader scope than the primarily symmetric key focused EKMI, providing a more comprehensive protocol in which SKSML can potentially participate."

However, it neglects to mention what short-comings of the EKMI TC's work and/or focus requires the creation of another TC within OASIS that overlaps the EKMI TC's work.  The EKMI TC has clearly indicated in its charter, presentations, writings, documentation and e-mails, that:

* An EKMI consists of a Public Key Infrastructure (PKI) and a Symmetric
   Key Management System (SKMS), which by definition includes all their
   related protocols, technology and practices;

* Given the body of work created by the IETF PKIX which serves the PKI
   industry, the EKMI TC initially intended to focus on the creation of
   symmetric data-encryption key-management standards (which neither
   prevents customers from using PKI protocols, nor duplicates anything
   they may have done or will do with respect to digital certificates
   and asymmetric key-management);

* When the Symmetric Key Services Markup Language (SKSML) becomes an
   OASIS standard, the EKMI TC will take up the work of merging SKSML
   with PKI-related protocols by following the same principles it used
   in creating SKSML - leverage all previous useful protocols and not
   duplicate anything;

Yet, the KMIP TC charter neither lists any short-comings in the SKSML nor explains how SKSML fails to secure an enterprise's sensitive data or manage data-encryption keys, effectively.  Stating that KMIP will provide "a more comprehensive protocol in which SKSML can potentially participate" without listing SKSML's deficiencies is a disingenuous way of sowing fear, uncertainty and doubt in the key-management market.

The KMIP TC charter fails to explain how KMIP can lower the Total Cost of Ownership (TCO) of an enterprise considering that every single device currently deployed today - be it storage, network or a personal device with embedded storage - is incapable of using KMIP today or for the next year for that matter.  All such devices will need to be replaced at a capital cost of tens of billions of dollars to use KMIP, and can potentially take upto 3-5 years to secure data.  SKSML, on the other hand, is capable of securing data on the vast majority of applications and platforms *today*, on
*existing* storage devices, *existing* networking devices and/or
*existing* personal devices with embedded storage.

The KMIP TC charter fails to provide any proof that their protocol is reasonably and cost-efficiently implementable and/or workable.
The EKMI TC's SKSML has had an open-source, reference implementation of an early DRAFT since 2006, and has already proven the protocol to be implementable and workable.  It has been downloaded nearly 2,000 times over this period, and a community of users has already developed around this open-source work.  One of those community members had this to say about this early implementation of SKSML:

"Looking forward to next build to have a go at it, very impressive piece of work".

The EKMI TC, recognizing that certain devices are at a disadvantage in processing the XML in SKSML, has created a sub-committee to explore the creation of a "Mobile SKSML" profile to serve the needs of "low-power, low-bandwidth" devices.  This sub-committee will begin its work shortly and is anticipated to have its work completed before the end of calendar 2009.  The KMIP TC charter makes no reference to this effort and the overlap their charter has with this sub-committee's work.

Recognizing the importance of business compliance to regulatory and contractual requirements, the EKMI TC has explicitly called for creating EKMI Implementation, Operations and Audit Guidelines in its charter.  The TC has already created DRAFT documents to this effect, reached out to international audit associations and professional IT Security auditors to define guidelines that meet the spirit and intent of data-security laws.  The KMIP TC charter neglects to describe how its protocol will be implemented within applications, used, operated and audited to meet regulatory requirements.

EKMI has been written up in technical journals (ACM proceedings), information technology magazines (Information Week, ISSA Journal) and business-related journals (ABA SciTech Journal).  It has been presented around the world in England, Germany, India, Poland, Singapore and Spain besides the USA.  It has articulated a vision that the only long-term data security is to encrypt data within applications, thereby creating end-to-end security.  This vision is even endorsed by the CEO of Heartland Payment Systems (the company that potentially suffered the largest data-breach in the
industry) as recently as last week.  The EKMI TC has focused on this message so sharply that SKSML is well on its way towards a tipping point in having that vision understood.

Given the above, OASIS will be doing the industry - and its EKMI TC members who have laboured for over two years on this effort - a huge disservice by convening and creating the KMIP TC with its current charter.  The proposed TC charter needs to clearly explain why the EKMI TC is an inappropriate forum for this work, how it expects to differentiate itself from EKMI TC, what benefits does that differentiation provide the industry and how it expects to avoid confusing the market.  In the absence of addressing these questions, OASIS runs the risk of being accused of serving the needs of its deep-pocketed vendor sponsors, rather than the IT industry at large, thereby impugning the credibility of the standards organization itself.

Arshad Noor
StrongAuth, Inc.
(Chair, EKMI TC)







---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php