OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [kmip] KMIP ubiquity vs KMIP conformance


I agree with the argument for ubiquity of KMIP, along with moving additional objects and operations to optional. But in doing so, I’m left with several concerns:

 

  1. We fundamentally end up with a specification where most everything is optional. This is fine, but does nothing to improve interoperability among various implementations. Clients may have only a few required items while servers would probably have more, but we still need to do the basic work to reach an agreement of what those are. The proposal below and the recommendations in Bruce’s previous e-mail seem like a great start. But couldn’t this just as easily be implemented in the form of a single Base Profile?  Once this profile is established, any other desired profiles could be built from the Base Profile by interested parties.

 

  1. Other organizations that will use KMIP (e.g., P1619.3) will want to specify objects and operations that will be used in their particular domain. There needs to be some method of synchronizing changes made to KMIP - as well as usage of KMIP by these other organizations (via extensions) - so that changes don’t result in implementations suddenly becoming obsolete. For this reason, KMIP must have some sort of registration mechanism for profiles and extensions to avoid incompatibility or lots of work.

 

I’d like to propose that we move forward with the ubiquity focus as Bruce has described in his messages by minimizing the number of mandatory objects and operation.  I would further propose that we implement this by way of a Base Profile in V 1. In subsequent versions, we can look at how other profiles and extensions are incorporated, but a base mechanism for managing this issue will be present from the start.

 

-Walt

---
Walt Hubis
Software Architect
Engenio Storage Group

LSI Corporation
5400 Airport Blvd Ste 100
Boulder, Colorado 80301 USA
Phone: (303) 381-4332
Mobile: (303) 641-8528
walt.hubis@lsi.com
http://www.lsi.com


From: Bruce Rich [mailto:brich@us.ibm.com]
Sent: Tuesday, June 16, 2009 12:09 PM
To: kmip@lists.oasis-open.org
Subject: [kmip] KMIP ubiquity vs KMIP conformance

 


TC members,

I was asked to post something on the mailing list to expand somewhat on my remarks on the call of 11 June.  Here goes...

 We tread a fine line when we discuss KMIP conformance, especially in a timeframe when we are trying to establish the viability of the standard.  If I go back and look at the charter for this workgroup (http://www.oasis-open.org/committees/kmip/charter.php), my impression is that the primary goal is initially a broadly useable, interoperable protocol for Key Management.  The protocol is to be broad enough to accommodate a wide variety of different actors, living out a number of potentially disparate roles.  These actors span a range of capability and sophistication, from devices that are rather security-unsavvy to complex entities who know exactly what they want and need from the other actors.  The very fact that the KMIP exchange format is initially a binary format is driven by the desire to enable actors who may not have the processing power or intelligence to handle a more sophisticated XML exchange format.  This desire to support a rich ecosphere of exploiters, customers and casual users is in conflict with the desire to constrain actors to only use the protocol in certain prescribed ways.  If the protocol is to be widely useable, then in the beginning conformance needs to be loosely defined so that we can get broad buy-in from a number of potentially-conflicting constituencies.  The practical implications of such an approach are that we take down barriers to acceptance, by accommodating a wide variety of object types and operations, and having very few required objects or operations.  If we are successful in having the KMIP protocol be expressive enough to handle finely-nuanced exchanges, while also allowing unsophisticated applications to speak, then we enable the ecosystem that was outlined in the charter.

So what might be some implications of a KMIP ubiquity focus?  Well, some of the following might fall out:
1) We might reduce the set of required operations mentioned in the spec (perhaps as indicated in my earlier note).  Minimally, we need to reconcile the set of required operations given that the objects on which they operate are themselves optional.
2) We might consider the needs of a very unsophisticated client by allowing it to ask for a symmetric key without any parameters at all, letting the server pick the algorithm and strength.
3) We might also consider the needs of a highly-security-aware client by NOT allowing the server to override attributes if the client knows exactly what it needs.  This could be as simple as a NO_OVERRIDES flag in the BatchItem header
4) We might adjust the roles in the CryptographicParameters to better accommodate a base set of financial-community adopters (if such a thing is possible in the near-term, else defer to V2).

What then becomes of the desire for KMIP conformance statements?  I'm not sure I have a good answer for that.  How does one obtain order when one has "let a thousand flowers bloom"?  I think that communities will spring up in the KMIP ecosystem that will drive from a rough consensus to a firm agreement about their core sets of functionality (and extension points), and those communities may take the base KMIP specs and codify profiles that constrict the approved actors to only behave in prescribed fashions.  But I think it premature to do that now, at least not in the direct path to standardization of the KMIP protocol.

In the interim, I see the primary activities of the KMIP core group to be the following:
1) establish an expressive core protocol by ensuring that KMIP can address the requirements of a number of potential constituencies (v1)
2) having established a solid base in #1 above, look for additional leverage by providing a higher-level embodiment (e.g., XML) that speaks to an audience that would appreciate an idiom in their vernacular (v2)

Bruce A Rich
brich at-sign us dot ibm dot com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]