Home » Articles

p6pythonkmip – a python extension for KMIP

By Mark Joseph - July 1, 2019 @ 8:20 am

P6R has written a Python C Extension for its Secure KMIP Client (SKC). SKC is a full featured
KMIP client SDK that supports KMIP protocol versions 1.0, 1.1, 1.2, 1.3, 1.4, 2.0, and 2.1 with all message formats TTLV, JSON, XML, and TTLV over HTTPS. p6pythonkmip provides the following benefits:

  1. Exposes the full SKC KMIP features via an easy to use yet powerful API. A more complete and better tested KMIP implementation than what is available in open source.
  2. Supports both Python versions 2.X and 3.X
  3. Runs on both Linux and Windows operating systems
  4. P6R provides support and product maintenance. KMIP can be a complex protocol and P6R provides KMIP education and expert help with troubleshooting.

P6R demonstrates KMIP Client SDK’s Standards Conformance at RSA 2019

By Mark Joseph - March 8, 2019 @ 1:09 pm

P6R participated in the OASIS KMIP interoperability demonstration at the 2019 RSA conference.
P6R was showcasing the latest release of its SKC product, which contains a full featured KMIP Client with UEFI support, and PKCS11. P6R also demoed its KMIP Server Protocol Verification Suite (KVS).

As part of this demonstration P6R participated in an OASIS run interoperation test with other vendors in the KMIP Technical Committee. The results of these tests is shown below.


KVS Automated Testing for KMIP Servers

By jsusoy - February 15, 2019 @ 11:33 am

P6R’s KMIP Verification Suite (KVS) automates testing of a KMIP server for compliance with any of the defined OASIS KMIP protocol versions, including those defined in OASIS KMIP profiles. P6R has been using this tool for the past several years in at least 4 separate formal OASIS interops. The result is a very mature and easy to use tool. We’ve used it to perform interop testing, with one person running the tests, on as many as 10 servers in only days. It can be used for running single or multiple test-cases from the command line, integrating with a CI system to automate testing for every build.


  • Comprehensive coverage. KVS implements all of the defined OASIS KMIP test cases. This is over 2600 test cases, all message formats (TTLV/XML/JSON), and all KMIP versions. These tests are actually used in formal interop testing.
  • Very detailed logging. KVS provides logging of tests and KMIP protocol interactions in a variety of formats (eg. Test TTLV, but log in XML with TTLV hex dump). Detail is important to help find out what going on when a test fails. Supported log formats are TTLV, XML and JSON. Logs provide a source of proof that server is working or not. Provides separate logs for protocol logging and test output to make finding problems easier.
  • Flexible. Can easily run just one, a subset, all tests in a category, or all tests. Tests can be excluded if that is more convenient. Multiple different output formats making integration much easier.
  • Interoperable. KVS can provide jUnit style output allowing integration with a variety of tools. Runs from the command line allowing it to be scripted, or run from a variety of tools including CI systems.

Reduces QA and Development Costs

Customers that are using it are realizing huge QA cost reductions, enabling them to concentrate their engineering efforts on their server instead of writing, verifying and maintaining test cases.

“The KVS test suite has been a great asset for interoperability testing” stated John Leiseboer, CTO of QuintessenceLabs. “It works seamlessly, delivering both a significant time and resource saving, as well as a more robust process.”

P6R maintains and enhances KVS, adding test cases as they evolve in the standard. This is a significant effort. In the latest interop, around 180 new test cases were added to test the KMIP 2.0 protocol version and this does not yet cover all the new KMIP 2.0 features.

Enables Test-Driven/Test-First Development (TDD)

KVS is not just for QA. KVS enables Test-Driven Development (TDD) by providing the test cases for KMIP features that have yet to be implemented. Developers then write the code to fulfill those test cases. A huge benefit of this practice is the ability to refactor code with confidence. Developers can easily verify refactored code by running the tests periodically as they change code.

SKC Compatibility

P6R’s Secure KMIP Client (SKC) is the foundation of KVS and so another benefit of using KVS is proving compatibility with P6R’s KMIP Client.

KVS is currently shipping and available for purchase. P6R is an active  member of the OASIS KMIP Technical Committee.

The KMIP Bug Report: Db2 KMIP Client

By Mark Joseph - May 19, 2018 @ 12:20 pm

