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:
- 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.
- 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