KMIP V1.2 topics

[<robert.griffin@rsa.com>]

Hi –

 

For our KMIP TC call tomorrow (including for discussion of the F2F agenda), here’s the list of topics that I know of so far in terms of V1.2 enhancements:

 

Use cases that will drive our enhancements:

 

-          Virtualization-related use cases. Implications of these will likely include entity object, group object, policy object, registration operations.

 

-          Storage-related use cases. Implications here include alternative trust establishment models

 

-          PGP-related use cases. Implications here include new PGP-related objects and operations.

 

-          QKD use cases; implications include alternatives for trust establishment

 

Enhancements to KMIP protocol

 

-          PGP objects, operations and attributes

 

-          Entity, including different entity types, delegation models, entity groups

 

-          Policies, including access/permission policies, cryptographic policies

 

-          Enhancements to registration operation

 

-          Other modifications to groups, particularly for cryptographic objects (as opposed to entities

 

-          alternatives to TLS for end-to-end trust, such as with intermediaries

 

KMIP profiles, conformance validation, etc

 

-          New profiles related to new use cases

 

-          Test-bed and/or certification through SNIA SSIF or UNH

 

These possible enhancements are included in the current version of the V1.1 Usage Guide:

 

·         Registration of Clients. This would allow in-band registration and management of clients, which currently may only be registered and/or managed using off-line mechanisms.

·         Client-requested specification of additional clients that are allowed to use a key. This requires coordinated identities between the client and server, and as such, is deferred until registration of clients is addressed.

·         Registration of Notifications. This would allow clients to specify, using an in-band mechanism, information and events that they wish to be notified of, and what mechanisms should be used for such notifications, possibly including the configuration of pushed cryptographic material. This functionality would assume the Registration of Clients as a prerequisite.

·         Key Migration. This would standardize the migration of keys from one HSM to another, using mechanisms already in the protocol or ones added for this purpose.

·         Server to Server key management. This would extend the protocol to support communication between key management servers in different key management domains, for purposes of exporting and importing cryptographic material and potentially policy information.

·         Multiple derived keys. This would allow the creation of multiple derived keys from one or more input keys. Note, however, that the current version of KMIP provides the capability to derive multiple keys and initialization vectors by creating a Secret Data object and specifying a cryptographic length equal to the total length of the derived objects.

·         XML encoding. _expression_ of KMIP in XML rather than in tag/type/length/value may be considered for the future.

·         Specification of Mask Generation Function. KMIP does not currently allow clients to specify the Mask Generation Function and assumes that encryption or signature schemes, such as OAEP or PSS, use MGF1 with the hash function as specified in the Cryptographic Parameters attribute. Client specification of MGFs may be considered for the future.

·         Server monitoring of client status. This would enable the transfer of information about the client and its cryptographic module to the server. This information would enable the server to generate alarms and/or disallow requests from a client running component versions with known vulnerabilities.

·         Symmetric key pairs. Only a subset of the cryptographic usage bits of the Cryptographic Usage Mask attribute may be permitted for keys distributed to a particular client. KMIP does not currently address how to securely assign and determine the applicable cryptographic usage for a client.

·         Hardware-protected attribute. This attribute would allow clients and servers to determine if a key may only be processed inside a secure cryptographic device, such as an HSM. If this attribute is set, the key may only exist in cleartext within a secure hardware device, and all security-relevant attributes are bound to it in such a way that they may not be modified outside of such a secure device.

·         Alternative profiles for key establishment. Less capable end-clients may not be able to support TLS and should use a proxy to communicate with the key management system. The KMIP protocol does not currently define alternative profiles, nor does it allow end-clients relying on the proxy model to securely establish a key with the server.

·         Attribute mutation. The possibility for the server to use attribute values different than requested by the client if these values are not suitable for the server, and return these values in the response, instead of failing the request.

·         Cryptographic Domain Parameters. KMIP allows a limited number of parameters to be specified during a Create Key Pair operation. Additional parameters may be considered for the future.

·         Certificate Suspension/Unsuspension. KMIP does not currently support certificate suspension (putting a certificate on hold) or unsuspension (removing a certificate from hold).  Adding support for certificate suspension/unsuspension into KMIP may be considered for the future.

·         Namespace registration. Establishing a registry for namespaces may be considered for the future.

·         Registering extensions to KMIP enumerations. Establishing a registry for extensions to defined KMIP enumerations, such as in support of profiles specific to IEEE P1619.3 or other organizations, may be considered for the future.

 

Regards,

Bob