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

Principal Software Architect, Development 

5465 Legacy Drive 

Plano, Tx.  75024 

tel:  214-473-1917 

fax:  214-473-1069