KMIP ubiquity vs KMIP conformance

[Bruce Rich <brich@us.ibm.com>]

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