Bruce, Jay,
I could be in a small minority here, but I believe the sole
minimum/base requirement for client-server interoperability should be a
common messaging protocol, without requiring any specific cryptographic
operations, objects, or attributes. Any particular subset of algorithms,
operations, stuctures, and metadata will apply in a particular usage
domain, but not others. And, accepted cryptographic algorithms and key
sizes will change over time.
If clients can be guaranteed of some minimum server
communication and "query server" capabilities (perhaps at the level
of ,what are the other server-supported profiles), they can easily
determine whether server support for the client's intended use cases is
available. But, if common baseline messaging and server query are not
mandated in the base profile, then even this level of interop is not
guaranteed.
Regards,
Steve Wierenga
HP
From: Bruce Rich [mailto:]
Sent: Tuesday, August 25, 2009 7:48 PM
To:
Jay.Jacobs
Cc:
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"
<>
To:
""
<>
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:]
Sent: Friday, August 21, 2009 10:14 AM
To:
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:
From:
To:
Todd Arnold/Charlotte/IBM@IBMUS,
<>
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
