Bruce,
Having multiple [symmetric] profiles raises concerns . If
conformance is the minimum to meet and we’re creating multiple minimums, doesn’t
it always go down to the lowest common denominator? How would the average consumer
(or non-KM vendor) understand this and work with multiple minimums?
For example, if we create this first symmetric profile, then one
supporting key wrapping and another ROLE profile, the KMIP server vendors would
have to track all of these profiles and have the matrix of what profiles are
supported and what isn’t. If the consumer wants to add a client they have to
pull the conformance matrix for the server and compare to what the client
claims conformance to. This gets even more complicated when a client supports
two or more profiles now to support its functionality (we go back to talks of
upgrading the server). Would the profiles be in a hierarchy? Could we assign
some ordinal numbers to them such that a number “5” supports all profiles with
a “4” or lower? (this makes adding profiles later very difficult since it
would affect up the scale).
I’m just worried that if we fracture the standard into multiple
profiles that we’d end up with the same effect as having multiple standards. I’d
really like to feel comfortable that KMIP won’t end up there.
I hadn’t even considered the amount of work to test prototypes, and
as I think about it, it’s not a negligible point. But I think we’d see more
benefit focusing on the long term impact than the impact of the roll out.
Thanks,
Jay
From: Bruce Rich
[mailto:brich@us.ibm.com]
Sent: Tuesday, August 25, 2009 9:48 PM
To: Jay.Jacobs
Cc: kmip@lists.oasis-open.org
Subject: RE: [kmip] Broader View of Conformance
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