The Cover Pages [画像:The OASIS Cover Pages: The Online Resource for Markup Language Technologies]
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
OASIS Members Form Key Management Interoperability Protocol (KMIP) Committee.

Contents

Nearby: Cryptographic Key Management

Recent Updates:

On October 14, 2010, OASIS announced the approval of the Key Management Interoperability Protocol (KMIP) Version 1.0 as an OASIS Standard. Developed through a collaboration of more than thirty (30) vendors and end user organizations, KMIP enables communication between key management systems and cryptographically-enabled applications, including email, databases, and storage devices.

On September 01, 2010, OASIS announced that members of the Key Management Interoperability Protocol (KMIP) Technical Committee had submitted two approved Committee Specification documents for consideration at OASIS Standard maturity level: Key Management Interoperability Protocol Specification Version 1.0 and Key Management Interoperability Protocol Profiles Version 1.0. Balloting for the two specifications was scheduled for September 16-30, 2010. Note also companion specifications at CS 01 level: Key Management Interoperability Protocol Usage Guide Version 1.0 (provides illustrative information on using the protocol) and Key Management Interoperability Protocol Use Cases Version 1.0 (provides samples of protocol messages corresponding to a set of defined test cases).

On April 29, 2010, OASIS announced a 15-day public review for the four Key Management Interoperability Protocol Version 1.0 specifications, through May 14, 2010. The documents for review include:

On November 05, 2009, the OASIS KMIP Technical Committee voted to accept four KMIP Version 1.0 specification documents at Committee Draft level and release them for public review. Public review was announced for December 01, 2009 through January 30, 2010. Subsequently, comments were organized for evaluation by the TC members and for disposition. At the same time, additional proposals were sent to the KMIP TC list for consideration in KMIP 1.0 and 2.0.

On February 12, 2009, Brocade, EMC/RSA, HP, IBM, LSI, NetApp, Seagate, and Thales e-Security submitted a draft charter proposal for the creation of an OASIS Key Management Interoperability Protocol (KMIP) Technical Committee.

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, ranging from a simple automated electric meter to very complex disk-arrays, KMIP enables enterprise key management servers to communicate via a single protocol to all cryptographic clients supporting that 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 addresses the critical need for a comprehensive key management protocol built into the information infrastructure, so that enterprises can deploy effective unified key management for all their encryption, certificate-based device authentication, digital signature, and other cryptographic capabilities."

Initial supporting entities for KMIP included Brocade, Cisco, EMC/RSA, HP, IBM, LSI, NetApp, Seagate, and Thales e-Security. Additional statements of support have been received (corporate or individual) from 3PAR, Aetna, Akamai Technologies, Algorithmic Research (Arx), Axway Software, BeCrypt, Computer Associates (CA), CipherOptics, Cryptsoft, Dajeil, DigiCert, Election Systems and Software, Emulex, Exar Corporation, Freescale Semiconductor, International Electronic Communication Analysts (IECA), Lexmark International, MIT, Mitre Corporation, National Security Agency (NSA), NIST, Oracle, PayPal, PGP Corporation, PrimeKey Solutions, Quantum, Red Hat, SafeNet, Skyworth TTG, Sun Microsystems, Symantec, Target, US Department of Defense (DoD), Valicore, Venafi, Verisign, Voltage Security, Vormetric, and others.

A final approved KMIP TC Charter and Call for Participation was published on March 04, 2009. The KMIP First Meeting was scheduled to be held as a Face-to-Face meeting on April 24, 2009, from 9am PDT until 5pm PDT, at the West Mezzanine 274/276 in the Moscone Convention Center in San Francisco (RSA 2009 San Francisco Conference). A special code is available for a free conference pass for those not otherwise registered. Initial (some provisional) agenda items include nomination and election of KMIP TC (Co-)Chair(s); review and modify meeting agenda; presentation on submitted draft KMIP specification, usage guide and use cases; discuss a weekly TC meeting schedule, identification of questions/issues/changes/additions for KMIP V1.0 and future versions; [in addition to the deferred items listed in the KMIP Usage Guide '6.0 Deferred KMIP Functionality'], other potential items that have been suggested so far include: byte alignment within KMIP messages and enhanced capabilities for registering client-generated symmetric keys; setting priorities of identified issues and process for moving them to resolution; draft schedule leading to KMIP V1.0 public review, including agenda for next meeting, etc...

The Key Management Interoperability Protocol (KMIP) was initially developed by HP, IBM, RSA, and Thales e-Security in the 2007-2008 timeframe to meet the compelling needs of today's enterprise data centre environments; Brocade, LSI, and Seagate later joined the specification development effort. NetApp representatives were named in the KMIP TC proposal and as specification co-authors.

The OASIS KMIP Technical Committee (as chartered) "will develop specification(s) for the interoperability of key management services with key management clients. The specifications will address anticipated customer requirements for key lifecycle management (generation, refresh, distribution, tracking of use, life-cycle policies including states, archive, and destruction), key sharing, and long-term availability of cryptographic objects of all types (public/private keys and certificates, symmetric keys, and other forms of "shared secrets") and related areas."

The problem addressed by KMIP, according to the published FAQ document, is "primarily that of standardizing communication between encryption systems that need to consume keys and the key management systems that create and manage those keys. Being able to encrypt and retain access to data requires that encryption keys be generated and stored. To date, organizations deploying encryption have not been able to take advantage of interoperability across encryption and the key management systems. By defining a low-level protocol that can be used to request and deliver keys between any key manager and any encryption system, KMIP enables the industry to have any encryption system communicate with any key management system. Through this interoperability, enterprise will be able to deploy a single enterprise key management infrastructure to mange keys for all encryption systems in the enterprise that require symmetric keys, asymmetric keys pairs, certificates and other security objects..."

According to the announcement from the supporting companies, KMIP "was developed to support other industry standardization efforts and is complementary to application-specific standards projects such as IEEE 1619.3 (for storage needs) and OASIS EKMI (for XML needs)."

The KMIP protocol supports all reasonable key management system related cryptographic objects. This list currently [version 0.98] includes: (1) Symmetric Keys; (2) Split (multi-part) Keys; (3) Asymmetric Key Pairs and their components; (4) Digital Certificates; (5) Derived Keys; (6) Opaque (non-interpretable) cryptographic objects.

The Charter Proposal for the OASIS KMIP TC reports that the initial TC goal is to "define an interoperable protocol for standard communication between key management servers, and clients and other actors which can utilize these keys. Secure key management for TPMs [Trusted Platform Modules] and Storage Devices will be addressed. The scope of the keys addressed is enterprise-wide, including a wide range of actors: that is, machine, software, or human participants exercising the protocol within the framework. Actors for KMIP may include: Storage Devices, Networking Devices, Personal devices with embedded storage (e.g., Personal Computers, Handheld Computers, Cell Phones), Users, Applications, Databases, Operating Systems, Input/Output Subsystems, Management Frameworks, Key Management Systems, and Agents..."

Planned deliverables from the OASIS KMIP TC include: (1) Revised KMIP Specification which defines the normative expression of the protocol, including objects, attributes, operations and other elements; (2) Updated KMIP Usage Guide which provides illustrative and explanatory information on implementing the protocol, including authentication profiles, implementation recommendations, conformance guidelines and security considerations; (3) Revised document for KMIP Use Cases and Test Cases which supplies sample use cases for KMIP, test cases for implementing those use cases, and examples of the protocol implementing those test cases; (4) Updated KMIP FAQ Document to provide guidance on what KMIP is, the problems it is intended to address, and other frequently asked questions.

KMIP Specification: Bibliographic Information and Overview

