[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SKSML Specification Question
|
Forgive me if I am seen as, “rocking the boat,” but I do need some clarification on the current SKSML specification. I do see how the current specification could be employed to implement a network enabled symmetric key management architecture, but I am concerned about the lack of information about the client application or device as seem from the SKS.
The vision as described by the OASIS TC assumes the existence of a variety of traditional and non-traditional applications and devices scattered about within an enterprise all capable of cryptography and therefore all needing an integrated key management solution. The proposed architectural solution from the TC involves the client-server model enabled by a standardized protocol for requesting and delivering key materials.
Clearly the proposed SKSML specification delivers such a protocol, but what I am concerned about is how well the server will scale based upon the proposed specification. To get right to the point, what I see as missing from an SKS server standpoint is the ability to intelligently create and maintain policy-based key pools at the server where different pools or types of pools have different characteristics based upon how the key is used by the application requesting the key.
Take a simple scenario where I have a need to encrypt at-rest data on backup tape devices and ensure that the keys are retained for 10-years from their last use in encrypting data, and I have a second need like the one Arshad mentioned during the June meeting where I want to encrypt browser cookies across every desktop and laptop in my enterprise (say 60,000). Clearly from a server perspective I probably do not need to keep the key used to encrypt cookies for 10-years, and with 60,000 desktops and laptops running browsers and requesting new keys on a regular basis this could result in millions of keys being retained at the server way beyond their usefulness.
Now I could define key classes on the server and establish policies for how to manage the keys based upon the key class, but that means that for every application or device I want to bring on-line and manage in unique ways I will need to define a new key class at the server and every instance of that application or device would need to be configured to request keys from that key class.
What I was hoping to see in terms of an EKMI specification was one which supported plug-and-play as well as customized configurations. To be plug-and-play, I believe the standard needs to also contemplate standardized protocol elements and values to place client applications and devices into a finite series of classifications. And so backup applications and/or devices could be easily identified as such by the SKS server and a policy at the server could associate all backup applications and devices with a specific key class (key pool with common management characteristics). A web browser would also have a assigned value that was part of the SKSML specification, which again would allow the SKS server to properly classify the client application and assign the proper key class without having to configure anything outside of the SKS server (plug-and-play). The SKSML already allows an application to request a key from a specific key class, so the flexibility is there to customize applications and SKS policies could choose to honor keys from specific classes or could decide to ignore the key class requested by the application and based upon other controlling SKS server policies and the application’s “classification” the SKS server would decide upon the proper key class. SKS server policies could also be written to combine information based upon the application’s or device’s classification with information from the CN of its X.509 certificate and/or it’s requested key class to provide a more granular set of managed key classes. But if the SKS server is not provided with some sort of information that would allow the server to classify the type of application or device, then plug-and-play becomes very difficult without treating all keys as equals in terms of retention, access and caching policies.
In the interest of plug-and-play, I also believe it is necessary for the SKSML to allow the client to request a key for a specific algorithm in a strength that is supported by the client application. Of course, one implementation would be to have key classes associated with specific algorithms and key strengths but if we are to enable industry-wide plug-and-play then the SKSML should establish standardized key classes that are part of the specification and must therefore be supported by any SKS server implementation.
To achieve some of this application and device awareness at the SKS server, the key class is one possibility or this information could be passed via the CN information of the X.509 certificate, but either way if the values to classify the generic types of applications and devices as well as the algorithms supported by the client are not industry standardized values then I do not see how this could foster a plug-and-play key management capability.
Where have I gone wrong?
Tim Bruce
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]