Hi Catherine,
Does your customer want this behaviour for just the Secret Data Object, or also for other cryptographic objects such as symmetric keys, public keys, private keys, certificates, etc?
If so, why should a Secret Data object be treated differently to other objects in this respect? This is a valid question to ask, and there may actually be valid reasons for specifying different rules for different types of cryptographic objects. In the absence
of such reasons however, I believe that the current behaviour is correct.
The intent of the standard is clear: clients are required to enforce the correct usage of keys (and by extension Secret Data objects, which although not necessarily keys, are in the
same class as keys; i.e. cryptographic objects). There are certain state transition rules that the server is required to enforce, and certain operations that are forbidden by the server when cryptographic objects are in certain states; e.g. an active key must
not be destroyed by the server. The rest is up to the client, but...
Unfortunately, neither the standard nor the profiles actually state that the client - not the server - is responsible for this. But the intent is clearly spelled out in the Usage Guide.
Quote from 1.1 Usage Guide below.
"2.1 Island of Trust"
"Clients may be provided key material by the server, but they only use that keying material for the purposes explicitly listed in the delivery payload.
Clients that ignore these instructions and use the keys in ways not explicitly allowed by the server are non-compliant. There is no requirement for the key management system, however, to enforce this behavior."
Although this more readily applies to usage of keys (like encrypt, sign, MAC, etc.), I believe that it also must extend to the client enforcing the rules on usage w.r.t. state; e.g.
an inactive key must not be used except to perform proof of possession, or key confirmation - it must not be used for cryptographic purposes.
The NIST SP 800-57 Part 1 key management guidelines document also allows inactive keys to be delivered by a key management system to clients of the system. 800-57 Part 1 does not define
a Secret Data object, but in the KMIP context, it should be treated like a key as far as states and state transitions are concerned (in my opinion).
I’m willing to consider supporting changes to KMIP to support different rules with respect to object state for different objects, but I think we need to understand the use cases and
reasons for this.
Regards,
John
From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org]
On Behalf Of Ying, Catherine
Sent: Thursday, 31 October 2013 8:20 PM
To: kmip@lists.oasis-open.org
Subject: [kmip] Question on Secret Data retrieval while the object is not in Active state
Hi,
We have a customer that uses KMIP to communicate with our SafeNet KeySecure server. Recently they raised the request to block the Secret Data object from being retrieved from the server unless the object is in Active
state. We have explained to them that it is a violation of the KMIP spec 1.1 in section 4.11. Currently Get command returns the Managed Object specified by the Unique Identifier, regardless of its state. Secret Data is one of the Managed Object types. However,
they strongly request that KeySecure server implements the Get behavior as they desired. We have to raise this to the KMIP committee.
My question is, have any similar requests been raised by other KMIP customers before? If they have, what’s the guideline on handling such out-of-band customer request? If not, I would like to hear your opinions on this
request.
Thanks a lot!
Catherine
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.