In conjunction with the KMIP announcement of February 12, 2009 and the proposed TC Charter, four KMIP documents were designated for contribution to the OASIS KMIP TC: KMIP Specification, Usage Guide, Use Cases, and FAQ document.

  • KMIP: Key Management Interoperability Protocol . [aka "Key Management Interoperability Protocol Specification"] Draft Version 0.98. Revised February 10, 2009. 108 pages. Edited by Robert Haas (IBM Zurich Research Laboratory, WWW) and Jeff Kravitz [WWW]. Corporate authors: Brocade, EMC, Hewlett Packard Development Corporation, IBM, NetApp, and Thales e-Security. Copyright © 2009 EMC, Hewlett Packard Development Corporation, IBM, and Thales e-Security. Contributors: David Babcock (HP), Steven Bade (IBM), Paolo Bezoari (NetApp), Mathias Björkqvist (IBM), Bruce Brinson (EMC), Christian Cachin (IBM), Tony Crossman (nCipher), Stan Feather (HP), Indra Fitzgerald (HP), Judy Furlong (EMC), Jon Geater (nCipher), Bob Griffin (EMC), Robert Haas (IBM - Editor), Timothy Hahn (IBM), Jack Harwood (EMC), Walt Hubis (LSI), Glen Jaquette (IBM), Jeff Kravitz (IBM - Editor), Michael McIntosh (IBM), Brian Metzger (HP), Anthony Nadalin (IBM), Elaine Palmer (IBM), Joe Pato (HP), René Pawlitzek (IBM), Subhash Sankuratripati (NetApp), Mark Schiller (HP), Martin Skagen (Brocade), Marcus Streets (nCipher), John Tattan (EMC), Karla Thomas (Brocade), Marko Vukolic (IBM), and Steve Wierenga (HP).

    From the specification 'Introduction': "This document is intended as a specification of the protocol used for the communication between clients and servers to perform certain management operations on objects stored and maintained by a key management system. These objects will be referred to as Managed Objects in this specification. They include symmetric and asymmetric cryptographic keys, digital certificates, and templates used to simplify the creation of objects and control their use. Managed Objects are managed with operations that include the ability to generate cryptographic keys, register objects with the key management system, obtain objects from the system, destroy objects from the system, and search for objects maintained by the system. Managed Objects also have associated attributes, which are named values stored by the key management system and which can be obtained from the system via operations. Certain attributes may be changed, added or deleted, again by operations.

    The protocol specified in this document includes several certificate-related functions for which there are a number of existing protocols — namely Validate (e.g., SVP or XKMS), Certify (e.g., CMP, CMC, SCEP) and Re-certify (e.g., CMP, CMC, SCEP). The protocol does not attempt to define a comprehensive certificate management protocol such as would be required for a certification authority. However, it does include functions that are needed in proxying certificate management functions through a key server..."

    Managed Objects. Managed Objects are objects that are the subjects of key management operations, including all objects that may be registered with the system. Managed Cryptographic Objects are the subset of Managed Objects that contain cryptographic material, e.g., certificates, keys, and secret data.

    1. Certificate: A Managed Cryptographic Object, which is a digital certificate, such as an encoded X.509
    2. Symmetric Key: A Managed Cryptographic Object which has a Key Block
    3. Public Key: A Managed Cryptographic Object, which is the public portion of an asymmetric key pair; this is a raw public key, not a certificate
    4. Private Key: A Managed Cryptographic Object, which is a the private portion of an asymmetric key pair
    5. Split Key: A Managed Cryptographic Object, which is a split key; a split key is a secret, usually a symmetric key or a private key that has been split into a number of parts, each of which can then be distributed to several key holders, for additional security
    6. Template: A named Managed Object containing the client-settable attributes of a Managed Cryptographic Object, essentially a stored, named list of attributes used in various operations
    7. Policy Template: A named Managed Object containing attributes, used to encapsulate all of the policy-related attributes into a Managed Object which may be independent of any single Managed Cryptographic Object
    8. Secret Data: A Managed Cryptographic Object containing a shared secret that is not a key or certificate, e.g., a password, where the Key Block used to contain Secret Data should contain a (possibly wrapped) Key Value of the Opaque type
    9. Opaque Object: A Managed Object that the key management server may not be able to interpret, but will store, where the context information for this object can be stored and retrieved using Custom Attributes

    Protocol Operations. KMIP defines a set of standardized Operations that apply to Managed Objects that consist of Attributes and possibly cryptographic material. Some twenty-six (26) Client-to-Server Operations are described in Section 4 of the KMIP 0.98 specification; two (2) Server-to-Client Operations (Notify, Put) are presented in Section 5. Summary:

    1. Create: An operation which requests the server to generate a new key as a Managed Cryptographic Object, containing information about the type of object being created, and some of the attributes to be assigned to the object (e.g., Cryptographic Algorithm, Cryptographic Length)
    2. Create Key Pair: An operation which requests the server to generate a new public/private key pair and register the two corresponding new Managed Cryptographic Objects, containing attributes to be assigned to the objects (e.g., Cryptographic Algorithm, Cryptographic Length), where Attributes and Template Names can be specified for both keys at the same time, by specifying a Common Template-Attribute object in the request
    3. Register: An operation which requests the server to register a Managed Object (created by the client or obtained by the client through some other means), allowing the server to manage the object, where arguments in the request are similar to those in the Create operation, but also may contain the object itself, for storage by the server
    4. Re-key: A request used to generate a replacement key for an existing symmetric key, analogous to the Create operation, except that many of the attributes of the new key are unchanged from the original key
    5. Derive Key: A request used to derive a symmetric key using a key or secret that is already known to the key management system, applicable only to Managed Objects that can be used for key derivation; the Derive Key bit must be set in the Cryptographic Usage Mask attribute of the specified Managed Object
    6. Certify: A request used to obtain a new certificate for a public key, where only a single certificate can be requested at a time; server support for this operation is optional, as it requires that the key management system have access to a certification authority
    7. Re-certify: A request used to renew an existing certificate with the same key pair, where only a single certificate can be renewed at a time; server support for this operation is optional, as it requires that the key management system have access to a certification authority
    8. Locate: An operation which requests that the server searches for one or more Managed Objects, specified by one or more attributes,where all attributes are allowed to be used
    9. Check: An operation which requests that the server checks for the use of a Managed Object according to policy-related values specified in the request, used only when placed in a batched set of operations, usually following a Locate, Create, Create Pair, Derive Key, Certify, Re-Certify or Re-Key operation and followed by a Get operation
    10. Get: A request that the server return a Managed Object, which is specified in the request by its Unique Identifier
    11. Get Attributes: A request which returns one or more attributes of a Managed Object, where the object is specified by its Unique Identifier and the desired attributes are specified by name in the request
    12. Get Attribute List: A request which returns a list of the attribute names associated with a specified object; the object is specified by its Unique Identifier
    13. Add Attribute: A request which adds a new attribute (with possibly multiple values) and sets its value, containing the Unique Identifier of the Managed Object which the attribute pertains to, and the name and new value of the attribute
    14. Modify Attribute: A request which modifies the value of an existing attribute, containing the Unique Identifier of the Managed Object which the attribute pertains to, and the name, optional index, and new value of the attribute
    15. Delete Attribute: A request used to delete an attribute, containing the Unique Identifier of the Managed Object which the attribute pertains to, and the name, and optionally the Attribute Index of the attribute
    16. Obtain Lease: A request used to request a new Lease Time for a specified cryptographic object, where the Lease Time is an interval value that determines when the client's internal cache of information about the object expires and must be renewed
    17. Get Usage Allocation: A request is used to obtain an allocation from the current Usage Limits values, to allow the client to use the Managed Cryptographic Object for protection purposes, applicable only to Managed Cryptographic Objects that can be used for protection purposes (symmetric keys, private keys, public keys) and valid only if the Managed Cryptographic Object has a Usage Limits attribute
    18. Activate: A request used to activate a Managed Cryptographic Object, containing the unique identifier of the Managed Cryptographic Object
    19. Revoke: A request used to revoke a Managed Cryptographic Object, containing the unique identifier of the Managed Cryptographic Object and a reason for the revocation, e.g., 'compromised', 'no longer used', etc.
    20. Destroy: A request used to indicate to the server that the key material for the specified Managed Cryptographic Object should be destroyed, where the meta-data for the key material may be retained by the server
    21. Archive: A request used to specify that a Managed Object is now permitted to be placed in archival storage, where actual time when the object is placed in archival storage and the location of the archive or level of archive hierarchy are determined by the policies within the key management system, and are not specified by the client
    22. Recover: A request used to obtain access to a Managed Object that has been placed in archival storage, and may require asynchronous polling to obtain the response
    23. Validate: An operation requesting that the server validate a certificate chain, and return information on its validity, where only a single certificate chain may be included; the request may contain a list of certificate objects, and/or a list of Unique Identifiers which identify Managed Certificate objects
    24. Query: A request is used by the client to interrogate the server to determine its capabilities and/or protocol mechanisms, where the Query Function field in the request may contain (one of) Query Operations, Query Objects, or Query Server Information
    25. Cancel: A request is used to cancel an outstanding asynchronous operation, where the correlation value of the original operation must be specified in the request
    26. Poll: A request is used to poll the server in order to obtain the status of an outstanding asynchronous operation
    27. Notify: Server-to-Client operation is used to notify a client of events, only sent by a server to a client outside the normal client request/response protocol
    28. Put: Server-to-Client operation is used to 'push' Managed Cryptographic Objects to clients, only sent by a server to a client outside the normal client request/response protocol

    Attributes. KMIP Specification Section 3 ("Attributes") describes attributes that are associated with Managed Objects. Managed objects include: Certificate, Symmetric Key, Public Key, Private Key, Split Key, Template, Policy Template, Secret Data, and Opaque Object. The attributes may be obtained by a client from the server using the Get Attribute operation. Some attributes may be set by the Add Attribute operation or updated by the Modify Attribute operation, and some may be deleted by the Delete Attribute operation if they no longer apply to the Managed Object. When attributes are returned by the server, e.g., via a Get Attributes operation, the returned attribute value may differ depending on the client. For example, the Cryptographic Usage Mask value may be different for different clients, depending on the policy of the server. Similarly, when a client modifies an attribute, this is merely a mechanism for sending information to the server. The server may store the attribute as received, or modify the attribute before saving it, or combine it with information from other sources, or merely use it as advice on how to modify its internal knowledge of the cryptographic object. The choice depends on server functionality, policy, and the kind of attribute being modified."

    Summary of Managed Object attributes:

    1. Unique Identifier: generated by the key management system to uniquely identify a Managed Object
    2. Name: used to identify and locate the object, assigned by the client
    3. Object Type: type of a Managed Object, e.g., public key, private key, symmetric key, etc
    4. Cryptographic Algorithm: cryptographic algorithm used by the object, e.g., RSA, DSA, DES, 3DES, AES, etc.
    5. Cryptographic Length: the length in bits of the cryptographic key material of the Managed Cryptographic Object
    6. Cryptographic Parameters: a structure that contains a set of optional fields that describe certain cryptographic parameters to be used when performing cryptographic operations using the object
    7. Certificate Type: type of a certificate, e.g., X.509, PGP, etc.
    8. Certificate Issuer: identification of a certificate, containing the Issuer Distinguished Name (from the Issuer field of the certificate) and the Certificate Serial Number (from the Serial Number field of the certificate)
    9. Certificate Subject: contains the Subject Distinguished Name (from the Subject field of the certificate) optionally including one or more alternative names (e.g., email address, IP address, DNS name)
    10. Digest: A digest of the key (digest of the Key Material), certificate (digest of the Certificate Value), or opaque object (digest of the Opaque Data Value)
    11. Operation Policy Name: indication of what entities may perform which key management operations on the object
    12. Cryptographic Usage Mask: is a bit mask which indicates to the client which cryptographic functions may be performed using the key
    13. Lease Time: defines a time interval for a Managed Object that indicates how long a client should use the object
    14. Usage Limits: a mechanism for limiting the usage of a Managed Cryptographic Object
    15. State: an indication of the state of an object as known to the key management server, where an object may be in one of six states at any given time, as described in NIST Special Publication 800-57
    16. Initial Date: date and time when the Managed Cryptographic Object was first created or registered at the server
    17. Activation Date: date and time when the Managed Cryptographic Object may begin to be used
    18. Process Start Date: date and time when a Managed Symmetric Key Object may begin to be used for process purposes, e.g., decryption or unwrapping, depending on the value of its Cryptographic Usage Mask attribute
    19. Protect Stop Date: date and time when a Managed Symmetric Key Object may no longer be used for protect purposes
    20. Deactivation Date: The date and time when the Managed Cryptographic Object may no longer be used for any purpose, except for decryption, signature verification, or unwrapping...
    21. Destroy Date: date and time when the Managed Cryptographic Object was destroyed
    22. Compromise Occurrence Date: date and time when the Managed Cryptographic Object was first believed to be compromised
    23. Compromise Date: date and time when the Managed Cryptographic Object is entered into the compromised state
    24. Revocation Reason: indication of why the Managed Cryptographic Object was revoked, e.g., 'compromised', 'expired', 'no longer used', etc.
    25. Archive Date: date and time when the Managed Object was placed in archival storage
    26. Object Group: group name, where an object may be part of a group of objects
    27. Link: A link from a Managed Cryptographic Object to another, closely related target Managed Cryptographic Object
    28. Application Specific Identification: used to specify the intended use of a Managed Object
    29. Contact Information: optional attribute, where content is used for contact purposes only
    30. Last Changed Date: date and time of the last change to the contents or attributes of the specified object
    31. Custom Attribute: user-defined attribute and intended for vendor-specific purposes

  • Key Management Interoperability Protocol Usage Guide . Draft Version 0.98. Revised February 10, 2009. 22 pages. Copyright © 2009 Brocade, EMC, Hewlett Packard Development Corporation, IBM, LSI, NetApp, and Thales e-Security.

    This Guide is intended to complement the Key Management Interoperability Protocol Specification by providing guidance on how to implement KMIP most effectively to ensure interoperability. In particular, it includes the following guidance: (1) Clarification of assumptions and requirements that drive or influence the design of KMIP and implementation of KMIP-compliant key management. (2) Definition of required and optional profiles for authentication and communication privacy between KMIP participants — clients and servers. (3) Specific recommendations for implementation of particular KMIP functionality. (4) Clarification of mandatory and optional capabilities for conformant implementations. (5) Functionality considered for inclusion in KMIP V1.0 but deferred to subsequent versions of the standard. (6) Further assistance for implementing KMIP is provided by the Use Cases document that describes a set of recommended test cases and provides the TTLV (Type/Tag/Length/Value) format for the message exchanges defined by those use cases.

    Section 2.0 ("Assumptions") describes assumptions that underlie the KMIP protocol and implementation of clients and servers that utilize the protocol. Summary:

    • Islands of Trust: Clients are necessarily given key material but they must only use that keying material for the purposes explicitly listed in the delivery payload.
    • Message Security: KMIP relies on TLS/SSL to authenticate the client and on the underlying protocol to provide confidentiality, integrity, message authentication and protection against replay attack.
    • State-less Server: The protocol operates on the assumption that the server is state-less, which means that there is no concept of 'sessions' inherent in the protocol.
    • Extensible Protocol: The protocol provides for 'private' or vendor-specific extensions, which allow for differentiation among vendor implementations.
    • Support for Cryptographic Objects: The protocol supports all reasonable key management system related cryptographic objects.
    • Client-Server Message-based Model: The protocol operates primarily in a client-server, message-based model; the exceptions are the Put and Notify operations.
    • Synchronous and Asynchronous Messages: The protocol allows both modes of operation.
    • Support for 'Intelligent Clients' and 'Key Using Devices': The protocol supports intelligent clients, such as end-user workstations, which are capable of requesting all of the functions of KMIP.
    • Batched Requests and Responses: The protocol contains a mechanism for sending batched requests and receiving batched responses, to allow for higher throughput on operations that deal with a large number of entities.
    • Reliable Message Delivery: The reliable message delivery function is relegated to the transport protocol, and not part of the key management protocol itself.
    • Large Responses: For requests that are capable of large responses, a mechanism in the protocol allows a client to specify in a request the maximum allowed size of a response.
    • Key Life-cycle and Key State: The KMIP Specification describes the key life-cycle model, based on the NIST 800-57 key state definitions, supported by the KMIP protocol.

    Section 3.0 ("KMIP Profiles") section describes two KMIP profiles. These profiles describe mechanisms by which authentication and communications privacy are established outside KMIP. Both profiles must be supported by any conforming implementation of KMIP.

    • SSL/TLS Profile (Mandatory): Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide secure communications for data transfers, using cryptographic mechanisms to provide both authentication of participants and privacy of the communication. SSL 2.0 has known security issues and all current implementations of HTTP/S support more recent protocols. Therefore this profile prohibits the use of SSL 2.0 and recommends SSL 3.1 or TLS 1.0.
    • HTTPS Profile: Hypertext Transfer Protocol over Secure Socket Layer or https is a URI (Universal Resource Indicator) scheme used to indicate a secure HTTP connection, requiring a different default TCP port (443) and an additional encryption and authentication layer, implemented by SSL/TLS, between HTTP and TCP. As in the SSL/TLS profile, the client certificate used in the SSL session must be included in any client-initiated KMIP messages between the client and server as the value of the Credentials object in the message, with credential type of certificate...

    Section 4.0 ("Usage Guidelines") is the most substantial section, providing guidance on using the functionality described in the Key Management Interoperability Protocol Specification. For example:

    • Authentication
    • Authorization for Revoke, Recover, Delete and Archive Operations
    • Using Notify and Put Operations
    • Usage Allocation
    • Key State and Times
    • Templates
    • Archive Operations
    • Message Extensions
    • Unique Identifiers
    • Result Message Text
    • Certificate Transitions
    • Query
    • Canceling Asynchronous Operations
    • Multi-instance Hash
    • Returning Related Objects
    • Reducing Multiple Requests through Use of Batch
    • Maximum Message Size
    • Using Offset in Re-key and Re-certify Operations
    • Locate Queries
    • ID Placeholder
    • Using Wrapped Keys with KMIP

    Section 5.0 ("Conformance") clarifies (e.g.,) that "server implementations of the KMIP protocol must support all objects, attributes, operations and profiles not specified as optional in the KMIP Specification in order to be conformant to the specification. Server implementations that do not support objects, attributes, operations and profiles defined as optional can claim KMIP conformance, though they may be limited in terms of interoperability with other KMIP implementations...

    Section 6.0 ("Deferred KMIP Functionality") identifies missing items that have been judged candidates for future inclusion in the specification:

    • Registration of Clients
    • Client-requested specification of additional clients allowed to use a key
    • Registration of Notifications
    • Key Migration
    • Server to Server key management
    • Specification by client of key encoding
    • Multiple derived keys
    • XML encoding

  • Key Management Interoperability Protocol Use Cases . [aka "KMIP Use Cases for Proof of Concept Testing"] Draft Version 0.98. Revised February 10, 2009. 63 pages. Edited by Mathias Björkqvist (IBM Zurich Research Laboratory) and René Pawlitzek (IBM Zurich Research Laboratory). Contributors (From Section 2, "Acknowledgments"): David Babcock (HP), Paolo Bezoari (NetApp, Joseph Birr-Pixton (Thales/nCipher, Mathias Bjvrkqvist (IBM - Editor), John Clark (HP), Stan Feather (HP), Jon Geater (nCipher), Bob Griffin (EMC), Robert Haas (IBM), Jack Harwood (EMC), Walt Hubis (LSI), Vlad Libershteyn (HP), Mark Lin (EMC/RSA), Brian Metzger (HP), Madhav Mutalik (EMC/RSA), Anthony Nadalin (IBM), Reni Pawlitzek (IBM - Editor), Subhash Sankuratripati (NetApp Martin Skagen (Brocade), Bruce Rich (IBM), Parameswaran Seshan (EMC/RSA), John Tattan (EMC), Karla Thomas (Brocade).

    "The purpose of this document is to describe use cases to demonstrate the Key Management Interoperability Protocol (KMIP). The use cases shall indicate if all concepts within the protocol are sound and can be used to implement typical scenarios in real life. These use cases are not intended to fully test an implementation of KMIP. Thus, the use-cases do not contain typical QA scenarios which would stress an implementation. The use cases are based on Version 0.98 of the protocol. Message exchange: The message exchange between clients and the server to test the following use-case scenarios shall happen with TLV encoding over the HTTP transport. Use cases are provided for: (1) Centralized Management. Basic functionality use cases test the basic features of KMIP including key and template creation, attribute functionality, access methods, and batch operation [Use-case: Create / Destroy, Use-case: Register / Create / Get attributes / Destroy, Use-case: Create / Locate / Get / Destroy, Use-case: Dual client use-case, ID Placeholder linked Locate and Get batch]; Use case 'asynchronous locate' tests the asynchronous capabilities of KMIP using locate. (2) Key life cycle support [Usecase: revoke scenario]. (3) Auditing and reporting. Use case: 'get usage allocation scenario'tests the usage management functionality of KMIP. (4) Key Interchange, Key Exchange [Use case: Import of a Third-party Key] (5) Vendor Extensions. These use cases test the handling of unknown message extensions with vendor-specific content. (6) Asymmetric keys: Creation of keys using 'Create Key Pair' operation, locating pair using Link attribute. (7) Key Roll-over: These use-cases test manual key roll-over using the 'Re-key' operation. In particular, they test the formatting of the Re-key command, the handling and server-side processing of the various Time attributes and the setting of some other attributes that are not automatically copied from the existing key to the new key. (8) Archival: These use cases test archiving and locating keys using the off-line indicator. The Archive and Recover operations may be performed asynchronously, in which case the client must Poll the server until the operations complete. The client must also indicate in the request that it supports asynchronous responses..."

  • Key Management Interoperability Protocol (KMIP) FAQ Document . Version 0.98. Revised February 10, 2009. 2 pages. Produced by representatives from Brocade, EMC, HP, IBM, LSI, Netapp, Seagate, and Thales. This document supplies answers to twelve (12) KMIP frequently asked questions.

KMIP TC Charter and Call for Participation

This text is adapted from the full text of the Charter and Call for Participation, which contains detailed information on how to join as an OASIS Member, how to join the KMIP TC, and how to gain TC voting rights as of the First TC Meeting. References are provided to the canonical source files for the 'Call for Participation' in plain text format. See also, earlier, the KMIP TC (Draft) Charter Proposal.

Contents

Charter and Call For Participation: OASIS KMIP Technical Committee

TC Name

OASIS Key Management Interoperability Protocol (KMIP) Technical Committee

Statement of Purpose

The KMIP Technical Committee will develop specification(s) for the interoperability of key management services with key management clients. The specifications will address anticipated customer requirements for key lifecycle management (generation, refresh, distribution, tracking of use, life-cycle policies including states, archive, and destruction), key sharing, and long-term availability of cryptographic objects of all types (public/private keys and certificates, symmetric keys, and other forms of "shared secrets") and related areas.

Scope

The initial goal is to define an interoperable protocol for standard communication between key management servers, and clients and other actors which can utilize these keys. Secure key management for TPMs (Trusted Platform Modules) and Storage Devices will be addressed. The scope of the keys addressed is enterprise-wide, including a wide range of actors: that is, machine, software, or human participants exercising the protocol within the framework. Actors for KMIP may include:

  • Storage Devices
  • Networking Devices
  • Personal devices with embedded storage (e.g., Personal Computers, Handheld Computers, Cell Phones)
  • Users
  • Applications
  • Databases
  • Operating Systems
  • Input/Output Subsystems
  • Management Frameworks
  • Key Management Systems
  • Agents

Out of Scope

Out of scope areas include:

  • Implementation specific internals of prototypes and products
  • Multi-vendor Key Management facility mirrors or clusters
  • Definition of an architectural design for a central enterprise key management or certificate management system other than any necessary models, interfaces and protocols strictly required to support interoperability between Actors in the multi-vendor certificate and key management framework
  • Framework interfaces not dedicated to secure key and certificate management
  • Certain areas of functionality related to key management are also outside the scope of this technical committee, in particular registration of clients, server-to-server communication and key migration
  • Bindings other than tag-length-value wire protocol and XSD-based encodings

List of Deliverables

The deliverables for the KMIP Technical Committee are anticipated to include the following:

  • Revised KMIP Specification v0.98. This provides the normative expression of the protocol, including objects, attributes, operations and other elements. A Committee Specification is scheduled for completion within twelve (12) months of the first TC meeting.

  • Revised KMIP Usage Guide v0.98. This provides illustrative and explanatory information on implementing the protocol, including authentication profiles, implementation recommendations, conformance guidelines and security considerations. A Committee Specification is scheduled for completion within twelve (12) months of the first TC meeting.

  • Revised KMIP Use Cases and Test Cases v0.98. This provides sample use cases for KMIP, test cases for implementing those use cases, and examples of the protocol implementing those test cases. A Committee Specification is scheduled for completion within twelve (12) months of the first TC meeting.

  • Revised KMIP Frequently Asked Questions. This document provides guidance on what KMIP is, the problems it is intended to address and other frequently asked questions.

KMIP, as defined in the above deliverables, will be scoped to include the following:

1) Comprehensive Key and Certificate Lifecycle Management Framework

A. Lifecycle Management Framework to Include:

  1. Provisioning of Keys and Certificates
    1. Creation
    2. Distribution
    3. Exchange/Interchange
    4. Auditing
  2. Reporting
  3. Logging (Usage tracking)
  4. Backup
  5. Restore
  6. Archive
  7. Update/Refresh
  8. Management of trust mechanisms between EKCLM (Enterprise Key and Certificate Lifecycle Management) actors only as necessary to support EKCLM

B. Comprehensive Key and Certificate Policy Framework to include:

  1. Creation
  2. Distribution
  3. Exchange/Interchange
  4. Auditing
  5. Reporting
  6. Logging (Usage tracking)
  7. Backup
  8. Restore
  9. Archive
  10. Update/Refresh
  11. Expectation of Policy Enforcement
    1. At endpoints
    2. At Key Manager
    3. At intermediaries between endpoints and Key Manager facility

C. Interoperability between Machine Actors in performing all aspects of A) and B), and addressing:

  1. pre-provisioning and late binding of keys and certificates
  2. support for hierarchical or delegation or direct models
  3. actor discovery and enrollment as necessary to support ECKLM
  4. key, certificate and policy migration
  5. audit and logging facilities

