RE: [kmip] Groups - KMIP-SP800-130-152.pdf uploaded

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

That actually is a good use case for suspended state and return to activation transition.  The use case I mentioned below for the tape falling off the back of the truck and then turning up in the library is not uncommon and it is a good use case for symmetric keys and the revoked state.  When the tape is "magically found" two weeks later, the use case for Revoked (or what we call disabled) comes into play such that the key isn't returned to full service but a deactivated state for verification of what is on the tape because you never have duplicate bar codes occur (the tape storage folks will get this one).  So basically I would like to see both states and their associated transitions date/times put into the KMIP model.

I have a slide that has the eight states on it based on the one that was in the first draft of SP800-130 from NIST if it is needed during the face to face. 

Bob L.

Robert A. (Bob) Lockhart
Chief Solutions Architect - Key Management
Thales e-Security,Inc

-----Original Message-----
From: Chuck White [mailto:cwhite@semper-fortis.com] 
Sent: Wednesday, February 19, 2014 1:38 PM
To: Lockhart, Robert; Furlong, Judith
Cc: kmip@lists.oasis-open.org
Subject: RE: [kmip] Groups - KMIP-SP800-130-152.pdf uploaded

Howdy Bob!

It really has value when you see KMIP being applied to things that are used to communicate with each other. In some cases you just want to put the key on hold vs straight out revoking it. One use case is keys loaded on a satellite on processes of what you do in light of key lifecycle on a bird. Current approach has every key the satellite will ever have loaded at launch. Industry wants to change- but in the spirit of "make before break" giving them options to retire a key(ie suspend) vs revoke a key will bode well with those folks- this is just one example. 

From a NIST perspective, I'm thinking that they are looking a broad use of CKMS and they want to support applications, communications, and storage. What is cool about KMIP is that it can do all of that - the last mile is things like Security Attributes and adding an additional state to align the KMIP spec with what NIST is looking for.  As a relative newbie\convert to KMIP - it is pretty cool to see it starting from this position. 

See y'all tomorrow. 

Thanks!

Chuck


Charles White
Semper Fortis Solutions, LLC


This message contains information from Semper Fortis Solutions, LLC which may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited.

-----Original Message-----
From: Lockhart, Robert [mailto:Robert.Lockhart@thalesesec.com] 
Sent: Tuesday, February 18, 2014 8:09 PM
To: Furlong, Judith
Cc: Chuck White; kmip@lists.oasis-open.org
Subject: Re: [kmip] Groups - KMIP-SP800-130-152.pdf uploaded

My concern is that NIST appears to be looking to update the SP800-57 Part 1 state model to include revoke, suspend and return to activation.  The are also calling out these states in the Second Draft of SP800-152.

It would be nice to consider at least the addition of the states to KMIP or as other attributes at a minimum so that they may be used by key owners without requiring server vendors getting in the way if NIST or someone else has a need.

As for use cases there are potential use cases for these states for not just certificates but symmetric keys as well (e.g. Tape falls off the back of a truck but is found in the library two weeks later - real world use case that I have seen three or four times before).

Robert A. (Bob) Lockhart
Chief Solutions Architect - Key Management Thales e-Security, Inc.


On Feb 18, 2014, at 1:39 PM, "Furlong, Judith" <judith.furlong@emc.com<mailto:judith.furlong@emc.com>> wrote:

Chuck

In Slide 7, last bullet you suggest adding new operations for Suspend/Re-activate and associated date attributes

Instead of adding new operations one could leverage the Revoke operation to support this - We deferred support of the certificateHold and removeFromCRL revocation reasons from current KMIP versions mainly because we didn't see folks using KMIP to support the suspending/unsuspending of public key certificates.  But SP800-130 support could be used as justification for adding the certificateHold and removeFromCRL options to the revocation reason enumerations.

If we leverage the Revoke operation in this way you could also leverage the existing Compromise Date to handle when the key was Suspended.  This assume folks are not bothered by using an attribute named 'compromise' for something which is 'suspended'. A new attribute to track when the key was reactivated would still need to be added - assuming you don't want to overload Activation Date.

Judy

From: kmip@lists.oasis-open.org<mailto:kmip@lists.oasis-open.org> [mailto:kmip@lists.oasis-open.org] On Behalf Of Charles White
Sent: Thursday, February 13, 2014 7:49 AM
To: kmip@lists.oasis-open.org<mailto:kmip@lists.oasis-open.org>
Subject: [kmip] Groups - KMIP-SP800-130-152.pdf uploaded

Submitter's message
Good morning/evening KMIP TC!

KMIP-SP800-130-152.pdf provides an overview of how NIST guidelines for Cryptographic Key Management Systems impact KMIP. Also this presentation provides options for further alignment of KMIP to NIST standards. Note there is a corresponding spreadsheet - NIST-KMIP CR.xlsx that documents the relationship between the collective set of standards.

Thanks!

Chuck
-- Charles White
Document Name: KMIP-SP800-130-152.pdf<https://www.oasis-open.org/apps/org/workgroup/kmip/document.php?document_id=52201>
________________________________
Description
Review of NIST SP800-130 and NIST SP800-152. Discussing options to update KMIP 1.3 to align with NIST guidance. Note that there is a corresponding spreadsheet - NIST KMIP CR.xlsx Download Latest Revision<https://www.oasis-open.org/apps/org/workgroup/kmip/download.php/52201/latest/KMIP-SP800-130-152.pdf>
Public Download Link<https://www.oasis-open.org/committees/document.php?document_id=52201&wg_abbrev=kmip>
________________________________
Submitter: Charles White
Group: OASIS Key Management Interoperability Protocol (KMIP) TC
Folder: Drafts
Date submitted: 2014-02-13 04:48:46