The OASIS Key Management Interoperability Protocol (KMIP) TC has submitted the following specification, which is an approved Committee Specification, to be considered as an OASIS Standard:
The text of the TC submission is appended.
You now have through 15 September to familiarize yourself with the submission and provide input to your organization's voting representative.
On 16 September, a Call For Vote will be issued to all Voting Representatives of OASIS member organizations. They will have until the last day of September, inclusive, to cast their ballots on whether this Committee Specification should be approved as an OASIS Standard or not.
In accordance with the OASIS Technical Committee Process, this Committee Specification has already completed the necessary 60-day public review period as noted in the submission below.
The normative TC Process for approval of Committee Specifications as OASIS Standards is found at:
Your participation in the review and balloting process is greatly appreciated.
(a) Links to the approved Committee Specification in the TC's document repository, and any appropriate supplemental documentation for the specification, both of which must be written using the OASIS templates.
We are requesting submission of the following KMIP V1.0 Committee Specification to the Membership of OASIS for considerations as an OASIS standard:
(b) The editable version of all files that are part of the Committee Specification;
The editable versions of the above documents are available at:
(c) Certification by the TC that all schema and XML instances included in the specification, whether by inclusion or reference, including fragments of such, are well formed, and that all expressions are valid;
The KMIP co-chairs certify that the KMIP V1.0 Profiles document includes expression of message format and contents; all instances of such expressions included in the specification, whether by inclusion or reference, including fragments of such, are well formed and valid. KMIP V1.0 does not include schema or XML expressions.
(d) A clear English-language summary of the specification;
The Key Management Interoperability Protocol (KMIP) establishes a single, comprehensive protocol for communication between enterprise key management servers and cryptographic clients. By defining a protocol that can be used by any cryptographic client, from the smallest automated electric meters to the most complex disk-arrays, KMIP enables enterprise key management servers to speak a single protocol to all cryptographic clients supporting the protocol. Through vendor support of KMIP, an enterprise will be able to consolidate key management in a single enterprise key management system, reducing operational and infrastructure costs while strengthening operational controls and
governance of security policy.
KMIP includes three primary elements:
* Objects. These are the symmetric keys, asymmetric keys, digital certificates and so on upon which operations are performed.
* Operations. These are the actions taken with respect to the objects, such as getting an object from a key management system, modifying attributes of an object and so on.
* Attributes. These are the properties of the object, such as the kind of object it is, the unique identifier for the object, and so on.
The protocol supports other elements, such as the use of templates that can simplify the specification of attributes in a request or response. But at its most basic level, KMIP consists of placing objects, operations and/or attributes either into a request from a cryptographic client to a key management server or into a response from a key management server to a cryptographic client.
(e) A statement regarding the relationship of this specification to similar work of other OASIS TCs or other standards developing organizations;
As a transport-level protocol, KMIP is complementary to other key management efforts, including OASIS EKMI and IEEE P1619.3, expressed in XML. KMIP leverages other standards whenever possible. For example, it uses the key life-cycle specified in NIST special publication 800-57 to define attributes related to key states. It uses network security mechanisms such as TLS to establish authenticated communication between the key management system and the cryptographic client. It relies on existing standards for encryption algorithms, key derivation and many other aspects of a cryptographic solution, focusing on the unique and critical problem of interoperable messages between key management systems and cryptographic clients.
(f) The Statements of Use presented above;
Statements of Use are available at the following locations:
Safenet (client only):
(g) The beginning and ending dates of the public review(s), a pointer to the announcement of the public review(s), and a pointer to an account of
each of the comments/issues raised during the public review period(s), along with its resolution;
First public review:
- beginning date: 1-December-2009
- ending date: 30-January-2010
- comments spreadsheet:
Second public review:
- beginning date: 29-April-2010
- ending date: 14-May-2010
- comments spreadsheet:
(h) An account of and results of the voting to approve the specification as a Committee Specification, including the date of the ballot and a pointer to the ballot;
KMIP TC unanimously agreed on 27-May-2010 to request the OASIS TC Admin to initiate a Special Majority Vote to approve the KMIP V1.0 Profiles
(see location above) as a Committee Specification. The ballot started 7-June-2010 and ended 14-June-2010., with the following results:
In favor: 28 (100% of votes; 82% of eligible voters)
Did not vote: 5
In addition, the KMIP TC unanimously agreed on 10-June-2010 to request the OASIS TC Admin to initiate a Special Majority Vote to request a vote
by the OASIS membership to approve the KMIP V1.0 Profiles committee specification as an OASIS Standard. The ballot started 30-June-2010 and
ended 7-July-2010., with the following results:
In favor: 31 (100% of votes; 91% of eligible voters)
Did not vote: 3
(i) An account of or pointer to votes and comments received in any earlier attempts to standardize substantially the same specification,
together with the originating TC's response to each comment;
There were no earlier attempts to standardize this or any other KMIP specification.
(j) A pointer to the publicly visible comments archive for the originating TC;
(k) A pointer to any minority reports delivered by one or more Members who did not vote in favor of approving the Committee Specification,
which report may include statements regarding why the member voted against the specification or that the member believes that Substantive
Changes were made which have not gone through public review; or certification by the Chair that no minority reports exist.
The KMIP co-chairs certify that no minority reports exist.