Re: [kmip] Broader View of Conformance

[Todd Arnold <arnoldt@us.ibm.com>]

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