Key management at the RSA Conference
There are lots of free copies of the latest issue of InformationWeek magazine floating around at this week's RSA Conference. I picked one of these up and looked at it because of the article that was featured on the cover: “Standards Matter.” Here's an interesting quote from this article:
If we’re not careful, standards for nascent technologies could be so splintered as to be worse than none at all.
This reminded me that the first meeting of the OASIS Key Management Interoperability Protocol (KMIP) Technical Committee is going to be this Friday. KMIP is probably the best example that you can think of for splintering standards that might turn out to be worse than none at all. The IEEE Security in Storage Working Group (SISWG) is already well underway with the P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data. The most recent project plan that I’ve seen for this standard shows it being completed late this year. SISWG plans to define two versions of its key management protocol in the P1619.3 standard: one that’s XML-based and another that’s TLV-based.
Oddly enough, an XML version and a TLV version also seems to be the plan for KMIP, which certainly should make you wonder exactly why KMIP is really needed. I seem to recall that the whole point of developing a standard for key management was to ensure interoperability between products from different vendors, and having two different standards for the same thing seems like the worst possible way to do this.
It certainly looks like IBM is responsible for the splintering into multiple and non-interoperable key management standards that the InformationWeek article talks about. They’re really the one behind the KMIP effort, even though they’re also involved in SISWG. It would be interesting to hear what their reason for essentially killing the possibility of interoperable key management was. Didn’t they like the direction that P1619.3 was moving in? If that’s the case, why didn’t they just speak up and make their opinion known? And do they really think that having two non-interoperable key management standards benefits anyone?
These questions shouldn't just be on a security vendor's blog; they're the sorts of questions that IBM's customers should be asking them. Maybe IBM has a good reason for starting KMIP, even though there seems to be a standard well underway that solves the same problem that KMIP does. If that's the case, then they certainly deserve support from those who will benefit from KMIP, which includes many security vendors and their customers. If they don't have a compelling reason, however, their customers should clearly explain to them that they want interoperable key management that they can use enterprise wide, and that the vendor community should act accordingly.
Another part of the InformationWeek article that caught my eye was this:
Technology must be developed and deployed with live customers before functionality can be standardized.
This is also relevant to the development of key management standards. Many vendors have shipping key management products. As I mentioned in an earlier post, the recent Burton Group report on enterprise key management seemed to indicate that only a few vendors (Voltage, RSA/EMC, nCipher, NetApp and SafeNet) have much experience in developing key management products that do much more than manage keys for their other products.
If this assessment is right, you might wonder how useful IBM’s thoughts on how to do key management will be. Their approach may be great for managing keys that IBM products need, but they may not be as useful for a general-purpose key management standard. It will be interesting to follow the development of KMIP to see if this turns out to be true or not.