Re: [kmip] Destroying an Active object

[Tim Hudson <tjh@cryptsoft.com>]

On 5/11/2015 2:08 AM, Featherstone, David wrote:
>
> 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?
>

That wording is entirely redundant and can be removed without altering
the interpretation. It basically states that to destroy an active object
it has to be deactivated first which is done by setting (or modifying)
the Deactivation Date. It means nothing more than that.

i.e. an object in active state can be destroyed if you first make it
deactivated prior to destroying it.

The NIST model explicitly disallowed moving directly from Active to
Destroyed states - as do conforming KMIP implementations (there are test
cases covering precisely this context).

Tim.