RE: Specification clarification in regard to managed object retrieval

["Lockhart, Robert" <Robert.Lockhart@thalesesec.com>]

Some of the states don't say what is allowed or not allowed and leave a lot up to the client to be well behaved.



A good example of this is a key in process only state.  What it means is that a server can provide the key to the client if it is allowed to normally get it or get it under special circumstances.  What the client does with the key after that is up to the client which may not care about FIPS, common criteria, states or other such things.  A server has little if any control over what a client does with a key once he gets it.  In fact, in most cases today, devices completely ignore state or usage masks and do with the key as they please (most of the storage devices out there come to mind when typing this statement).



There is also a fine line of what is vendor specific and what should be in the specification.  My personal opinion has always been that if a key is in the pre-active state and it leaves the device where generated, it should be put into an active state prior to register or get functions as some clients as mentioned above don't care about key state and that means that in theory that keys could live their entire life in a pre-active state...



Basically this means that a key registered to a server should never be in a pre-active state at all.  The servers can't trace the history of a key beyond whomever registered it unless the key has a lot of metadata associated with it when registered.  Being my jaded self, I think most clients believe that less is more when creating their own keys and then registering them.



It is really up to a vendor to interpret how they want to implement it and we would need to tread lightly here.



I have an old email from the folks (Elaine B.) at NIST during the P1619.3 days on this topic and could dig it out for refresher or we could ask the NIST folks for their opinion since I think some of us are concerned more from a FIPS and CC standpoint than others might be.



Just my pennies worth,


Bob L.

Robert A. (Bob) Lockhart
Chief Solution Architect - Key Management
THALES e-Security, Inc.
________________________________
From: kmip@lists.oasis-open.org [kmip@lists.oasis-open.org] on behalf of Saha, Saikat [Saikat.Saha@safenet-inc.com]
Sent: Thursday, June 27, 2013 09:50
To: kmip@lists.oasis-open.org
Subject: [kmip] Specification clarification in regard to managed object retrieval

KMIP Team,



Section 4.22 of the KMIP spec at http://docs.oasis-open.org/kmip/spec/v1.1/os/kmip-spec-v1.1-os.html#_Toc333494539 doesn’t mention any state restrictions. It’s very unlikely this is an oversight. More likely Get is allowed in any state.



The section 3.22 in the KMIP spec quoted below says "Pre-Active: The object exists but is not yet usable for any cryptographic purpose." Retrieving using Get is not a cryptographic purpose so returning a pre-active key does not violate this. This is reinforced by the text in test 4.1 which says “[being in the compromised state] does not stop a client from being able to add, modify and delete attributes or even get the key (since we assume here that the out-of-band registration has been used to make the server aware of the fact that the client is capable of interpreting the attributes of the key and determining what it is allowed to do with the key).” Emphasis added by me. Therefore it appears it is the client’s responsibility to determine what is allowed to be done with the key based on the attributes returned by the KS/DS.


Test case 3.1.3 at http://docs.oasis-open.org/kmip/testcases/v1.1/cn01/kmip-testcases-v1.1-cn01.html#_Toc333488775 is titled “Test Case: Create / Locate / Get / Destroy”. That sequence of commands is supposed to succeed. Requiring that the Activate command or setting the Activation Date such that the key becomes Active before the Get command is called would cause this test case to fail.


Given above, what is committee members consensus of allowing the “Get” command to retrieve a “Pre-Active” key or Secret Data object?

One view is that precluding Get from retrieving Pre-Active keys does appear to violate spec.
Other view is that why would the KMIP server allow to retrieve a key that is in “Pre-active” state. Some real-life customers have proposed that server should not allow clients to retrieve an object in pre-active state.

Would appreciate some feedback from the committee members.

Regards,
Saikat


The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.