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
From: Todd Arnold
[mailto:arnoldt@us.ibm.com]
Sent: Friday, August 21, 2009 9:43 AM
To: kmip@lists.oasis-open.org
Subject: Re: [kmip] Broader View of Conformance
I tend to
disagree. I think that's because we have different views of how KMIP
might be provided in products.
I think the
conformance requirement might want to specify the minimum set of things we
thing all KMIP servers should support, and not the maximum set.
Consider this
scenario, which I think is very different from what you have in mind.
Instead of a general-purpose server with software implementing KMIP,
let's say my company wants to support KMIP for a specific application, and I
want to provide that support in a special-purpose piece of secure hardware.
A good example is the use of KMIP to support key management for a banking
application, where I would implement the necessary KMIP features in a secure
HSM instead of doing it in software in a general-purpose server. Doing
KMIP in a special-purpose hardware device like this is "hard", and
implementing and testing the full set if KMIP functionality would be very
expensive. If I know that the clients that will be using my device to
serve keys are very limited in their requirements, I can afford to do this
development - but if the KMIP standard makes it mandatory that I also implement
and test all the many, many other KMIP functions that I know my clients will
never use, it will probably make the job too expensive and I'll probably decide
not to implement KMIP at all. I don't think that is what we want - I
think we want to define KMIP so that it will be as attractive as possible to
the maximum number of people. We want to write this so that everyone will
be excited and will see how it can be used in their environment, whether that
environment is general-purpose or special-purpose. In view of that, the
minimum set of required features might be those things that are necessary for a
client to figure out if KMIP suits their needs or not.
In your example
scenario, you suggest that there could be a proliferation of different KMIP
servers with different capabilities. I'm not sure I agree, unless there
are real reasons to have those separate implementations. I think what
might be more likely is that people would switch from a limited-function KMIP
server to a broader-function KMIP server that is a superset of what they had
when they only needed simpler functions. I think vendors who develop KMIP
servers might go one of two ways - they might just do the whole thing, which
would let people start off with something that would meet most of their needs
now and in the future, or they might offer a basic KMIP server for one price
and then offer enhanced versions at extra cost (maybe even "plug-ins"
to add KMIP functionality).
Just my
views...
-------------------------------------------------------------------
Todd W. Arnold, STSM
IBM Cryptographic Technology Development
(704) 594-8253 FAX 594-8336
-------------------------------------------------------------------
email: arnoldt@us.ibm.com
From:
|
"Jay.Jacobs"
<Jay.Jacobs@target.com>
|
To:
|
"kmip@lists.oasis-open.org"
<kmip@lists.oasis-open.org>
|
Date:
|
08/21/2009
10:23 AM
|
Subject:
|
[kmip]
Broader View of Conformance
|
I wanted to
re-iterate what I talked about on the last conference call in looking at
conformance at a higher level. I have a concern that multiple server
profiles will fragment adoption and increase the complexity and/or frailty of
interoperability.
Here’s
the scenario I’d like to avoid. Say I purchase a KMIP conforming
server for tape devices, then later purchase/upgrade some client product that
also claims “KMIP Conformance” but the new client needs a different
profile from the server, so I get a second key management server. After a
few iterations I may end up with several KMIP implementations across the
enterprise (compounded by any added features from vendor extensions). The
end result is that my key management now looks like the picture of what KMIP is
trying to solve: isolated key management instances that can only support a
fraction of the clients in my network.
Here’s
what I would propose, a single KMIP profile for servers, that should support
whatever client gets thrown at it. This makes the server interchangeable
in the network. It will be more work to create a KMIP Server, but there
shouldn’t be many of them in an enterprise anyway. The clients are
compliant only in the requests they choose to make. If a client
won’t ever request asymmetric keys, they wouldn’t have a need to
support it and it would still be conforming to the standard.
Thanks,
Jay Jacobs