Both symmetric and asymmetric keys are supported, including the ability to sign certificates.
KMIP also allows for clients to ask a server to encrypt or decrypt data, without needing direct access to the key.
Clients then use the protocol for accessing these objects subject to a security model that is implemented by the servers.
Other attributes are defined in the specification for the management of objects like the Application-Specific Identifier which is usually derived from tape-identification data.
Managed-objects may also be given a number of mutable yet globally unique Name attribute which can be used for Locating objects.
Each request may contain many operations thus enables the protocol to efficiently handle large numbers of keys.
The main one is a type–length–value encoding of messages, called TTLV (Tag, Type, Length, Value).
Default values of attributes can be provided, so that simple clients need not specify cryptographic and other parameters.
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.
PKCS#11 was created by RSA Security, but the standard is now also governed by an OASIS technical committee.
KMIP 2.0 also provides a standardized mechanism to transport PKCS#11 messages from clients to servers.
Vendors demonstrate interoperability during a process organized by the OASIS KMIP technical committee in the months before each RSA security conference.
These are used to test the interoperability of clients and servers, but they also provide concrete examples of the usage of each standard KMIP feature.