OASIS Key Management Interoperability Protocol (KMIP) TC

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.

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.

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.

> 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). This is correct for the general case, but as I have stated before, it is not correct for all key types. Here is what NIST SP800-57 Part 1 (revised2 mar08-2007) says: 7.3 States and Transitions for Asymmetric Keys The preceding discussion of key states and transitions applies to both symmetric and asymmetric keys; however, some observations that are specific to asymmetric keys are in order. Asymmetric keys that are or will be certified are in the pre-activation state until certified or until the "not before" date specified in a certificate has passed. The types of transitions for asymmetric keys depend on the key type. Examples of transitions follow: a. A private signature key is not retained in the deactivated state, but transitions immediately to the destroyed state. b. A private signature key transitioning from the active state to the compromised state is not retained in that state, but transitions immediately to the destroyed-compromised state unless retention is required for legal purposes. c. A public signature verification key may transition to the deactivated state at the end of the corresponding private key's cryptoperiod. The public signature verification key enters the compromised state if its integrity becomes suspect. However, public signature verification keys need not be destroyed. d. A public key transport key transitioning from the active state is not retained in the deactivated state, but transitions immediately to the destroyed state. It enters the compromised state only when its integrity is suspect. e. Private and public key agreement keys transitioning from the active state are not retained in the deactivated state, but transition immediately to the destroyed state. Note paragraphs a, d, and e - these keys do immediately transition from the active state to the destroyed state. Regards, John

On 5/11/2015 10:30 AM, John Leiseboer wrote: >> 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). > This is correct for the general case, but as I have stated before, it is not correct for all key types. Here is what NIST SP800-57 Part 1 (revised2 mar08-2007) says: The text you quote (yet again) does not alter the state model at all - it simply indicates that "*transitioning immediately*" to another state should occur - not that the state model is wrong or that the well defined transitions are wrong. The wording of "*not retained*" also makes that clear as well - the state transitions occur - it is simply making it clear that the key does not remain in the (effectively intermediate) state on its journey through multiple state transitions in accordance with the defined state model transitions. The state rules are not violated - the journey just has multiple hops - all of which are allowed and can happen for various reasons for any managed object. You could go from PreActive to Active to Deactivated to Destroyed to Destroyed Compromised without remaining in the states along the way for any length of time. That is indeed a contrived example - but permitted - as long as the state model for allowed transitions is followed. States transitions are not skipped and nothing within the text indicates that (or in any of the previous discussions within the TC or with NIST on the topic). The section you quote is noted as "*some observations*" - it is not about changing requirements or altering the state model - it is about simply *observing *some *examples *of transitions. Those state transitions are clearly defined and fixed both in NIST SP800-57 and in KMIP. Tim.

Classification: Thales e-Security OPEN I had a look and it is either pre-active or deactivated keys that can be transitioned to destroyed as John & Tim state (my goof for not looking). As I said earlier there is nothing stopping a rapid transition from active to deactivated to destroyed as long as the user performs the two state transitions properly as described in the spec. Make sure you reference the current SP800 57 Part 1 as version 3 has been out since 2012. Version 4 is currently a draft and changed the model quite a bit so we will need to watch it. Bob L. On Nov 4, 2015, at 4:58 PM, Tim Hudson <tjh@cryptsoft.com< mailto:tjh@cryptsoft.com >> wrote: On 5/11/2015 10:30 AM, John Leiseboer wrote: 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). This is correct for the general case, but as I have stated before, it is not correct for all key types. Here is what NIST SP800-57 Part 1 (revised2 mar08-2007) says: The text you quote (yet again) does not alter the state model at all - it simply indicates that "*transitioning immediately*" to another state should occur - not that the state model is wrong or that the well defined transitions are wrong. The wording of "*not retained*" also makes that clear as well - the state transitions occur - it is simply making it clear that the key does not remain in the (effectively intermediate) state on its journey through multiple state transitions in accordance with the defined state model transitions. The state rules are not violated - the journey just has multiple hops - all of which are allowed and can happen for various reasons for any managed object. You could go from PreActive to Active to Deactivated to Destroyed to Destroyed Compromised without remaining in the states along the way for any length of time. That is indeed a contrived example - but permitted - as long as the state model for allowed transitions is followed. States transitions are not skipped and nothing within the text indicates that (or in any of the previous discussions within the TC or with NIST on the topic). The section you quote is noted as "*some observations*" - it is not about changing requirements or altering the state model - it is about simply *observing *some *examples *of transitions. Those state transitions are clearly defined and fixed both in NIST SP800-57 and in KMIP. Tim. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php