RE: [kmip] Broader View of Conformance

["Wierenga, Steven" <steve.wierenga@hp.com>]

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:brich@us.ibm.com]
Sent: Tuesday, August 25, 2009 7: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