D. General Capabilities may include:

  1. Secure and Robust Mechanisms, Techniques, Protocols and Algorithms
  2. Recovery capabilities, only as needed by interoperable interfaces, anticipating power failure, or other common failures of automated Actors
  3. Forward compatibility considerations
  4. Interface to Identity Management facilities as necessary for A) and B)
  5. Interface to Enterprise Directory facilities as necessary for A) and B)

2) KMIP TC will also support activities to encourage adoption of KMIP.

This would likely include:

  • Interoperability sessions to test effectiveness of the specification
  • Reference implementations of KMIP functionality

OASIS IPR Mode

IPR Mode under which the TC will operate:

The KMIP TC is anticipated to operate under RF on RAND IPR Mode.

Audience

Anticipated audience or users.

KMIP is intended for the following audiences:

  • Architects, designers and implementers of providers and consumers of enterprise key management services.

Language

Work group business and proceedings will be conducted in English.

Non-Normative Information

Similar Work

Identification of similar or applicable work.

Similar work is currently underway in several other organizations:

  • OASIS EKMI TC. We see KMIP TC as addressing a broader scope than the primarily symmetric key focused EKMI, providing a more comprehensive protocol in which SKSML can potentially participate.

  • IEEE P1619.3. We see KMIP TC as addressing a broad scope than the primarily storage-related P1619.3.

  • TCG Infrastructure Working Group. We see KMIP TC as addressing a broader scope than the primarily TPM related TCG IWG.

  • IETF Keyprov. We see KMIP TC as addressing a broader scope than the primarily mobile-related IETF Keyprov.

