Key Management Interoperability Protocol

Objects

The types of managed-objects being managed by KMIP include:

• Symmetric-Keys used for algorithms like AES.
• Public and Private Keys used for asymmetric-algorithms like RSA, DSA and ECDH. Separate objects are used for storing the public and private key, thus a user may have permission to access one but not the other. Related objects usually contain Link attributes containing the other object's unique identifier.
• Certificates and PGP Keys.
• Split Keys, with each split being a distinct object that can be managed independently from the other splits.
• Secret Data, such as passwords.
• Opaque Data for client and server defined extensions.
• Certificate Signing Requests.

Operations

The operations provided by KMIP include:

• Create: creating a new managed object such as a symmetric key, and return the identifier.
• Create Key Pair: creating two objects that represent asymmetric keys.
• Get: retrieving an object's value given its unique identifier. The returned value may be wrapped (encrypted) with another key that is on the server for additional security.
• Register: storing an externally generated key value.
• Add Attributes, Get Attributes, Modify Attributes and Set Attribute: These can be used to manipulate mutable attributes of a managed object.
• Locate: retrieving a list of objects based on a predicates.
• Re-Key, Re-Key-Key-Pair: creating a new key that can replace an existing key. There are also attributes that can be used to have the server automatically rotate keys after a given period or number of uses. The Name is moved to the new key and is normally used to retrieve a key for protection operations such as encrypt and sign. The old key can also be retrieved using the Unique Identifier for process operations such as decryption and signature verification.
• (Re-)Certify - certifies a certificate.
• Split and Join N of M keys.
• Encrypt, Decrypt, MAC etc.: Cryptographic operations performed on the key management server. A key itself can be marked being not-Extractable, in which case its value never leaves the server.
• Export, Import: Move keys to and from other KMIP servers.
• Activate, Deactivate etc.: Operations to implement the NIST key life cycle.
• Encapsulate, Decapsulate: Post Quantum algorithm support.

Key life cycle

Each key has a cryptographic state defined by the National Institute of Standards and Technology (NIST). Keys are created in an Initial state, and must be Activated before they can be used. Keys may then be Deactivated and eventually Destroyed. A key may also be marked being Compromised.

Operations are provided for manipulating Key-state in conformance with the NIST life-cycle guidelines. A Key-state may be interrogated using the State attribute or the attributes that record dates of each transformation such as Activation Date. Dates can be specified into the future thus keys automatically become unavailable for specified operations when they expire.

Message structure

KMIP is a stateless protocol in which messages are sent from a client to a server and then the client normally awaits on a reply. Each request may contain many operations thus enables the protocol to efficiently handle large numbers of keys. There are also advanced features for processing requests asynchronously.

The KMIP protocol specifies several different types of encodings. The main one is a type–length–value encoding of messages, called TTLV (Tag, Type, Length, Value). Nested TTLV structures allow for encoding of complex, multi-operation messages in a single binary message.

There are also well defined XML and JSON encodings of the protocol for environments where binary is not appropriate.

All of these protocols are expected to be transmitted using TLS protocol in order to ensure integrity and security. However, it is also possible to register and retrieve keys that are wrapped (encrypted) using another key on the server, which provides an additional level of security.

System management

KMIP provides standardized mechanisms to manage a KMIP server by suitably authorized administrative clients using System Objects.

User objects can be created and authorized to perform specific operations on specific managed objects. Both Managed Objects and Users can be assigned to groups, and those groups can form a hierarchy which facilitates efficient management of complex operating environments.

KMIP also provides a provisioning system that facilitates providing end points with credentials using simple one-time passwords.

Default values of attributes can be provided, so that simple clients need not specify cryptographic and other parameters. For example, an administrative user might specify that all "SecretAgent" keys should be 192 bit AES keys with CBC block chaining. A client then only needs to specify that they wish to create a "SecretAgent" key to have those defaults provided. It is also possible to enforce constraints on key parameters that implement security policy.

KMIP profiles

KMIP also defines a set of profiles, which are subsets of the KMIP specification showing common usage for a particular context. A particular KMIP implementation is said to be conformant to a profile when it fulfills all the requirements set forth in a profile specification document. OASIS has put forth various profiles describing the requirements for compliance towards storage arrays^[4] and tape libraries,^[5] but any organization can create a profile.

Relationship to PKCS#11

PKCS#11 is a C API used to control a hardware security module. PKCS#11 provides cryptographic operations to encrypt and decrypt, as well as operations for simple key management. There is considerable amount of overlap between the PKCS#11 API and the KMIP protocol.

The two standards were originally developed independently. PKCS#11 was created by RSA Security, but the standard is now also governed by an OASIS technical committee. It is the stated objective of both the PKCS#11 and KMIP committees to align the standards where practical. For example, the PKCS#11 Sensitive and Extractable attributes have been added to KMIP version 1.4. Many individuals are on the technical committees of both KMIP and PKCS#11.

KMIP 2.0 also provides a standardized mechanism to transport PKCS#11 messages from clients to servers. This can be used to target different PKCS#11 implementations without the need to recompile the programs that use it.

Interoperability between implementations

The OASIS KMIP Technical Committee maintains a list of results of KMIP TC interoperability testing, which can be found at OASIS Interoperability Tested. As of December 2024, there are 30 implementations across 16 vendors in this list.

The KMIP standard is defined using a formal specification document, test cases, and profiles put forth by the OASIS KMIP technical committee. These documents are publicly available on the OASIS website.

Vendors demonstrate interoperability during a process organized by the OASIS KMIP technical committee in the months before each RSA security conference. These demonstrations are informally known as interops. KMIP interops have been held almost every year since 2010. The following chart shows the Normalised number of general test cases and profile tests of all interop participants that have participated in two or more interops since 2014. ^[6]

Total KMIP Interop Server Tests

Total KMIP Interop Clients Tests

The 2025 interoperability test covered Post Quantum Cryptography (PCQ) algorithms that will be required as quantum computers become more powerful. ^[7]