The hard part of a key management standard

From a high level, a key management system only does a few things: it creates and manages cryptographic keys as well as the policies that govern their use. Defining exactly what keys are is fairly simple. Defining exactly what a policy is, on the other hand, can be fairly difficult, and defining a way to define policies is probably one of the most difficult parts of writing a useful key management standard. This is needed to guarantee interoperability between products from different vendors, so this is of more than just academic interest, at least to people trying to define standards for key management technologies. This is something that we'll probably have to address in the IEEE P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data, for example.

Some parts of a policy are fairly straightforward. Defining a validity period for a key is easy. It's even fairly easy to extend this idea to define how to allow keys to only be used certain ways at certain times. You might want to issue a key that only can be used to encrypt for the next 90 days, but can still be used to decrypt after that, and it's not hard to define a syntax for policies that can describe this particular case.

Users of encryption sometimes have rather unusual things that they want to include in a policy. One of the speakers at last week's Key Management Summit mentioned that he has a customer that needs to control the use of a key based on the geographical location of the user as defined by the output of a GPS system. An example of this might be that a key can only be issued to a user if the user is within 1 mile of (34º32'30''N, 115º47'30''W).

But while almost every key policy will need to define time periods of validity for keys, very few will probably need to define the geographic region in which keys can be used. So what we'll probably end up with a set of mandatory policy elements that all standards-compliant products can define and understand, plus a way for users to add additional optional policy elements to cover the rarer cases. Time periods of validity will probably be mandatory to implement while the location of a user will probably be one of the optional elements.