KMIP TC intends to establish liaisons with each of these organizations and may also establish liaisons with other organizations that are identified as focused on similar or applicable work.

First Meeting

Date, time, and location of the first meeting:

The date for the first meeting is April 24th 2009, from 9am PDT until 5pm PDT, to be held as a Face-to-Face meeting in San Francisco in conjunction with the RSA Conference [URI. See details: Friday, 24-April-2009. Time: 09:00am - 05:00pm PDT. Meeting Logistics: West Mezzanine 274/276 in the Moscone Convention Center in San Francisco for Friday 24-April-2009. A special code is available for a free conference pass for those not otherwise registered. Dial-in information for those not able to attend in person will be posted.]

Meeting Schedule

Projected ongoing meeting.

Conference calls will be held weekly, to be sponsored by one or more of the companies proposing the KMIP TC. These conference calls will be complemented by the following:

  • Face to face meetings as determined by the KMIP TC.
  • General communication will be via email reflectors with archiving provided by the KMIP TC.
  • KMIP TC progress will be communicated via a KMIP TC web page.
  • The KMIP TC will communicate (conference calls, joint working sessions, etc.) with external groups as appropriate.
  • The KMIP TC will communicate (conference calls, joint working sessions etc.) with internal OASIS groups (other TCs) as appropriate.

