RE: [kmip] Destroying an Active object

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

Classification: Thales e-Security OPEN


We probably need to revisit the entire state model and our list of states for 1.4 as NIST looks to be making changes in SP800-57 Part 1 Revision 4.  I know feedback has gone in but not sure what will change between the draft and the final version.  SP800-152 release does mention the suspended state and we will need to address that at a minimum.

As for the old state model I know it was possible to move a key directly from Active to Deactivated, Compromised or Destroyed so while it may not be a requirement as per NIST it makes tracking keys a little easier by transitioning them via Deactivated through to Destroyed even if the time of the two transitions are the same time.

I personally believe this should be a vendor specific implementation issue and not a requirement.  But as I mentioned above, due to the potential for the change in the NIST state model, we should "wait and see" which direction they go.

Bob L.
________________________________
From: kmip@lists.oasis-open.org [kmip@lists.oasis-open.org] on behalf of Featherstone, David [David.Featherstone@safenet-inc.com]
Sent: Wednesday, November 04, 2015 08:08
To: kmip@lists.oasis-open.org
Subject: [kmip] Destroying an Active object

Greetings

On a recent KMIP TC call, I recall some expressed opposition to allowing an Active object to be Destroy’d. I’m curious to understand whether the KMIP specification itself does not already allow this behavior [see last sentence of the following paragraph]:

KMIP Specification v1.2:
1608 4.21 Destroy
1609 This operation is used to indicate to the server that the key material for the specified Managed Object
1610 SHALL be destroyed. The meta-data for the key material MAY be retained by the server (e.g., used to
1611 ensure that an expired or revoked private signing key is no longer available). Special authentication and
1612 authorization SHOULD be enforced to perform this request (see [KMIP-UG]). Only the object owner or an
1613 authorized security officer SHOULD be allowed to issue this request. If the Unique Identifier specifies a
1614 Template object, then the object itself, including all meta-data, SHALL be destroyed. Cryptographic
1615 Objects MAY only be destroyed if they are in either Pre-Active or Deactivated state. A Cryptographic
1616 Object in the Active state MAY be destroyed if the server sets the Deactivation date (the state of the
1617 object transitions to Deactivated) to a date that is prior to or equal to the current date before destroying
1618 the object.

Does the above described behavior really differ from that which NIST proposes?

Cheers,
… Dave



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.