[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [kmip] Destroying an Active object
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]