kmip message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [kmip] Broader View of Conformance
- From: Bruce Rich <brich@us.ibm.com>
- To: "Jay.Jacobs" <Jay.Jacobs@target.com>
- Date: Tue, 25 Aug 2009 21:47:42 -0500
Jay,
My intention in putting out a base symmetric
key profile proposal was to allow us to come up with a minimum subset that
would be "easily" testable and would not set an insurmountable
first hurdle for KMIP enthusiasts. I don't actually know of anyone
that yet has an implementation of the full KMIP specification, so having
an interop between several vendors to prove the "I" in KMIP may
be a ways off if our first step were to be the full protocol. That
said, I can imagine a couple more profiles for symmetric keys, one that
added key wrapping and one that enabled the "ROLE" part of CryptographicParameters,
which may approach the banking scenario to which you referred. But
I don't have the bandwidth to work on those profiles yet. I was hoping
we could get to the full protocol via stepwise implementation and hopefully
we'll be able to arrive at rough consensus on the meaningful increments.
Bruce A Rich
brich at-sign us dot ibm dot com
From:
| "Jay.Jacobs" <Jay.Jacobs@target.com>
|
To:
| "kmip@lists.oasis-open.org"
<kmip@lists.oasis-open.org>
|
Date:
| 08/21/2009 11:21 AM
|
Subject:
| RE: [kmip] Broader View of Conformance |
I can’t say I disagree with
the points being made.
I think it all goes down to the goal of the I in KMIP, how interoperable
do we want to make it? Interoperable in a vertical segment or horizontal
across the enterprise? I think what we are leaning toward the former
at the expense of the latter.
The banking scenario is a
valid use case. I think if we went with one minimum server profile
we may risk imposing a high cost for development and conformance or the
risk of implementations splintering off from the standard. If we
implement multiple profiles we risk having a splintered standard, and multiple
KMIP standards to chose from.
One option is to limit the
profiles to a very small number (2 or 3) with little-or-no option for adding
more (at least in 1.0). I think it would be important to define a
full conformance profile (to the minimum as Todd mentioned) such that no
subset profile will require more (to ensure fully conforming servers support
all sub-profiles). This may be improved with defining two classes
of conformance being “full conformance” and the rest being “profile
conformance”, so that the consumers are very aware of their purchase.
To the comment about switching
over from one KMIP Server to another, I agree with the challenges in server
specific designs and I’ll add that corporate inertia may also go against
changing out functioning solutions.
Thanks,
Jay Jacobs
From: Todd Arnold [mailto:arnoldt@us.ibm.com]
Sent: Friday, August 21, 2009 10:14 AM
To: kmip@lists.oasis-open.org
Subject: RE: [kmip] Broader View of Conformance
The other very important point to this is that since we have a standard
defining how KMIP works, people should be able to switch from one KMIP
server product to another if they need additional functionality.
Of course, the caveat here is that our KMIP spec leaves a lot of things
up to the server designer, so they might be different in different implementations.
(For example, there are several things noted in the spec and user
guide as "outside the scope", such as registration of the client
with the server.)
-------------------------------------------------------------------
Todd W. Arnold, STSM
IBM Cryptographic Technology Development
(704) 594-8253 FAX 594-8336
-------------------------------------------------------------------
email: arnoldt@us.ibm.com
From:
| David.Lawson@Emulex.Com
|
To:
| Todd Arnold/Charlotte/IBM@IBMUS, <kmip@lists.oasis-open.org>
|
Date:
| 08/21/2009 10:55 AM
|
Subject:
| RE: [kmip] Broader View of Conformance |
Requiring all KMIP compliant servers to implement most of the KMIP specification
would raise the costs of the users requiring only a single subset of KMIP
for their application. Allowing targeted profiles to support the lower
cost, targeted servers, does not necessarily mean there will be a multitude
of KMIP servers required. If a user requires support of a single profile,
a KMIP compliant server can be purchased that supports just the one profile.
If the user wishes to have a more general purpose KMIP server, he can purchase
a server that supports multiple profiles, approaching the server that supports
most of the KMIP specification.
The user who requires, or might require in the future, can purchase the
KMIP server that provides support for multiple profiles, or that can be
upgraded to support multiple profiles at a later time. This would prevent
the problem of having one key server for each purpose.
David Lawson
Emulex Corporation
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]