OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [kmip] Groups - State Model Update uploaded

Classification: Thales e-Security OPEN

We can add the other state transitions but I used the diagram from NIST in SP800-130 Draft 1 (June 2010).  I did add one transition from revoked to compromised but there is an actual use case for it so I included it.

The reality is that if we keep it logical and the transitions only to what is required in most cases you can pass through two transitions to get from current state (A) via a middle state (B) to the desired state (C).  The state transition times for B & C would be the same which seems to be a valid way to do it and keeps the model neat and tidy.  It's one of those cases where less could really be more in my little world at least.

I only proposed one state for shredded as in theory, the object no longer exists in any way shape or form, meaning that as far as key management goes it never existed.  However having said that, you would hopefully still have log information for the auditor types that required to know all about it for some number of years after the fact.

The suspended state didn't have a compromised transition in the NIST draft so I left it off.  I look at suspended as a way to keep a key from being served usually based on time of day/day of week reasons and that the key object and data in question are known to have been in a controlled environment the entire time.

Again, the only "extra transition" I added was revoked to compromised because there are cases for it.  An example is a tape cartridge that fell off the back of the truck and was thought lost but shows up in a box that was later sent to the off site storage.  You don't know for sure it was not removed for the shipment it was supposed to be in and put back in a later one or if it just didn't make it out of the library when it should have (that could never happen though... - I can name three very public, very expensive events that fall into that use case).

Lets discuss more on the call.

Bob L.

Robert A. (Bob) Lockhart
Chief Solution Architect - Key Management
THALES e-Security, Inc.
From: Tim Hudson [tjh@cryptsoft.com]
Sent: Thursday, May 08, 2014 12:44
To: Lockhart, Robert
Cc: kmip@lists.oasis-open.org
Subject: Re: [kmip] Groups - State Model Update uploaded

Initial comments.

The current NIST state model explicitly handles all non-active states
being able to proceed immediately to compromised.
If you can go from Pre-Active to compromised then why not Pre-Active to
If you provide Pre-Active to Shredded then Deactivated to Shredded.
Shredded seems to be better modelled as Destroyed Shredded and Destroyed
Compromised Shredded - forcing transition through the existing Destroyed
state rather than introducing a new direct state approach.
You also don't allow for Suspend to go to Compromised - all other states
allow a Compromised (or Destroyed Compromised) direct transition.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]