Howdy Judy! I agree with the idea of looking at certificateHold and removeFromCRL as possible commands associated with certificates. That being said the idea of suspending and restoring a key (symmetric, asymmetric, or otherwise) has value for KMIP as we see the specification being utilized in other things like communications systems. I suspect the folks from NIST will want some definitive lines in attributes. After digesting both SPs my first thought is that the folks who wrote those publications would take issue with mixing attributes – yes that means more attributes for better or for worse. But I could be wrong. This is something to bring up at the Key Management working group next month at NIST – I will definitely do that. Fundamentally speaking the code that does the revoke could be utilized (read instantiated for “Suspend”) as it is logically similar – as long as you don’t destroy the key after you revoke it. 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. From: Furlong, Judith [mailto:
judith.furlong@emc.com] Sent: Tuesday, February 18, 2014 4:39 PM To: Chuck White;
kmip@lists.oasis-open.org Subject: RE: [kmip] Groups - KMIP-SP800-130-152.pdf uploaded 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 ] On Behalf Of Charles White Sent: Thursday, February 13, 2014 7:49 AM To:
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 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 Public Download Link Submitter : Charles White Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Drafts Date submitted : 2014-02-13 04:48:46