TC Supporters

Names, electronic mail addresses, and membership affiliations of at least Minimum Membership:

Convenor

The name of the Convenor who must be an Eligible Person:

Robert Griffin (EMC)

Affiliated OASIS Member Section

The name of the Member Section with which the TC intends to affiliate, if any:

The KMIP TC intends to affiliate with the IDtrust Member Section.

Contributions to the TC

List of contributions of existing technical work that the proposers anticipate will be made to this TC:

FAQ Document

Frequently Asked Questions (FAQ) document:

See preceding list of contributions.

Specification Working Title

Proposed working title and acronym for the specification(s) to be developed by the TC:

  • KMIP Specification
  • KMIP Usage Guide
  • KMIP Use Cases and Test Cases
  • KMIP FAQ

Source: KMIP TC Call for Participation

KMIP Announcement from Industry Partners

From the complete text of the announcement by the developers of the KMIP Version 0.98 specification: "Leading Organizations Unveil New Interoperability Specification for Encryption Key Management to Aid IT Security, Compliance and Data Recovery. Brocade, EMC, HP, IBM, LSI, Seagate, and Thales Work to Remove Barriers to Encryption Across Data Center Systems by Submitting New Specification to OASIS."

See also the announcement as published by EMC/RSA, HP, IBM (English, German), LSI, nCipher, and Thales e-Security.

