atom feed4 messages in org.oasis-open.lists.kmip[kmip] KMIP operations and objects
FromSent OnAttachments
Bruce RichJun 3, 2009 3:43 pm 
Rod WidemanJun 10, 2009 7:39 am 
Robert HaasJun 25, 2009 6:25 am 
Rod WidemanJun 25, 2009 7:49 am 
Subject:[kmip] KMIP operations and objects
From:Bruce Rich (bri@us.ibm.com)
Date:Jun 3, 2009 3:43:58 pm
List:org.oasis-open.lists.kmip

Before we close down discussion of modifications to KMIP v1 and given the fact that the compliance discussion for KMIP is lagging a bit, I would like to enter the following proposal:

If we were to move the following objects to optional SecretData OpaqueObject and the following operations to optional DeriveKey Archive Recover Get with WrappingSpecification then we more or less have in place what was deemed adequate for the proof of concept (POC) implementations.

Then complying with this newly-coined, limited set of required objects and operations could be more or less a "Basic Profile".

Complying with the full set of required and optional objects and operations could be an "Advanced Profile". (And there may be several steps between basic and advanced, but I am most interested in "Basic", at least for now.)

(NB. Archive and Recover were part of the POC, but are adding states outside of those defined in the NIST state model, and it may be useful to be able to exclude those from an entry-level model) (NB. Given transport security, one can argue that the WrappingSpecifications are not absolutely necessary for an entry-level model) (NB, Strictly speaking, ALL of the KMIP objects seem to be optional, since the Query Objects response need not have any objects listed, but I wanted to emphasize that a very useable first-step KMIP implementation could be had without supporting SecretData and OpaqueObject)

I apologize if this is viewed as overly controversial, but I'm reluctant to end discussion about KMIP v1 content without some closure on the compliance/profile discussion.

Bruce A Rich brich at-sign us dot ibm dot com