kmip message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: KMIP operations and objects
- From: Bruce Rich <brich@us.ibm.com>
- To: kmip@lists.oasis-open.org
- Date: Wed, 3 Jun 2009 17:44:21 -0500
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]