February 12, 2009.

Brocade, HP, IBM, LSI, RSA — The Security Division of EMC, Seagate, and Thales (formerly nCipher) today announced the creation of a jointly developed specification for enterprise key management that is engineered to dramatically simplify how companies encrypt and safeguard information. The companies — leaders in enterprise computing, storage, and security — developed the Key Management Interoperability Protocol (KMIP) in response to customers' needs to enable the widespread use of encryption. The companies intend to submit KMIP to OASIS (Organization for the Advancement of Structured Information Standards) for advancement through the organization's open standards process.

KMIP was developed by HP, IBM, RSA, and Thales to meet the compelling needs of today's enterprise data centre environments, with Brocade, LSI, and Seagate joining the effort. All seven companies will now be devoting time and resources to OASIS for ongoing development.

According to IDC [1], 44 percent of enterprises plan to encrypt more than 75 percent of their data by 2009, and one of the top two issues related to deploying encryption is the ability to recover the data [2].

"The use of encryption is widely recognized as the best method for protecting valuable information and enabling compliance with industry and government regulations," says Charles Kolodgy, research director at IDC. "Time and time again, our research shows the primary barrier to the widespread use of encryption is the fear that encrypted data will be lost — slowing the adoption of encryption. Users are demanding strong key management systems and advancing this work through the open standards process offers tangible benefits for vendors, developers and enterprises alike."

Companies often deploy separate encryption and key management systems for different business uses, such as laptops, storage, databases and applications, and until now cumbersome — often manual — efforts were necessary to generate, distribute, vault, expire, and rotate encryption keys. This has resulted in increased costs for IT, difficulty meeting audit and compliance requirements, and lost data.

"The IT community is asking for open standards and interoperability to help meet the increasing demand for encryption," says Laurent Liscia, executive director of OASIS. "We applaud Brocade, HP, IBM, LSI, RSA, Seagate, and Thales for choosing to advance KMIP through the open standards process, and we encourage others in the security community — both users and providers — to participate in the standardization of this very important work."

Developed by leading enterprise storage, systems and security vendors, KMIP is designed to provide a single, comprehensive protocol for communication between enterprise key management services and encryption systems. Brocade, HP, IBM, LSI, RSA, Seagate, and Thales are committed to delivering KMIP-enabled solutions. By taking advantage of KMIP-enabled software and devices, companies will be able to cut operational costs and reduce risk by removing redundant, incompatible key management processes.

Streamlined key management is essential in a wide variety of data management processes. For example, the data recovery process requires locating encryption keys quickly even for tapes created weeks or months earlier. At the same time, this efficiency must not impact the security of keys or violate corporate policies regarding how keys are stored and distributed . KMIP enables vendors to address this need for enterprise-wide key management, providing customers with better data security and decreased expenditures on multiple key management products and operations.

KMIP is the first specification for enterprise key management that is ready for adoption. It was developed to support other industry standardization efforts and is complementary to application-specific standards projects such as IEEE 1619.3 (for storage needs) and OASIS EKMI (for XML needs).

About the Key Management Interoperability Protocol (KMIP)

KMIP enables key lifecycle management. KMIP can be used by both legacy and new encryption applications, supporting symmetric keys, asymmetric keys, digital certificates, and other "shared secrets." KMIP offers developers templates to simplify the development and use of KMIP-enabled applications.

KMIP defines the protocol for encryption client and key management server communication. Key lifecycle operations supported include generation, submission, retrieval, and deletion of cryptographic keys. Vendors intend to deliver KMIP-enabled encryption applications that support communication with compatible KMIP key management servers.

More information can be found at: http://xml.coverpages.org/KMIP/.

[1] IDC, Data Protection Study: Data Encryption Option, Document #207606, June 2007
[2] IDC, IDC Encryption Usage Survey, Document #213646, August 2008

About EMC

EMC Corporation (NYSE: EMC) is the world's leading developer and provider of information infrastructure technology and solutions that enable organizations of all sizes to transform the way they compete and create value from their information. Information about EMC's products and services can be found at www.EMC.com.