Recently a customer using the P6R’s KMIP Server Protocol Library (KSL) sent us a KMIP message that our parser pointed out as not valid KMIP. This customer was performing integration testing between their KMIP server and IBM’s Db2 Database (version 11.1 running on windows) (https://www.ibm.com/analytics/us/en/db2/). Db2 has some KMIP Client code so that it can obtain keys for database encryption from an outside KMIP server. This is what KMIP was designed for. We have no idea of the origin of the KMIP client code but assume that it was written internally.

[1] Incorrect Text String encoding

The KMIP message that was of issue was trying to execute a KMIP Activate operation and is encoded in TTLV (a binary format) KMIP 1.0 protocol version. The offending KMIP message is as follows:


The broken part of this message comes at the very end in the following bytes encoded in TTLV (which stands for Tag Type Length Value):

420094 07 00000018 41574d6b736570694a54625a49736f5f30586f7200000000

The first part “420094″ is the Tag which indicates that the data following is a unique identifier. The second part “07″ indicates the Type is a text string. The third part “00000018″ is the Length of the following data which is 24. The fourth part “41574d6b736570694a54625a49736f5f30586f7200000000″ is the Value and is the unique identifier of a key on the KMIP server to activate.

The problem is with the length part. It is set to 24 but should be set to 20 bytes. Text strings in KMIP are padded with zeros to make their length a multiple of 8 so the last 4 bytes are all padded zeros. But this padding must not be included in the length of the text string value. In the above message the Db2 KMIP client did include the padding as part of the text string length and that is incorrect.

Since the above message uses KMIP protocol version 1.0 we are going to reference the KMIP 1.0 specification document (http://docs.oasis-open.org/kmip/spec/v1.0/os/kmip-spec-1.0-os.html). From this specification, Section Item Length,

     "...If the Item Type is Integer, Enumeration, Text String, Byte String, or Interval, then 
     the Item Length is the number of bytes excluding the padding bytes. Text Strings and Byte 
     Strings SHALL be padded with the minimal number of bytes following the Item Value to obtain 
     a multiple of eight bytes." (emphasis added)

[2] An Extension Credential Type with an Incorrect Byte String Encoding

While not an error this message does use an interesting encoding for the message credential.

420024 05 00000004 8000000100000000 
  420025 08 00000018 540001010000001054000407000000034442320000000000

The “420024″ Tag indicates “Credential Type”, the “05″ Type is enumeration, the “00000004″ is the length of the enumeration, and finally the
“8000000100000000″ is a Db2 defined KMIP extension type. Now KMIP does provide several ways to extend the protocol but now our customer has to find out the Db2 proprietary definition and implement that.

The next part is the Credential Value itself and is encoded as a Byte String. Interesting the length value of the Byte String value also looks wrong as the apparent padding is again included in the defined length.

Full featured KMIP clients are not easy to implement and that is why P6R has spent years developing and testing with every commercially available KMIP server it can find. P6R’s Secure KMIP Client (SKC) is a commercial product that has been shipping for over 5 years.

2018 OASIS KMIP Client Interop Results

By Mark Joseph - April 13, 2018 @ 2:40 pm

P6R had a pod in the OASIS booth at the 2018 RSA Conference Expo. This was our 4th year at this conference. We where showing off our KMIP and PKCS#11 products.
P6R at 2018 RSA Conference Expo

P6R participated in its 4th OASIS KMIP Interop. This interop tested KMIP 1.4 and the draft specification of KMIP 2.0. P6R tested its Secure KMIP Client (SKC) with the following list of KMIP Servers: Cryptsoft KMIP C and Java Servers, Fornetix Key Orchestration Server, IBM SKLM, Kryptus kNET HSM, Micro Focus ESKM, Q-Labs qCrypt, Thales DSM, and Unbound KMIP server. Below are the results of all clients participating in the Interop. Note that P6R’s SKC results is the full column on the right. P6R SKC passed all test cases conducted in this Interop.

KeyNexus and P6R Announce KMIP Partnership

By Mark Joseph - March 27, 2018 @ 8:57 am

KeyNexus and P6R Announce KMIP Partnership, Delivering a Complete End-to-End Client-Server KMIP Solution

Detailed differences between KMIP 1.4 and 2.0

By Mark Joseph - March 24, 2018 @ 12:51 pm

This document focuses on the technical content that has changed from KMIP protocol version 1.4 to 2.0. While there are significant changes in how the two documents are organized and the material presented this article will not address those differences. This article uses the published KMIP 1.4 standard document
KMIP 1.4, 22 November 2017 and a draft version of the KMIP 2.0 standard. Please note that since this comparison is based on a draft KMIP 2.0 standard the details presented here can still change in the future.

We started this task of comparing the two protocol versions as part of the process of adding KMIP 2.0 support to our suite of KMIP products: P6R’s KMIP Client Product Suite, Secure KMIP Client (SKC), and P6R’s KMIP Server Library (KSL). We have done a similar comparsion between KMIP 1.0 and 1.1.

At a high level what has changed?

The first significant thing to notice is that all the depreciated features have been removed from previous protocol versions. The main example of this are Templates. Templates are no longer a managed object and are nowhere to be found in the specification. Another big change has occurred to attributes both in how they are represented and encoded in the protocol. The text string name of each attribute, which was also passed in the binary TTLV protocol version, has finally been removed. Lastly, I would categorize the remaining changes to be mostly improvements of existing attributes. The motivations behind these changes have been to increase interoperability and efficiency of the protocol.

1. Managed Objects

  • a. PGP Certificates have been removed and are not part of KMIP 2.0
  • b. Template objects have been removed (depreciated in KMIP 1.3) and are not part of KMIP 2.0
  • c. A Certificate Request has been added as a new managed object

2. Base Objects

  • The following have been remove and are not part of KMIP 2.0: Transparent ECDSA Private Key, Transparent ECDSA Public Key, Transparent ECDH Private Key, Transparent ECDH Public Key, Transparent ECMQV Private Key, and Transparent ECMQV Public Key.

It was deemed that the remaining Transparent EC Private Key and Transparent EC Public Key attributes where sufficient, and all have identical structures anyway. For the second item, all have been replaced and simplified which will be mentioned below.

In the Key Value structure, the Attribute array has been replaced with the Attributes structure.

3. Attributes

  • a. The following attributes have been removed and are not part of KMIP 2.0: Certificate Identifier, Certificate Issuer, Certificate Subject, Custom Attribute, and Operation Policy Name.
  • b. The following attributes have been added to KMIP 2.0: NIST Key Type, Short Unique Identifier, and Vendor Attribute (replaces the Custom Attribute).

There has also been a major change in the way that attributes are encoded. Pre-KMIP 2.0 the string name of an attribute (e.g., “Cryptographic Usage Mask”) would be sent over the network. That practice is now limited to only vendor defined attributes. In doing this a more economical encoding of each standard defined attribute has been adopted. This is significant improvement over the previous versions of the protocol.

4. Attribute Structures

  • a. The following attribute structures have been removed and are not part of KMIP 2.0: Template-Attribute, Common Template-Attribute, Private Key Template-Attribute, and Public Key Template-Attribute.
  • b. The following attribute structures have been added to KMIP 2.0: Attributes, Common Attributes, Private Key Attributes, Public Key Attributes, Attribute Reference, Current Attribute, and New Attribute.

This change was motivated by the removal of Templates from the standard. The new attribute structures are meant as a “simplified” replacement of the previous structures.

5. Modified and New Structures

  • a. The Extension Information structure has been extended with the following optional fields: Extension Enumeration, Extension Attribute, Extension Parent Structure Tag, and Extension Description.
  • b. The Profile Information structure has been extended with the “Profile Version” field.
  • c. The Key Wrapping Specification structure has its “Attribute Name” field replaced with an Attribute Reference field.
  • d. The Server Information structure was an undefined structure in KMIP 1.4 and has been changed to a well defined, multi-field structure. This is a much overdue change and finally makes this base object useful.

  • e. The Log Message base object has been added new to KMIP 2.0

6. Operations

  • a. There has been a positive change in all operations that sent attributes to a KMIP server. In KMIP 1.4 and earlier, the responses to such operations would return a copy of all the attributes that where included in the request. This has changed in KMIP 2.0 in that responses no longer return a copy of the attributes that appeared in the request

    b. Operations where this change has been made include: Create, Create Key Pair, Add Attribute, Delete Attribute, Derive Key, Create Split Key, Join Split Key, Register, Certify, Re-Certify, Re-Key, and Re-Key Key Pair.

  • c. Add Attribute, Attribute replaced by Current Attribute structure
  • d. Certify, Template-Attribute replaced by Attributes structure
  • e. Create, Template-Attribute replaced by Attributes
  • f. Create Key Pair, Common Template-Attribute replaced by Common Attributes, Private Key Template-Attribute replaced by Private Key Attributes, Public Key Template-Attribute replaced by Public Key Attributes
  • g. Create Split Key, Template-Attribute replaced by Attributes
  • h. Delete Attribute, Attribute Name and Attribute Index replaced by Current Attribute. Note, that to delete an attribute the value of that attribute must be provided in the Current Attribute structure. This is different from KMIP 1.4
  • i. Derive Key, Template-Attribute replaced by Attributes
  • j. Export, in the response one or more Attribute structures are replaced by Attributes, Template is removed
  • k. Get, in the response Template is removed
  • l. Get Attributes, Attribute Name replaced by Attribute Reference, in response zero or more Attribute structures replaced by Attributes
  • m. Get Atribute List, in response Attribute Name replaced byAttribute Reference
  • n. Import, Object Type added, one or more Attribute structures replaced by Attributes, Template removed
  • o. Join Split Key, Template-Attribute replaced by Attributes
  • q. Locate, zero or more Attribute structures replaced by Attributes.
    The paragraph starting with “Wild-cards or regular expressions” has been removed since it has not been implemented and it is unclear how to implement it.
    The description of how the “Storage Status Mask field” is used has been expanded.
  • r. Log, a new operation
  • s. Modify Attribute, Attribute replaced by Current Attribute and New Attribute structures
  • t. Register, Template-Attribute replace by Attributes, Template removed
  • u. Re-Certify, Certificate Request Unique Identifier added, Template-Attribute replaced by Attributes
  • v. Re-Key, Template-Attribute replaced by Attributes
  • w. Re-Key Key Pair Common Template-Attribute replaced by Common Attributes, Key Private Template-Attribute replaced by Private Key Attributes, Public Key Template-Attributes replaced by Public Key Attributes
  • x. Notify, the list of Attribute structures has been replaced by the new Attributes structure for indicating attributes that have changed and a list of Attribute Reference structures indicating attributes that have been deleted.
  • y. Put, Template object has been removed from the list of objects that can be pushed to the client and the list of Attribute structures has been replaced by the new Attributes structure.

7. Enumerations and Masks

  • a. Certificate Request Type Enumeration: PGP has been removed
  • b. Certificate Type Enumeration: PGP has been removed
  • c. Item Type Enumeration: Data Time Extended is new
  • d. Link Type Enumeration: Wrapping Key Link is new
  • e. Object Type Enumeration: Certificate Request is new
  • f. NIST Key Type Enumeration has been added to KMIP 2.0
  • g. Profile Name Enumeration: all profiles before KMIP 2.0 have been removed
  • h. Storage Status Mask: Destroyed Storage is new
  • i. Tags have been moved into the enumerations section. Several old tag values have been removed by being marked as “reserved”. New tag values have been from 420125 (i.e., Attributes) to 42013D (i.e., New Attribute).

8. Miscellaneous

  • a. Under message encoding a new TTLV type has been added: Data Time Extended which is a 64 bit POSIX Time in micro-seconds.
  • b. The default value for Batch Order Option has been changed to True (i.e., batched operations shall be executed in the order in which they appear in a request).

P6R’s KMIP Verification Suite (KVS)

By Mark Joseph - March 13, 2018 @ 11:08 am

This document was updated on 30 June 2020.

P6R is introducing the new product KMIP Verification Suite (KVS). Due to customer interest we have taken our KMIP test harness, which we have used to develop our KMIP Client product (SKC) and have used during several OASIS KMIP Interop events, and are making it available to vendors to test their KMIP server products. KVS implements all defined OASIS KMIP test cases for protocol versions 1.0, 1.1, 1.2, 1.3, 1.4, 2.0, and 2.1. KVS is implemented with P6R’s Secure KMIP Client (SKC) to generate proper KMIP messages in TTLV, JSON, XML, and TTLV over HTTPS. SKC is also used to parse the server’s response while KVS matches the server’s response to what is expected as defined by the OASIS test cases.

KVS supports the following OASIS defined KMIP defined tests:
KMIP Test Cases Version 1.0, (defined in several of the documents below such as http://docs.oasis-open.org/kmip/testcases/v1.2/kmip-testcases-v1.2.html)

KMIP Test Cases Version 1.1, http://docs.oasis-open.org/kmip/testcases/v1.1/kmip-testcases-v1.1.html

KMIP Test Cases Version 1.2, http://docs.oasis-open.org/kmip/testcases/v1.2/kmip-testcases-v1.2.html

KMIP Test Cases Version 1.3, http://docs.oasis-open.org/kmip/testcases/v1.3/kmip-testcases-v1.3.html

KMIP Test Cases Version 1.4, http://docs.oasis-open.org/kmip/testcases/v1.4/cn01/kmip-testcases-v1.4-cn01.html

KMIP Test Cases Version 2.0, http://docs.oasis-open.org/kmip/kmip-testcases/v2.0/cn01/kmip-testcases-v2.0-cn01.html

KMIP Test Cases Version 2.1

KVS has been used to test interoperability with the following KMIP servers:
1. Cryptsoft KMIP C Server SDK
2. Cryptsoft KMIP Java Server SDK
3. Dell KMIP Server
4. Fornetix Key Orchestration Server
5. Micro Focus ESKM Server (formerly HPE)
6. IBM SKLM Server
7. QuintessenceLabs qCrypt Server
8. SafeNet KeySecure Server
9. Thales KeyAuthority KMIP Server
10. Townsend Security Alliance Key Manager
11. Utimaco KeyServer
12. Vormetric Data Security Manager KMIP Server
13. Kryptus kNET HSM
14. Hancom Secure KeyManager
15. Unbound UKC Server
16. keyNexus KMIP Server

P6R is a member of the OASIS KMIP technical committee and one if its employees is a co-editor on several of the KMIP test case documents.

P6R has been in business for 14 years

By Mark Joseph - November 30, 2017 @ 10:44 am

P6R is a privately held, self-funded and self-sustaining software company found in 2004. Providing multi-platform solutions to a broad range of businesses, P6R’s security products and professional services enable businesses to easily solve their key management and encryption integration challenges with OASIS KMIP, PKCS#11 toolkits and custom clients.

P6R partners with our customers in an ongoing relationship to develop successful solutions that deliver the highest levels of quality and customer value. P6R has a wide range of expertise in areas including computer security, networking, mobile technologies, scalability, high-availability, email, and ad serving. We take personal pride in everything that we do and are committed to achieving exceptional business results.

P6R is a Sponsor level member of OASIS (https://www.oasis-open.org/member-roster).

P6R is a member of the OASIS KMIP Technical Committee.

P6R is a member of the OASIS PKCS#11 Technical Committee.

P6R provides KMIP client (https://www.p6r.com/articles/2016/08/08/p6rs-kmip-client-product-suite/) and server (https://www.p6r.com/articles/2017/11/14/p6rs-kmip-server-library-ksl/) products.

P6R also provides a PKCS#11 library that integrates with KMIP and all major HSMs (https://www.p6r.com/articles/2014/11/22/p6rs-pkcs-11-provider/)

P6R has customers in disk storage, health care, financial, and enterprise data management.

P6R is a technology partner with several major security companies:
Safenet (https://safenet.gemalto.com/partners/p6r/), Thales e-Security ASAP member, Microfocus (previously HPE).

P6R is a US company based in California. All development and testing are done in the US.

P6R’s KMIP Server Library (KSL)

By Mark Joseph - November 14, 2017 @ 12:32 pm

This document was updated on 21 Jan. 2018.

P6R is introducing the new product KMIP Server Library (KSL). Due to customer interest we have extended our powerful KMIP client parsing library (i.e., SKC) to be able to parse server side requests. This product includes a server side parser and all the functions needed to send a properly encoded response back to a KMIP client. The idea is that a vendor, who has a key server, can now use KSL to add a KMIP protocol front end. The server vendor will still have to implement all server side mechanisms, but will not have to deal with the complexity of parsing or generating TTLV, XML, and JSON KMIP messages.

KSL is available on Windows and Linux. It supports a C++, C, and Java Native Interface (JNI) language bindings. KSL supports all KMIP operations that are defined for KMIP 1.0, 1.1, 1.2, 1.3, and 1.4 except for: Export. Support for the KMIP 1.4 operation Export will be added in the near future. KMIP 2.0 support will also be added at a future date once the specification for that protocol version is published.