EMC Canada (http://www.EMC2.ca), headquartered in Toronto with nine offices from coast to coast, is a wholly owned subsidiary of EMC Corporation.

About Brocade

Brocade (Nasdaq: BRCD) develops extraordinary networking solutions that enable today's complex, data-intensive businesses to optimize information connectivity and maximize the business value of their data. For more information, visit http://www.brocade.com.

About HP

HP, the world's largest technology company, simplifies the technology experience for consumers and businesses with a portfolio that spans printing, personal computing, software, services and IT infrastructure. More information about HP (NYSE: HPQ) is available at http://www.hp.com/.

About IBM

For more information, please visit www.ibm.com.

About LSI

LSI Corporation (NYSE: LSI) is a leading provider of innovative silicon, systems and software technologies that enable products, which seamlessly bring people, information and digital content together. The company offers a broad portfolio of capabilities and services including custom and standard product ICs, adapters, systems and software that are trusted by the world's best known brands to power leading solutions in the Storage and Networking markets. More information is available at http://www.lsi.com.

About RSA

RSA, The Security Division of EMC, is the premier provider of security solutions for business acceleration, helping the world's leading organizations succeed by solving their most complex and sensitive security challenges. RSA's information-centric approach to security guards the integrity and confidentiality of information throughout its lifecycle — no matter where it moves, who accesses it or how it is used. RSA offers industry-leading solutions in identity assurance and access control, data loss prevention, encryption & key management, compliance and security information management and fraud protection. These solutions bring trust to millions of user identities, the transactions that they perform, and the data that is generated. For more information, please visit http://www.rsa.com and http://www.emc.com.

About Seagate

Seagate is the worldwide leader in the design, manufacture and marketing of hard disk drives and storage solutions, providing products for a wide-range of applications, including Enterprise, Desktop, Mobile Computing, Consumer Electronics and Branded Solutions. Seagate's business model leverages technology leadership and world-class manufacturing to deliver industry-leading innovation and quality to its global customers, with the goal of being the time-to-market leader in all markets in which it participates. The company is committed to providing award-winning products, customer support and reliability to meet the world's growing demand for information storage. Seagate can be found around the globe and at http://www.seagate.com.

For more information about Seagate's Self-Encrypting Drive security solutions, visit http://www.sedsecuritysolutions.com.

About Thales

Thales is a leading international electronics and systems group, addressing defense, aerospace and security markets worldwide. Thales's leading-edge technology is supported by 22,000 R&D engineers who offer a capability unmatched in Europe to develop and deploy field-proven mission-critical information systems. To this end, the group's civil and military businesses develop in parallel and share a common base of technologies to serve a single objective: the security of people, property and nations. The group builds its growth on its unique multi-domestic strategy based on trusted partnerships with national customers and market players, while leveraging its global expertise to support local technology and industrial development. Thales employs 68,000 people in 50 countries with 2007 revenues of € 12.3 billion. See: http://www.thalesgroup.com.

Related Key Management Initiatives

The Key Management Interoperability Protocol (KMIP) is one of several cryptographic key management specifications. Related initiatives include the following:

  • ANSI X9 Financial Industry Standards. The Accredited Standards Committee X9 (ASC X9) has the mission to develop, establish, maintain, and promote standards for the Financial Services Industry in order to facilitate delivery of financial services and products. Key management in the ANSI X9 context means key generation, key distribution, key life cycle facility requirements, modes, IVs (cipher initial values), and message formats. ANSI X9 has published many specifications in the key management space, for: [1] Key Management Protocols (e.g., X9.69 Framework for Key Management Extensions, X9.70 Symmetric Key Distribution Using Public Key, X9.73 Cryptographic Message Syntax, X9.77 Public Key Infrastructure Protocols) [2] Retail Key Management: (e.g., X9.24 Symmetric Key Management, X9.65 Triple Data Encryption Algorithm (TDEA) Implementation, X9.69 Key Extensions) [3] Public Key Cryptography: (e.g., X9.30 Public Key Cryptography Using Irreversible Algorithms (1-2), X9.31 Digital Signatures Using Reversible Public Key Cryptography).

  • DMTF Security Modeling Working Group. The DMTF Security [Modeling] Working Group is creating Credential Profiles, where a Profile is a specification that normatively defines the data model interface between a WBEM Server and a WBEM Client. This includes Abstract and Specialized Profiles. DSP 1082 Credential Management Profile (Abstract Profile) provides a capability to represent and manage credentials in a managed system. Use case: Definition for the generic CIM model for managing different credentials. DSP 1096 Certificate Management Profile (Specialized Profile) provides capability to represent and manage X509 certificates. Use cases: (1) Import/management of asymmetric keys; (2) Management of key stores; (3) PKS#10 Request for certificate signing requests (CSR) generation; (4) Export/import/management of X509 certificates and certificate revocation lists (CRL)... (Examples) Import Asymmetric Key to Keystore, Import and Export X509 Certificates...

  • GlobalPlatform Key Management System. GlobalPlatform provides a universally recognized and globally implemented suite of smart card specifications, together with market and application specific configurations of those specifications and supporting documents... The Systems Committee's Key Management System (KMS) Working Group seeks "(1) to define interfaces between Key Management Systems (KMS), enabling control of key usage and ensuring interoperability between systems that share keys during the lifecycle of GlobalPlatform cards and applications; (2) To develop, maintain and evolve the KMS Requirements Specification..." The document GlobalPlatform Key Management System Functional Requirements (Version 1.0, November 2003) is available from the GP Systems Specifications repository.

  • IEEE P1619.3 Security in Storage Working Group (SISWG), Key Management. The IEEE Security in Storage Working Group (SISWG) is working on standards related to encrypted storage media, including both encryption and key management. Membership is open to anyone... IEEE Project P1619.3: "Key Management" was approved in February 2007 to develop a Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data. This project was chartered through December 31, 2011. The goals of the Key Management group are to: (1) Create a standard that allows secure interchange of encryption keys between devices that encrypt stored data and devices that manage keys; (2) Understand existing standards and use where possible to expedite the creation of this standard; (3) Raise public awareness of P1619.3 and encourage adoption; (4) Facilitate interchange by providing open source reference implementations. On February 18, 2009, Matt Ball announced the availability of IEEE P1619.3/D6, edited by Bob Lockhart. The draft is available for comment through March 20, 2009. Details: IEEE P1619.3/D6. Draft Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data, prepared by the IEEE Security in Storage Working Group of the Computer Society Information Assurance Committee (Unapproved IEEE Standards Draft, 90 pages).

  • IETF Provisioning of Symmetric Keys (KEYPROV) Working Group. The scope of this IETF working group is "to define protocols and data formats necessary for provisioning of symmetric cryptographic keys and associated attributes. The group is considering use cases related to use of Shared Symmetric Key Tokens. Other use cases may be considered for the purpose of avoiding unnecessary restrictions in the design and ensure the potential for future extensibility..." As of 2009-02, the IETF KEYPROV Working Group was co-chaired by Phillip Hallam-Baker (Verisign) and Hannes Tschofenig (NSN - FI/Espoo) within the IETF Security Area, directed by Tim Polk (NIST) and Pasi Eronen (Nokia). I-Ds have been produced for the protocol ("Dynamic Symmetric Key Provisioning Protocol - DSKPP") and two container formats ("Symmetric Key Package Content Type", "Portable Symmetric Key Container - PSKC"). IETF KEYPROV Working Group Description: "Current developments in deployment of Shared Symmetric Key (SSK) tokens have highlighted the need for a standard protocol for provisioning symmetric keys. The need for provisioning protocols in PKI architectures has been recognized for some time. Although the existence and architecture of these protocols provides a feasibility proof for the KEYPROV work assumptions built into these protocols mean that it is not possible to apply them to symmetric key architectures without substantial modification. In particular, the ability to provision symmetric keys and associated attributes dynamically to already issued devices such as cell phones and USB drives is highly desirable. The working group will develop the necessary protocols and data formats required to support provisioning and management of symmetric key authentication tokens, both proprietary and standards based."

  • ISO/IEC 11770: Key Management. ISO/IEC 11770 is concerned with the management of cryptographic keys. SO/IEC 11770-1:1996 Information technology — Security techniques — Key management — Part 1: Framework defines a general model of key management that is independent of the use of any particular cryptographic algorithm; it dentifies the objective of key management, basic concepts and key management services. Other parts include ISO/IEC 11770-2:2008 Information technology — Security techniques — Key management — Part 2: Mechanisms using symmetric techniques. Part 2 specifies a series of 13 mechanisms for establishing shared secret keys using symmetric cryptography. These mechanisms address three different environments for the establishment of shared secret keys: point-to-point key establishment schemes, mechanisms using a Key Distribution Centre (KDC), and techniques that use a Key Translation Centre (KTC). ISO/IEC 11770-3:2008 Information technology — Security techniques — Key management — Part 3: Mechanisms Using Asymmetric Techniques. Part 3 defines key management mechanisms based on asymmetric cryptographic techniques. It specifically addresses the use of asymmetric techniques to achieve the following goals. ISO/IEC 11770-4:2006 Information technology — Security techniques — Key management — Part 4: Mechanisms based on weak secrets. Part 4 defines key establishment mechanisms based on weak secrets, i.e., secrets that can be readily memorized by a human, and hence secrets that will be chosen from a relatively small set of possibilities.

  • KeyGen2: Key Provisioning/Management Standards Proposal. KeyGen2 is an individual standardization initiative with the goal of creating a scheme allowing any issuer of authentication, signature, and encryption keys to use mobile phones as the primary vehicle. The long-term target of the effort is combining this system with complementary mobile phone technologies such as NFC (Near Field Communication) which can make phones work as "better smart cards". KeyGen2 has mainly been developed by former RSA engineer Anders Rundgren. KeyGen2 is currently in early beta and can be tested at the public site: http://keycenter.webpki.org. KeyGen2 is meant to be deployed as Open Source, currently with Google's Android as the initial target: Android Keystore V2. A forward-looking description of this project in the making could be something like using Android as the vehicle that will eventually thwart the current userid/password explosion on the Internet but there are several other useful, more short-term and down-to-earth targets as well, including OTP (One Time Password) generation and secure key storage. KeyGen2 is based on XML Security and Internet-browser extensions. Unlike most other efforts in this area, KeyGen2 is targeting consumers using phones for on-line banking, e-government services, and eventually, through the use of "virtual" credit-cards, also for payments..."

  • National Institute of Standards and Technology (NIST). U.S. National Institute of Standards and Technology (NIST) publications on security (including encryption and key management) have played a prominent role for many years, especially for government applications. FIPS Publications are issued by NIST after approval by the Secretary of Commerce pursuant to Section 5131 of the Information Technology Reform Act of 1996 (Public Law 104-106) and the Federal Information Security Management Act of 2002 (Public Law 107-347). NIST Special Publications in the 800 series present documents of general interest to the computer security community. The Special Publication 800 series was established in 1990 to provide a separate identity for information technology security publications. This Special Publication 800 series reports on ITL's research, guidelines, and outreach efforts in computer security, and its collaborative activities with industry, government, and academic organizations. NIST Special Publication 800-57 provides cryptographic key management guidance. It consists of three (3) parts. Part 1 provides general guidance and best practices for the management of cryptographic keying material. Part 2 provides guidance on policy and security planning requirements for U.S. government agencies. Finally, Part 3 provides guidance when using the cryptographic features of current systems. The KMIP specification definition of the Managed Object State attribute (also Section 2.12 of the Usage Guide 'Key Life-cycle and Key State') clarifies that the KMIP Specification describes the key life-cycle model based on the [six] NIST 800-57 key state definitions, supported by the KMIP protocol."

  • OASIS Enterprise Key Management Infrastructure (EKMI) Technical Committee. The OASIS EKMI TC was chartered in December 2006 to "define symmetric key management protocols, including those for (1) Requesting a new or existing symmetric key from a server; (2) Requesting policy information from a server related to caching of keys on the client; (3) Sending a symmetric key to a requestor, based on a request; (4) Sending policy information to a requestor, based on a request; (5) Other protocol pairs as deemed necessary. In addition, the TC set out goals to document use cases, produce test suites, provide guidance on how a symmetric key-management infrastructure may be secured using asymmetric keys, and provide input on how such enterprise key-management infrastructures may be managed, operated and audited..." The TC work was launched with the contribution of Symmetric Key Services Markup Language from StrongAuth, Inc. as draft proposal for the EKMI protocol, supported by a working implementation of this protocol. The open source StrongKey is a building block in an Enterprise Key Management Infrastructure (EKMI), with the goal of centrally managing symmetric encryption keys. The EKMI TC operates under the Royalty-Free (RF) on Limited Terms Mode of the OASIS IPR Policy. In January 2009, the EKMI TC released Symmetric Key Services Markup Language (SKSML) Version 1.0 as a Committee Specification. This specification "defines the first (1.0) version of the Symmetric Key Services Markup Language (SKSML), an XML-based messaging protocol, by which applications executing on computing devices may request and receive symmetric key-management services from centralized key-management servers, securely, over networks. Applications using SKSML are expected to either implement the SKSML protocol, or use a software library — called the Symmetric Key Client Library (SKCL) — that implements this protocol. SKSML messages are transported within a SOAP layer, protected by a Web Services Security (WSS) header and can be used over standard HTTP securely..."

  • Sun Crypto Key Management System (KMS). In February 2009, Sun Microsystems announced the release of an open source key management technology, described as "the world's first generic communication protocol between a Key Manager and an encrypting device." The release terms enable partners to adopt this protocol to securely handle encryption keys without additional licensing. The protocol is implemented as a complete toolkit and is downloadable from the OpenSolaris website. According to the announcement, "Governments, finance, healthcare, retail and other vertical markets need to comply with current regulatory laws that create mandates to protect sensitive stored data. To support these requirements, this protocol is available to customers using the Sun StorageTek KMS 2.0 Key Manager and Sun StorageTek T9840D, T10000A, T10000B Enterprise Drives, as well as Sun StorageTek HP LTO4 drives shipped in Sun libraries. A number of additional partners are developing products based on this protocol, including EMC, whose RSA security division has talked about releasing it as an option on their RKM Key Manager... By releasing the Sun protocol as Open Source, Sun is taking a major step towards unifying [key management] technology. Sun continues to work with partners in the industry and with appropriate standards bodies such as IEEE 1619.3 Working Group and OASIS to further develop and formalize the interface as an industry standard. RSA is currently developing a solution using this protocol to work with their RKM key manager. IBM drive division is working on supporting this protocol for their IBM LTO4 drive shipped in Sun Libraries. Additionally, Sun has shared this protocol with numerous other industry partners including computer OEMs, back up application providers, disk array and switch manufacturers..."

  • Trusted Computing Group: Key Management Services Subgroup. The Trusted Computing Group (TCG) Storage Workgroup formed a Key Management Services Subgroup (KMSS) to provide a specific method to manage keys necessary for use in the environment defined by the TCG Storage Specification. The goals of the TCG Key Management Services Subgroup (KMSS) are to: (1) Develop a uniform approach to managing keys across a variety of storage devices; (2) Define an extensible set of key management operations to nurture and sustain encrypted data and its associated keys; (3) Define key management audit operations that may be required to securely record all key management operations; (4) Leverage existing protocols and techniques, for example [i] Support the TCG Storage Specification, [ii] Secure Communications, [iii] Authentication, [iv]Discovery, [v] Any existing and applicable standards; (5) Define procedures, protocols, and client APIs as needed to implement these goals..." KMSS is addressing: Key management services (KMS), KMS use cases, KMS device/host secure communication, KMS device/host authentication, KMS device/host capability negotiation, KMS key policy specification, and KMS audit logs. KMSS protocols will allow the host platform or application to perform the following operations and services with trusted storage devices: Requesting key generation; Key usage; Storage of keys; Retrieving keys; Modifying keys; Searching for keys; Key access rights; Disabling of keys; Destruction of keys. KMSS and P1619.3 are cooperating to avoid overlap.

  • W3C XML Key Management (XKMS). The W3C XML Key Management (XKMS) Activity was organized to specify protocols for distributing and registering public keys, suitable for use with the standard for XML Signatures defined by W3C and the Internet Engineering Task Force (IETF) and its companion standard for XML Encryption. The XKMS specification became a W3C Recommendation in June 2005, and has two parts: the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS). X-KISS allows a client to delegate part or all of the tasks required to process XML Signature 'ds:KeyInfo' elements to an XKMS service. A key objective of the protocol design is to minimize the complexity of applications using XML Signature. By becoming a client of the XKMS service, the application is relieved of the complexity and syntax of the underlying PKI used to establish trust relationships, which may be based upon a different specification such as X.509/PKIX, SPKI, or PGP. By design, the XML Signature specification does not mandate use of a particular trust policy. X-KRSS describes a protocol for registration and subsequent management of public key information. A client of a conforming service may request that the registration service bind information to a public key. The information bound may include a name, an identifier or extended attributes defined by the implementation.

KMIP Specification Version 1.0

KMIP OASIS Standard

On October 14, 2010, OASIS announced the approval of the Key Management Interoperability Protocol (KMIP) Version 1.0 as an OASIS Standard. Developed through a collaboration of more than thirty (30) vendors and end user organizations, KMIP enables communication between key management systems and cryptographically-enabled applications, including email, databases, and storage devices.

See also:

KMIP Candidate OASIS Standard Specifications

On September 01, 2010, OASIS announced that members of the Key Management Interoperability Protocol (KMIP) Technical Committee had submitted two approved Committee Specification documents for consideration at OASIS Standard maturity level. Balloting for the two specifications was scheduled for September 16-30, 2010. Note also at CS 01 level: Key Management Interoperability Protocol Usage Guide Version 1.0 (provides illustrative information on using the protocol) and Key Management Interoperability Protocol Use Cases Version 1.0 (provides samples of protocol messages corresponding to a set of defined test cases).

KMIP Committee Drafts Approved for First Public Review

On November 05, 2009, the OASIS KMIP Technical Committee voted to accept four specification documents at Committee Draft level and release them for public review. Public review was announced for December 01, 2009 through January 30, 2010. KMIP TC Members may send feedback to the TC discussion list, and others may submit comments via the TC Comment List.

KMIP General References: Drafts, Presentations, News, Blogs, Commentary

Principal References

Prev: Oracle Beehive Object Model Proposed for Standardization in OASIS ICOM TC.
Next: Charter Proposed for OASIS Emergency Management Adoption Technical Committee.
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Created: February 27, 2009. Modified: November 23, 2010.
News: Cover Stories Previous News Item Next News Item


Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

Newsletter Subscription
Newsletter Archives
[画像:Bottom Globe Image]

Document URI: http://xml.coverpages.org/ni2009-02-27-a.html — Legal stuff
Robin Cover, Editor: robin@oasis-open.org

AltStyle によって変換されたページ (->オリジナル) /