Key Management Interoperability Protocol

2TBD (Key Management Interoperability 3Protocol Usage Guide)

4Editor’s Draft 0.98

528 July29 April 2009

6Specification URIs: 7This Version: 8 TBD.html 9 TBD.doc (Authoritative) 10 TBD.pdf 11Previous Version: 12 TBD.html 13 TBD.doc (Authoritative) 14 TBD.pdf 15Latest Version: 16 TBD.html 17 TBD.doc 18 TBD.pdf 19Technical Committee: 20 OASIS Key Management Interoperability Protocol (KMIP) TC 21Chair(s): 22 Robert Griffin 23 Anthony Nadalin 24Editor(s): 25 Indra Fitzgerald 26Related work: 27 This specification replaces or supersedes: 28  None 29 This specification is related to: 30  TBD 31Declared XML Namespace(s): 32 TBD 33Abstract: 34 This document is intended to complement the Key Management Interoperability Protocol 35 Specification by providing guidance on how to implement the Key Management Interoperability 36 Protocol (KMIP) most effectively to ensure interoperability.

1kmip-1.0-ug-ed-0.98 289 April July 2009 2Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 1 of 26 37Status: 38 This document was last revised or approved by the Key Management Interoperability Protocol TC 39 on the above date. The level of approval is also listed above. Check the “Latest Version” or 40 “Latest Approved Version” location noted above for possible later revisions of this document. 41 Technical Committee members should send comments on this specification to the Technical 42 Committee’s email list. Others should send comments to the Technical Committee by using the 43 “Send A Comment” button on the Technical Committee’s web page at http://www.oasis- 44 open.org/committees/kmip/. 45 For information on whether any patents have been disclosed that may be essential to 46 implementing this specification, and any offers of patent licensing terms, please refer to the 47 Intellectual Property Rights section of the Technical Committee web page (http://www.oasis- 48 open.org/committees/kmip/ipr.php. 49 The non-normative errata page for this specification is located at http://www.oasis- 50 open.org/committees/kmip/.

52Copyright © OASIS® 2009. All Rights Reserved. 53All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual 54Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. 55This document and translations of it may be copied and furnished to others, and derivative works that 56comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, 57and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice 58and this section are included on all such copies and derivative works. However, this document itself may 59not be modified in any way, including by removing the copyright notice or references to OASIS, except as 60needed for the purpose of developing any document or deliverable produced by an OASIS Technical 61Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must 62be followed) or as required to translate it into languages other than English. 63The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 64or assigns. 65This document and the information contained herein is provided on an "AS IS" basis and OASIS 66DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 67WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 68OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 69PARTICULAR PURPOSE. 70OASIS requests that any OASIS Party or any other party that believes it has patent claims that would 71necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, 72to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to 73such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that 74produced this specification. 75OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of 76any patent claims that would necessarily be infringed by implementations of this specification by a patent 77holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR 78Mode of the OASIS Technical Committee that produced this specification. OASIS may include such 79claims on its website, but disclaims any obligation to do so. 80OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 81might be claimed to pertain to the implementation or use of the technology described in this document or 82the extent to which any license under such rights might or might not be available; neither does it represent 83that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to 84rights in any document or deliverable produced by an OASIS Technical Committee can be found on the 85OASIS website. Copies of claims of rights made available for publication and any assurances of licenses 86to be made available, or the result of an attempt made to obtain a general license or permission for the 87use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS 88Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any 89information or list of intellectual property rights will at any time be complete, or that any claims in such list 90are, in fact, Essential Claims. 91The names "OASIS", [insert specific trademarked names and abbreviations here] are trademarks of 92OASIS, the owner and developer of this specification, and should be used only to refer to the organization 93and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, 94while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis- 95open.org/who/trademark.php for above guidance.

971 Introduction ...... 6 98 1.1 Document Roadmap ...... 6 99 1.2 Goals and Requirements ...... 6 100 1.3 Notational Conventions ...... 6 101 1.4 Namespaces ...... 6 102 1.5 Terminology ...... 6 103 1.6 Normative References ...... 6 104 1.7 Non-normative References ...... 6 105 1.8 Compliance ...... 6 1062 Assumptions ...... 7 107 2.1 Island of Trust ...... 7 108 2.2 Message Security ...... 7 109 2.3 State-less Server ...... 7 110 2.4 Extensible Protocol ...... 7 111 2.5 Support for Cryptographic Objects ...... 7 112 2.6 Client-Server Message-based Model ...... 7 113 2.7 Synchronous and Asynchronous Messages ...... 8 114 2.8 Support for “Intelligent Clients” and “Key Using Devices” ...... 8 115 2.9 Batched Requests and Responses ...... 8 116 2.10 Reliable Message Delivery ...... 8 117 2.11 Large Responses ...... 8 118 2.12 Key Life-cycle and Key State ...... 8 1193 KMIP Profiles ...... 8 120 3.1 SSL/TLS Profile (Mandatory) ...... 9 121 3.1.1 Mandatory cipher suites ...... 9 122 3.1.2 Discouraged cipher suites ...... 9 123 3.2 HTTPS Profile ...... 10 1244 Usage Guidelines ...... 10 125 4.1 Authentication ...... 10 126 4.2 Authorization for Revoke, Recover, Destroy and Archive Operations ...... 10 127 4.3 Using Notify and Put Operations ...... 11 128 4.4 Usage Allocation ...... 11 129 4.5 Key State and Times ...... 11 130 4.6 Template ...... 13 131 4.7 Archive Operations ...... 13 132 4.8 Message Extensions ...... 13 133 4.9 Unique Identifiers ...... 13 134 4.10 Result Message Text ...... 13 135 4.11 Certificate Transitions ...... 13 136 4.12 Query ...... 13 137 4.13 Canceling Asynchronous Operations ...... 14 138 4.14 Multi-instance Hash ...... 14

10kmip-1.0-ug-ed-0.98 289 April July 2009 11Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 4 of 26 139 4.15 Returning Related Objects ...... 14 140 4.16 Reducing Multiple Requests through Use of Batch ...... 14 141 4.17 Maximum Message Size ...... 14 142 4.18 Using Offset in Re-key and Re-certify Operations ...... 15 143 4.19 Locate Queries ...... 15 144 4.20 ID Placeholder ...... 16 145 4.21 Using Wrapped Keys with KMIP ...... 17 146 4.21.1 Encrypt-only Example with a Symmetric Key ...... 17 147 4.21.2 Encrypt-only Example with an Asymmetric Key ...... 18 148 4.21.3 MAC-only Example with an HMAC Key ...... 18 149 4.22 Object Group ...... 19 150 4.23 Certify and Re-certify ...... 19 151 4.24 Registering a Key Pair ...... 19 152 4.25 Non-Cryptographic Objects ...... 19 1535 Conformance ...... 20 1546 Deferred KMIP Functionality ...... 20 155A. Acronyms ...... 22 156B. Acknowledgements ...... 23 157C. Revision History ...... 24 1581 Introduction ...... 6 159 1.1 Document Roadmap ...... 6 160 1.2 Goals and Requirements ...... 6 161 1.3 Notational Conventions ...... 6 162 1.4 Namespaces ...... 6 163 1.5 Terminology ...... 6 164 1.6 Normative References ...... 6 165 1.7 Non-normative References ...... 6 166 1.8 Compliance ...... 6 1672 Assumptions ...... 7 168 2.1 Island of Trust ...... 7 169 2.2 Message Security ...... 7 170 2.3 State-less Server ...... 7 171 2.4 Extensible Protocol ...... 7 172 2.5 Support for Cryptographic Objects ...... 7 173 2.6 Client-Server Message-based Model ...... 7 174 2.7 Synchronous and Asynchronous Messages ...... 8 175 2.8 Support for “Intelligent Clients” and “Key Using Devices” ...... 8 176 2.9 Batched Requests and Responses ...... 8 177 2.10 Reliable Message Delivery ...... 8 178 2.11 Large Responses ...... 8 179 2.12 Key Life-cycle and Key State ...... 8 1803 KMIP Profiles ...... 8 181 3.1 SSL/TLS Profile (Mandatory) ...... 9 182 3.1.1 Mandatory cipher suites ...... 9 183 3.1.2 Discouraged cipher suites ...... 9 13kmip-1.0-ug-ed-0.98 289 April July 2009 14Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 5 of 26 184 3.2 HTTPS Profile ...... 10 1854 Usage Guidelines ...... 10 186 4.1 Authentication ...... 10 187 4.2 Authorization for Revoke, Recover, Destroy and Archive Operations ...... 10 188 4.3 Using Notify and Put Operations ...... 11 189 4.4 Usage Allocation ...... 11 190 4.5 Key State and Times ...... 11 191 4.6 Template ...... 13 192 4.7 Archive Operations ...... 13 193 4.8 Message Extensions ...... 13 194 4.9 Unique Identifiers ...... 13 195 4.10 Result Message Text ...... 13 196 4.11 Certificate Transitions ...... 13 197 4.12 Query ...... 13 198 4.13 Canceling Asynchronous Operations ...... 14 199 4.14 Multi-instance Hash ...... 14 200 4.15 Returning Related Objects ...... 14 201 4.16 Reducing Multiple Requests through Use of Batch ...... 14 202 4.17 Maximum Message Size ...... 14 203 4.18 Using Offset in Re-key and Re-certify Operations ...... 15 204 4.19 Locate Queries ...... 15 205 4.20 ID Placeholder ...... 16 206 4.21 Using Wrapped Keys with KMIP ...... 17 207 4.21.1 Encrypt-only Example with a Symmetric Key ...... 17 208 4.21.2 Encrypt-only Example with an Asymmetric Key ...... 18 209 4.21.3 MAC-only Example with an HMAC Key ...... 18 210 4.22 Object Group ...... 19 211 4.23 Certify and Re-certify ...... 19 212 4.24 Registering a Key Pair ...... 19 213 4.25 Non-Cryptographic Objects ...... 19 2145 Conformance ...... 20 2156 Deferred KMIP Functionality ...... 20 216A. Acronyms ...... 22 217B. Acknowledgements ...... 23 218C. Revision History ...... 24 219 220 221Tables 222Table 1: ID Placeholder Input and Output for KMIP Operations ...... 17 223Table 1: ID Placeholder Input and Output for KMIP Operations ...... 17 224

16kmip-1.0-ug-ed-0.98 289 April July 2009 17Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 6 of 26 2251 Introduction 226This Key Management Interoperability Protocol Usage Guide is intended to complement the Key 227Management Interoperability Protocol Specification by providing guidance on how to implement the Key 228Management Interoperability Protocol (KMIP) most effectively to ensure interoperability. In particular, it 229includes the following guidance: 230  Clarification of assumptions and requirements that drive or influence the design of KMIP and 231 implementation of KMIP-compliant key management. 232  Definition of required and optional profiles for authentication and communication privacy between 233 KMIP participants (clients and servers). 234  Specific recommendations for implementation of particular KMIP functionality. 235  Clarification of mandatory and optional capabilities for conformant implementations. 236  Functionality considered for inclusion in KMIP V1.0 but deferred to subsequent versions of the 237 standard. 238Further assistance for implementing KMIP is provided by the KMIP Use Cases for Proof of Concept 239Testing document that describes a set of recommended test cases and provides the TTLV 240(Type/Tag/Length/Value) format for the message exchanges defined by those use cases.

2411.1 Document Roadmap 242 TBD

2431.2 Goals and Requirements 244 TBD

2451.3 Notational Conventions 246 TBD

2471.4 Namespaces 248 TBD

2491.5 Terminology 250 TBD

2511.6 Normative References 252 TBD

2531.7 Non-normative References 254 TBD

2551.8 Compliance 256 TBD

19kmip-1.0-ug-ed-0.98 289 April July 2009 20Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 7 of 26 2572 Assumptions 258The section describes assumptions that underlie the KMIP protocol and implementation of clients and 259servers that utilize the protocol.

2602.1 Island of Trust 261 Clients are necessarily given key material but they must only use that keying material for the 262 purposes explicitly listed in the delivery payload. Clients that ignore these instructions and use the 263 keys in ways not explicitly allowed by the server are non-compliant. There is no requirement for 264 the key management system, however, to enforce this behavior.

2652.2 Message Security 266 KMIP relies on TLS/SSL to authenticate the client and on the underlying protocol to provide 267 confidentiality, integrity, message authentication and protection against replay attack. KMIP offers 268 a wrapping mechanism for Key Value that does not rely on the transport the messages travel 269 over; this is intended for importing or exporting managed objects.

2702.3 State-less Server 271 The protocol operates on the assumption that the server is state-less, which means that there is 272 no concept of “sessions” inherent in the protocol. State-less server operation is much more 273 reliable and easier to implement, and is consistent with possible implementation scenarios, such 274 as web-services-based servers. This does not mean that the server itself maintains no state, only 275 that the protocol does not require this.

2762.4 Extensible Protocol 277 The protocol provides for “private” or vendor-specific extensions, which allow for differentiation 278 among vendor implementations. However, any objects, attributes and operations included in an 279 implementation must always be implemented as specified, regardless of whether they are 280 optional or required.

2812.5 Support for Cryptographic Objects 282 The protocol supports all reasonable key management system related cryptographic objects. This 283 list currently includes: 284  Symmetric Keys 285  Split (multi-part) Keys 286  Asymmetric Key Pairs and their components 287  Digital Certificates 288  Derived Keys 289  Secret Data 290  Opaque (non-interpretable) cryptographic objects

2912.6 Client-Server Message-based Model 292 The protocol operates primarily in a client-server, message-based model (the exceptions are the 293 Put and Notify operations). This means that most protocol exchanges are initiated by a client 294 sending a request message to a server, which then sends a reply to the client. The protocol also 295 provides optional mechanisms to allow for unsolicited notification of events to clients, and

22kmip-1.0-ug-ed-0.98 289 April July 2009 23Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 8 of 26 296 unsolicited delivery of cryptographic objects to clients, that is, a “push” model. These latter 297 features are optionally supported by servers and clients. Clients must register in order to receive 298 such events/notifications. Registration is implementation specific and not described in the 299 specification.

3002.7 Synchronous and Asynchronous Messages 301 The protocol allows two modes of operation. Synchronous (mandatory) operations are those in 302 which each request from a client sends a request and waits for a response from the server. 303 Polled Asynchronous operations (optional) are those in which the client sends a request, the 304 server responds with a “pending” status and the client polls the server for the completed response 305 and completion status. Server implementations may choose not to support the Polled 306 Asynchronous feature of the protocol.

3072.8 Support for “Intelligent Clients” and “Key Using Devices” 308 The protocol supports intelligent clients, such as end-user workstations, which are capable of 309 requesting all of the functions of KMIP. It also allows subsets of the protocol, and possible 310 alternate message representations, in order to support less capable devices which only need a 311 subset of the features of KMIP.

3122.9 Batched Requests and Responses 313 The protocol contains a mechanism for sending batched requests and receiving batched 314 responses, to allow for higher throughput on operations that deal with a large number of entities, 315 e. g. requesting dozens or hundreds of keys from a server at one time, and performing operations 316 in a group. An option is provided to continue processing requests after an earlier one fails or to 317 stop processing the remaining requests in the batch. Note that there is no option to treat an 318 entire batch as atomic, that is, if a request in the batch fails then preceding requests in the batch 319 are undone or rolled back. A special ID Placeholder is provided in KMIP to allow related requests 320 in a batch to be pipelined.

3212.10 Reliable Message Delivery 322 The reliable message delivery function is relegated to the transport protocol, and not part of the 323 key management protocol itself.

3242.11 Large Responses 325 For requests that are capable of large responses, a mechanism in the protocol allows a client to 326 specify in a request the maximum allowed size of a response. The server must be able to indicate 327 in a response to such a request that the response would have been too large and therefore not 328 returned.

3292.12 Key Life-cycle and Key State 330 The KMIP Specification describes the key life-cycle model, based on the NIST 800-57 key state 331 definitions, supported by the KMIP protocol. Particular implications of the key life-cycle model in 332 terms of defining time-related attributes of objects are discussed in section 4.5below.

3333 KMIP Profiles 334This section describes two KMIP profiles. These profiles describe mechanisms by which authentication 335and communications privacy are established outside KMIP. Both profiles must be supported by any 336conforming implementation of KMIP.

25kmip-1.0-ug-ed-0.98 289 April July 2009 26Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 9 of 26 3373.1 SSL/TLS Profile (Mandatory) 338 Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are 339 cryptographic protocols that provide secure communications for data transfers, using 340 cryptographic mechanisms to provide both authentication of participants and privacy of the 341 communication. SSL 2.0 has known security issues and all current implementations of HTTP/S 342 support more recent protocols. Therefore this profile prohibits the use of SSL 2.0 and 343 recommends SSL 3.1 or TLS 1.0. 344 345 In this profile, a KMIP client and server must use SSL/TLS to negotiate a mutually-authenticated 346 connection by using a handshaking procedure. 347 1. The handshake begins when a client connects to a TLS-enabled server requesting a 348 secure connection, presenting a list of supported cryptographic functions. 349 2. From this list, the server picks the strongest cipher and hash function that it also supports 350 and notifies the client of the decision. 351 3. The server sends back its identification in the form of a digital certificate and requests a 352 certificate from the client. 353 4. The client validates the server certificate. In order to generate the session keys used for 354 the secure connection, the client then encrypts a random number with the server's public 355 key, and sends the result to the server, along with the requested client certificate. 356 5. From the random number, both parties generate key material for encryption and 357 decryption of all subsequent communication. 358 Mutual authentication ensures that both the client and the server provide their certificates during 359 the handshake. However, the client certificate used in the SSL session may also be included in 360 any client-initiated KMIP messages between the client and server as the value of the Credentials 361 object in the message, with credential type of certificate. Similar, the server certificate used in the 362 SSL session may be included in any server-initiated KMIP messages between the client and 363 server as the value of the Credentials object in the message, with credential type of certificate. 364 In SSL and TLS, choices of algorithms are expressed as cipher suites. The following subsections 365 specify cipher suites that are required or discouraged, respectively. The use of any other cipher 366 suite not discussed below is optional.

367 3.1.1 Mandatory cipher suites 368 The mandatory cipher suites for the SSL/TLS profile are: 369  A TLS-capable instance must support TLS_RSA_WITH_AES_128_CBC_SHA 370  An SSL-capable instance must support SSL_RSA_WITH_AES_128_CBC_SHA

371 3.1.2 Discouraged cipher suites 372 As discussed in “WS-I Basic Security Profile”, the cipher suites defined in the SSL and 373 TLS specifications that use anonymous Diffie-Hellman (i. e. those that have DH_anon in 374 their symbolic name) are vulnerable to man-in-the-middle attacks. It is recommended that 375 such cipher suites be avoided. This profile recommends against the use of the following 376 cipher suites due to their lack of confidentiality services: 377  SSL_RSA_WITH_NULL_SHA 378  TLS_RSA_WITH_NULL_SHA 379  SSL_RSA_WITH_NULL_MD5 380  TLS_RSA_WITH_NULL_MD5

28kmip-1.0-ug-ed-0.98 289 April July 2009 29Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 10 of 26 381 It is also recommended that cipher suites that use 40 or 56 bit keys be avoided, due to 382 their relative ease of compromise through brute-force attack.

3833.2 HTTPS Profile 384 Hypertext Transfer Protocol over Secure Socket Layer or https is a URI (Universal Resource 385 Indicator) scheme used to indicate a secure HTTP connection, requiring a different default TCP 386 port (443) and an additional encryption and authentication layer, implemented by SSL/TLS, 387 between HTTP and TCP. The establishment of the trust relationship between the client and 388 server is the same as in the SSL/TLS profile described above. 389 As in the SSL/TLS profile, mutual authentication must be performed. The client certificate used in 390 the SSL session may be included in any client-initiated KMIP messages between the client and 391 server as the value of the Credentials object in the message, with credential type of certificate. 392 Similarly, the server certificate used in the SSL session may be included in any server-initiated 393 KMIP messages between the client and server as the value of the Credentials object in the 394 message, with credential type of certificate.

3954 Usage Guidelines 396This section provides guidance on using the functionality described in the Key Management 397Interoperability Protocol Specification.

3984.1 Authentication 399 As discussed in the Authentication section of the Key Management Interoperability Protocol 400 Specification, a conforming KMIP implementation must support mutual authentication of the client 401 and server as described in the SSL/TLS and HTTPS profiles in Section 3 of this Key Management 402 Interoperability Protocol Usage Guide. Other mechanisms for client and server authentication are 403 possible and optional for KMIP implementations. 404 The Credential attribute can be used for additional identification of a client. It does not, however, 405 assert that an identity has been authenticated. Therefore it should not be used as an alternative 406 to the transport-level authentication described above. 407 KMIP implementations that use other vendor-specific mechanisms for authenticating the client 408 and server may also use the Credential attribute to include additional identification information. 409 The Credential attribute may also be used for authentication of the client to the server, but only if 410 the communication is secured to prevent man-in-the-middle attacks that can result in replacement 411 of the credential attribute value. 412 If an “authentication not successful” error can be returned, it should be returned in preference to 413 any other result status. This prevents status code probing by a client that cannot authenticate. 414 Server decisions regarding which operations to reject if there is insufficiently strong authentication 415 of the client are not specified in the protocol. However, see Section 4.2 for recommendations 416 regarding particular operations for which authentication and authorization are particularly 417 important.

418 4.2 Authorization for Revoke, Recover, Destroy and Archive Operations 419 Neither authentication nor authorization is handled by the KMIP protocol directly. In particular, the 420 Credential attribute is not guaranteed to be an authenticated identity of the requesting client. 421 However, the mandatory profiles described in this KMIP Usage Guide describe how the client 422 identity must be established for KMIP-compliant implementations. This authentication must be 423 performed for all KMIP operations, with the single exception of the Query operation. 424 Certain operations that may be requested by a client via KMIP, particularly Revoke, Recover, 425 Destroy and Archive can have a significant impact on the availability of a key, on server 31kmip-1.0-ug-ed-0.98 289 April July 2009 32Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 11 of 26 426 performance and on key security. When a server receives a request for one of these operations, it 427 should ensure that the client has established an authenticated identity (see the profiles in Section 428 3). It should also ensure that client requesting the operation is an object creator, security officer or 429 other identity authorized to issue the request. It may also require additional authentication to 430 ensure that the object owner or security officer has issued that request. Even with such 431 authentication and authorization, requests for these operations should be considered only a “hint” 432 to the key management system, which may or may not choose to act upton this request.

4334.3 Using Notify and Put Operations 434 The Notify and Put operations are the only operations in the KMIP protocol that are initiated by 435 the server rather than the client. As the functionality provided by these operations can be 436 accomplished through client-initiated requests (using a polling model from the client to request 437 notification, for example), these operations are optional for conforming KMIP implementations. 438 However, they provide a mechanism for optimized communication between KMIP servers and 439 clients and have therefore been included in the KMIP specification. 440 In using Notify and Put, the following constraints and guidelines must be observed: 441  Registration of the client with the server, such that the server knows how to locate the 442 client to which a Notify or Put is being sent and which events for the Notify are supported, 443 is required for Notify and Put operations. However, such registration is outside the scope 444 of the KMIP protocol. This also includes specification of whether a given client supports 445 Put and Notify, and what attributes may be included in a Put for a particular client. 446  Communication between the client and the server must be properly authenticated to 447 forestall man-in-the-middle attacks in which the client receives Notify or Put operations 448 from an unauthenticated server. Authentication for a particular client/server 449 implementation must at a minimum be accomplished using one of the mandatory 450 authentication mechanisms. Further strengthening of the client/server communications 451 integrity by means of signed message content and/or wrapped keys is recommended. 452 Attribute values other than “Last Changed Date” should not be included in a Notify to 453 minimize risk of exposure of attribute information. 454  In order to minimize possible divergence of key or state information between client and 455 server as a result of server-initiated communication, any client receiving Notify or Put 456 messages must return acknowledgements of these messages to the server. This 457 acknowledgement can be at communication layers below the KMIP layer, such as by 458 using transport-level acknowledgement provided in TCP/IP. 459  For client devices that are incapable of responding to messages from the server, 460 communication with the server must happen via a proxy entity that communicates with 461 the server, using KMIP, on behalf of the client. Communication between a proxy entity 462 and the client can be secured using other, potentially proprietary mechanisms.

463 

4644.4 Usage Allocation 465 Usage should be allocated and handled carefully since power outages or other types of client 466 failures (crashes) may render allocated usage lost. For example, in the case a key is used for 467 encryption of tape drives, such a loss of the usage allocation information following a client failure 468 during encryption may result in the necessity for the entire tape backup session to be re- 469 encrypted using a different key, if the server cannot allocate more usage. This can be addressed 470 through such approaches as, caching usage allocation information on stable storage at the client, 471 and/or having conservative allocation policies at the server (e.g., by keeping the maximum 472 possible usage allocation per client request moderate). In general, usage allocations should be as 473 small as possible; it is preferable to use multiple smaller allocation requests rather than a single 474 larger request, to minimize the likelihood of unused allocation.

34kmip-1.0-ug-ed-0.98 289 April July 2009 35Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 12 of 26 4754.5 Key State and Times 476 The KMIP specification provides a number of time-related attributes, including the following: 477  Initial Date: The date and time when the KMIP Managed Cryptographic Object was first 478 created or registered at the server 479  Activation Date: The date and time when the KMIP Managed Cryptographic Object may 480 begin to be used 481  Process Start Date: The date and time when an KMIP Managed Symmetric or 482 Asymmetric Key Object may begin to be used for process purposes 483  Protect Stop Date: The date and time when an KMIP Managed Symmetric or Asymmetric 484 Key Object may no longer be used for protect purposes 485  Deactivation Date: The date and time when the KMIP Managed Cryptographic Object 486 may no longer be used for any purpose, except for decryption, signature verification, or 487 unwrapping, but only under extraordinary circumstances and when special permission is 488 granted 489  Destroy Date: The date and time when the KMIP Managed Cryptographic Object was 490 destroyed 491  Compromise Occurrence Date: The date and time when the KMIP Managed 492 Cryptographic Object was first believed to be compromised 493  Compromise Date: The date and time when the KMIP Managed Cryptographic Object is 494 entered into the compromised state 495  Archive Date: The date and time when the KMIP Managed Object was placed in Off-Line 496 storage 497 These attributes apply to all KMIP Cryptographic Objects key-related objects (symmetric keys, 498 asymmetric keys, etc) with exceptions as noted in the KMIP specification. However, certain of 499 these attributes (such as Initial Date) cannot be specified in template-related objects. 500 In using these attributes, the following guidelines should be observed: 501  As discussed for each of these attributes in Section 3 of the KMIP Specification, a 502 number of these times are set once and cannot be modified by client or server. However, 503 several of the time attributes (particularly Activation Date, Protect Start Date, Process 504 Stop Date and Deactivation Date) can be set by the server and/or requested by the client. 505 Coordination of time-related attributes between client and server, therefore, is primarily 506 the responsibility of the server, as it establishes the key and manages its state. However, 507 special conditions related to time-related attributes, governing when the server accepts 508 client modifications to time-related attributes, may be negotiated by policy exchange 509 between the client and server, outside the Key Management Interoperability Protocol. 510 511 In general, state transitions will occur as a result of operational requests. However, clients 512 may need to specify times in the future for such things as Activation Date, Deactivation 513 Date and so on. 514 515 It is allowed in KMIP for clients to specify times in the past for such attributes as 516 Activation Date, Deactivation Date and so on. This is intended primarily for clients that 517 were disconnected from the server at the time the client performed that operation on a 518 given key. 519  It is valid to have a Deactivation Date when there is no Activation Date. This means, 520 however, that the key is not yet active even though its Deactivation Date has been 521 specified. A valid Deactivation Date must be greater than or equal to Activation Date.

37kmip-1.0-ug-ed-0.98 289 April July 2009 38Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 13 of 26 522  Protect Stop Date must be greater than or equal to Process Start Date. KMIP 523 implementations should consider specifying both these attributes, particularly for 524 symmetric keys, as a key may be needed for decryption (process) long after it is no 525 longer appropriate to use it for encryption of new objects (protect). 526  If a Destroy operation is performed, resulting in the Destroy Date being set, and the 527 object has not already been deactivated, the deactivation of the object must also be 528 performed prior to Destroy so that Destroy Date is greater than or equal to Deactivation 529 Date. Although not required, it is highly desirable to set other related attributes, such as 530 Protect Stop Date, if they have not already been set. 531 KMIP allows the specification of attributes on a per-client basis, such that a server could 532 maintain or present different set of attributes for different clients. This flexibility may be 533 necessary in some cases, such as when a server must maintain availability of a key for some 534 clients even after a key moved to inactive state for most clients. However, such an approach 535 can result in significant inconsistencies regarding the object state from the point of view of all 536 participating clients and should therefore be avoided. It is highly recommended that a server 537 maintain a consistent state for each object, across all clients that have or can request that 538 object.

5394.6 Template 540 A server can maintain different policy templates for different clients. As in the state transitions 541 described above, however, this practice is discouraged.

5424.7 Archive Operations 543 When the Archive operation is performed, it is recommended that an object identifier and a 544 minimal set of attributes be retained within the server for operational efficiency. In such a case, 545 the retained attributes may include Unique Identifier and State.

5464.8 Message Extensions 547 Any number of vendor-specific extensions may be included in the Message Extension optional 548 structure. This allows KMIP implementations to create multiple extensions to the protocol.

5494.9 Unique Identifiers 550 For clients which require unique identifiers in a special form (such as IBM tape drives requiring 551 12- byte IDs), out-of-band registration/configuration can be used to communicate this requirement 552 to the server.

5534.10 Result Message Text 554 KMIP specifies result status, result reason and result message as normative message contents. 555 For result status and result reason, the enumerations provided in the KMIP specification are the 556 normative values. The values for result message text, on the other hand, are implementation- 557 specific. In consideration of internationalization, it is recommended that any vendor 558 implementation of KMIP provide appropriate language support for return message. How a client 559 specifies the language for Result Messages is outside the scope of the KMIP.

5604.11 Certificate Transitions 561 There is a possible state transition for certificate objects that is not represented by the NIST state 562 transition diagram. Certificate suspension (or certificate hold) allows a certificate to be revoked 563 (certificate appears on a CRL with a revocation reason of “certificateHold”) and then reinstated 564 (certificate appears on a CRL with revocation reason of “removeFromCRL”). There is no facility in

40kmip-1.0-ug-ed-0.98 289 April July 2009 41Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 14 of 26 565 the SP 800-57 diagram to reinstate a deactivated/compromised object. This state transition can 566 be accomplished in KMIP by returning an object from Revoked to Active state. However, there is 567 no indication in the protocol that an object has undergone such a transition.

5684.12 Query 569 Query does not explicitly support client requests to determine what operations require 570 authentication. To determine whether an operation requires authentication, a client must request 571 that operation.

5724.13 Canceling Asynchronous Operations 573 If an asynchronous operation is cancelled, no information is returned in the result code regarding 574 any operations that may have been partially completed. Identification and remediation of partially 575 completed operations is the responsibility of the server. 576 It is the responsibility of the server to determine when to discard the status of asynchronous 577 operations. The determination of how long a server should retain the status of an asynchronous 578 operation is implementation-dependent and not defined by KMIP. 579 Once a client has received the status on an asynchronous operation other than “pending”, any 580 subsequent request for status of that operation may return either the same status as in a previous 581 polling request or an “unavailable” response. 582 It is the responsibility of the server to determine when to discard the status of asynchronous 583 operations. The determination of how long a server should retain the status of an asynchronous 584 operation is implementation-dependent and not defined by KMIP. 585 Once a client has received the status on an asynchronous operation other than “pending”, any 586 subsequent request for status of that operation may return either the same status as in a previous 587 polling request or an “unavailable” response.

5884.14 Multi-instance Hash 589 The Digest attribute contains the output of hashing a managed object such as a key or a 590 certificate. The server always generates the SHA-256 hash when the object is created or 591 generated. KMIP allows multiple digests to be associated with the same managed object. For 592 example, it is common practice for public trusted CAs to publish two digests (often referred to as 593 the fingerprint or the thumbprint) of their certificate one calculated using the SHA-1 algorithm and 594 another using the MD-5 algorithm. In this case, each digest would be calculated by the server 595 using a different hash algorithm.

5964.15 Returning Related Objects 597 The key block is intended to return a single object and associated attributes and other data. For 598 those cases in which multiple related objects are needed by a client, such as the private key and 599 the related certificate required by RACF and JKS, the client should issue multiple Get requests to 600 obtain these related objects.

6014.16 Reducing Multiple Requests through Use of Batch 602 KMIP supports batch operations in order to reduce the number of calls between the client and 603 server for related operations. For example, Locate and Get are likely to be commonly 604 accomplished within a single batch request. 605 KMIP does not ensure that batch operations are atomic on the server side. But such atomicity can 606 be implemented by the server and in such a case, the client can use the optional “undo” mode to 607 request roll-back for batch operations implemented as atomic transactions. However, support for 608 “undo” mode is not required by the protocol, nor is there a guarantee that a server that supports 43kmip-1.0-ug-ed-0.98 289 April July 2009 44Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 15 of 26 609 “undo” mode has effectively implemented atomic batches, such as by preventing interleaving of 610 batch requests. The use of “undo”, therefore, should be restricted to those cases in which the 611 client can be assured, through mechanisms outside of KMIP, of the server effectively supporting 612 atomicity for batch operations.

6134.17 Maximum Message Size 614 When a server is processing messages in a batch, it should compare the resultant message size 615 after each message with the specified maximum message size. If the message is too large, it 616 should prepare a maximum message size response at that point, rather than continuing with 617 operations in the batch. This increases the client’s ability to understand what operations have and 618 have not been completed. 619 When processing individual requests within the batch, the server that has encountered a 620 maximum message size error should not return attribute values or other information as part of the 621 response.

6224.18 Using Offset in Re-key and Re-certify Operations 623 Both the Re-key and the Re-certify operations allow the specification of an offset interval . 624 The Re-key operation allows the client to specify an offset interval for activation of the key. This 625 offset specifies the duration of time between the time the request is made and when the activation 626 of the key will occur. If an offset is specified, all other times for the new key will be determined 627 using the intervals from Activation Date to Process Start Date, Protect Stop Date, etc as defined 628 from the original key. 629 The Re-certify operations allows the client to specify an offset interval that indicates the difference 630 between the Initial Date of the new certificate and the Activation Date of the new certification. As 631 with Re-key, all other times for the certificate will be determined using the intervals as defined 632 from the original certificate.

6334.19 Locate Queries 634 Locate queries can be formulated to address any of the following conditions: 635  Exact match of a transition. Locate the key(s) that transitioned to a certain state at a 636 specified time (t). 637  Range match of a transition. Locate the key(s) that transitioned to a certain state at any 638 time between two specified times (t and t’). 639  Exact match of a state at a given instance. Locate the key(s) that are in a certain state at 640 a specified time (t). 641  Match of a state during a time range. Locate the key(s) that are in a certain state at any 642 time between two specified times (t and t’). 643  Match of a state at some point during a time range. Locate the key(s) that are in a certain 644 state at some time between two specified times (t and t’). In this case, the transition to 645 that state could have happened before the start of the specified time range. 646 This is accomplished by allowing any date/time attribute to be present either once (for an exact 647 match) or at most twice (for a range match). 648 For instance, if the state we are interested in is Active, the Locate queries would be the following 649 (corresponding to the bulleted list above): 650  Exact match of a transition: Locate ( ActivationDate(t) ) 651  Range match of a transition: Locate ( ActivationDate(t), ActivationDate(t') )

46kmip-1.0-ug-ed-0.98 289 April July 2009 47Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 16 of 26 652  Exact match of a state at a given instance: Locate ( ActivationDate(0), ActivationDate(t), 653 DeactivationDate(t+1), DeactivationDate(MAX_INT), CompromiseDate(t+1), 654 CompromiseDate(MAX_INT) ) This looks for keys that transitioned to an Active state 655 before t, and transitioned to Deactivated or Compromised after t (because we don't want 656 the keys that also transitioned to Deactivated or Compromised before t). The server 657 assumes that keys that don't have a DeactivationDate or CompromiseDate equivalent to 658 MAX_INT (i.e., infinite). 659  Match of a state during a time range: Locate ( ActivationDate(0), ActivationDate(t), 660 DeactivationDate(t'+1), DeactivationDate(MAX_INT), CompromiseDate(t'+1), 661 CompromiseDate(MAX_INT) ) 662  Match of a state at some point during a time range: Locate ( ActivationDate(0), 663 ActivationDate(t'-1), DeactivationDate(t+1), DeactivationDate(MAX_INT), 664 CompromiseDate(t+1), CompromiseDate(MAX_INT) ) 665 The queries would be similar for Initial Date, Deactivation Date, Compromise Date and Destroy 666 Date. 667 In the case of the Destroyed-Compromise state, there are two dates recorded: Destroy Date and 668 Compromise Date. For this state, the Locate operation would be expressed as follows: 669  Exact match of a transition: Locate ( CompromiseDate(t), State(Compromised) and 670 Locate ( DestroyDate(t), State(Compromised) ) KMIP doesn’t support the OR in the 671 Locate request, so two requests must be issued). 672  Range match of a transition: Locate ( CompromiseDate(t), CompromiseDate(t'), 673 State(Compromised) and Locate ( DestroyDate(t), DestroyDate(t'), State(Compromised) 674 ) 675  Exact match of a state at a given instance: Locate ( CompromiseDate(0), 676 CompromiseDate(t), DestroyDate(0), DestroyDate(t) ) nothing else needed since there is 677 no exit transition. 678  Match of a state during through a time range: Locate ( CompromiseDate(0), 679 CompromiseDate(t), DestroyDate(0), DestroyDate(t) ) 680  Match of a state at some point during a time range: Locate ( CompromiseDate(0), 681 CompromiseDate(t'-1), DestroyDate(0), DestroyDate(t'-1) )

6824.20 ID Placeholder 683 The table below shows the ID Placeholder input and output for various operations.

ID Placeholder ID Placeholder input output (in case of operation failure, a batch using ID Placeholder must stop) Create - new Object Create Key Pair - new Private Key (the new Public Key can be obtained in the batched via a Locate) Register - new Object Derive Key - (because there new Symmetric Key can be more than one object) Locate - Object

49kmip-1.0-ug-ed-0.98 289 April July 2009 50Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 17 of 26 Get Object no change Request Object Object no change Validate - - Get Attributes Object no change List/Modify/Add/Delete Activate Object no change Revoke Object no change Destroy Object no change Archive/Recover Object no change Certify Public Key new Certificate Re-certify Certificate new Certificate Re-key Symmetric Key new Symmetric Key Obtain Lease Object no change Get Usage Allocation Keys no change

685 Table 1: ID Placeholder Input and Output for KMIP Operations

6864.21 Using Wrapped Keys with KMIP 687 KMIP provides the option to import and get keys in wrapped format. Clients who wish to get acan 688 request the server to return a wrapped key byfrom the server are expected to includinge the Key 689 Wrapping Specification in the Get Request Payload. The wrapping method will identify the type of 690 mechanism used to wrap a key, but will not identify the algorithm or block cipher mode. These will 691 be extracted server can determine these from the attributes set for the specified Encryption Key 692 or MAC/Signing Key. If a key has multiple Cryptographic Parameters definedset, clients can 693 include the applicablepick one by including the parameters for the specified key in Key Wrapping 694 Specification. Clients also have the option to omit the parameters for the specified key and If 695 omitted, the server will choose the Cryptographic Parameter attribute with the lowest indexuse the 696 default parameters, i.e. those with the lowest index. 697 The Key Value includes both the Key Material and if requested in Key Wrapping Specification 698 certain attributes of the key. The Key Value can be encrypted, signed/MACed, or both encrypted 699 and signed/MACed (and vice versa). In addition, clients have the option to wrap the key block 700 according to standards, such as ANSI TR-31, or other standard or vendor-specific key wrapping 701 methods. 702 It is important to note that if Key Wrapping Specification is included in the Get Request Payload, 703 the Key Value may not necessarily be encrypted. If Wrapping Method is MAC/sign, the returned 704 Key Value will be in plaintext and the Key Wrapping Data will include the MAC or Signature of the 705 Key Value. 706 Prior to wrapping or unwrapping a key, the server shall verify that the wrapping key is allowed to 707 be used for the specified purpose. For example, if a symmetric key is used for key encryption, the 708 symmetric key must have the wrap bit set in Cryptographic Usage Mask. Similarly, if the client 709 registers a signed key, the server must verify that the Signature Key, as specified by the client 710 inside Key Wrapper Data, has the Verify bit set in Cryptographic Usage Mask.

52kmip-1.0-ug-ed-0.98 289 April July 2009 53Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 18 of 26 711 4.21.1 Encrypt-only Example with a Using Symmetric KeyWrapped 712 Keys 713 If a key is to be wrapped with the Cryptographic Usage Mask attribute using AES key 714 wrap, clients must include the following information in the Key Wrapping Specification: 715  Wrapping Method: Encrypt 716  Encryption Key Information 717 o Unique Key ID: Key ID of AES key 718 o Cryptographic Parameters: Block Cipher Mode is AES key 719 wrapNISTKeyWrap (not required if default block cipher mode for 720 wrapping key is AES key wrapNISTKeyWrap) 721  Attribute Name: Cryptographic Usage Mask 722 The Cryptographic Parameters attribute is required if multiple instances of Cryptographic 723 Parameters exist and the lowest index does not correspond to the NIST key wrap mode 724 of operation. The server shall verify that the AES wrapping key must has ve the 725 NISTKeyWrapAES key wrap set as an allowable Block Cipher Mode and that. the wrap 726 bit is set in Cryptographic Usage Mask. This must be verified by the server. 727 If the correct data was provided to the server and no conflicts exist, the server will AES 728 key wrap the Key Value, including both the Key Material and the Attribute objects, and 729 return the encrypted blob (octet string) inside the Key Block under Key Value. 730 The Key Wrapping Data includes the same data as specified in the Key Wrapping 731 Specification except for the Attribute Name.

732 4.21.2 Encrypt-only Example with an Asymmetric Key 733 If a key is to be wrapped with an RSA public key, clients shall include the following 734 information in the Key Wrapping Specification: 735  Wrapping Method: Encrypt 736  Encryption Key Information 737 o Unique Key ID: Key ID of RSA public key 738 o Cryptographic Parameters: 739 . Padding Method: OAEP 740 . Hashing Algorithm: SHA-256 741 The Cryptographic Parameters attribute is required if multiple instances of Cryptographic 742 Parameters exist for the wrapping key and the lowest index does not correspond to the 743 required padding method. The server shall verify that the specified Cryptographic 744 Parameters instance and the wrap bit in Cryptographic Usage Mask are set for the 745 corresponding wrapping key. 746 The Key Wrapping Data returned by the server includes the same data as specified in the 747 Key Wrapping Specification. 748 For both OAEP and PSS, KMIP currently assumes that the Mask Generation Function 749 (MGF) and Hash use the same underlying hash function as specified in Cryptographic 750 Parameters. The example above requires the server to use Hash SHA-256 and Mask 751 Generation Function MGF1 with SHA-256.

55kmip-1.0-ug-ed-0.98 289 April July 2009 56Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 19 of 26 752 4.21.3 MAC-only Example with an Using Wrapped KeysHMAC Key 753 If a key and Custom Attribute is to be MACed withA client that wishes to HMAC SHA-256, 754 the Key Value including a custom attribute must specify the following in Key Wrapping 755 Specification must be specified: 756  Wrapping Method: MAC/sign 757  MAC/Signature Key Information 758 o Unique Key ID: Key ID of HMAC SHA-256 759  Attribute Name: x-Nonce 760 For HMAC, no crypto parameters need to be specified. The algorithm set for the key 761 already identifies the hash function. The server shall verify that the HMAC key has the 762 MAC bit set in Cryptographic Usage Mask. Note that an HMAC key does not require the 763 “Wrap” function to be set. 764 The server will create an HMAC over the Key Value if the correct data was provided by 765 the client and no conflicts exist. The Key Value will be returned in plaintext and the Key 766 Block will include the following Key Wrapping Data: 767  Wrapping Method: MAC/sign 768  MAC/Signature Key Information 769  Unique Key ID: Key ID of HMAC SHA-256 770  MAC/Signature: HMAC of Key Value 771 In the example the custom attribute x-Nonce was included to help clients, who are relying 772 on the proxy model, to detect replay attacks. End-clients, who communicate with the key 773 management server, may not support SSL/TLS and may not be able to rely on the 774 message protection mechanisms provided by a security protocol. A custom attribute can 775 be created to hold a random number, counter, nonce, date, or time. The custom attribute 776 needs to be created before requesting the server to return a wrapped key and is 777 recommended to be set if clients frequently wrap/sign the same key with the same 778 wrapping/signing key.

7794.22 Object Group 780 The key management system may specify rules for the valid group names which may be created 781 by the client. Clients will be informed of such rules by a mechanism which is not specified by the 782 KMIP Specification. In the protocol, the group names themselves are character strings of no 783 specified format. Specific key management system implementations may choose to support 784 hierarchical naming schemes or other syntax restrictions on the names. Groups may be used to 785 associate objects for a variety of purposes. A set of keys used for a common purpose, but for 786 different time intervals, may be linked by a common Object Group. Servers may create 787 predefined groups and add objects to them independently of client requests.

7884.23 Certify and Re-certify 789 The key management system may contain multiple embedded CAs or may have access to 790 multiple external CAs. How the server routes a Certificate Request to a CA is vendor-specific and 791 outside the scope of KMIP. If the server requires and supports the capability for clients to specify 792 the CA to be used for signing a Certificate Request, then this information can be provided by 793 including the Certificate Issuer attribute in the Certify or Re-certify request.

58kmip-1.0-ug-ed-0.98 289 April July 2009 59Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 20 of 26 7944.24 Registering a Key Pair 795 During a Create Key Pair a Link Attribute is automatically created by the server for each object. 796 Certain attributes must be the same for both objects and will be set by the server while creating 797 the key pair. The KMIP protocol does not support an equivalent operation for registering a key 798 pair. Clients can register the objects independently and manually set the Link attributes to make 799 the server aware that these keys are associated with each other. When the Link attribute is set for 800 both objects, servers are recommended to verify that the registered objects indeed correspond to 801 each other and apply similar restrictions as if the key pair was created on the server. 802 Clients are encouraged to perform the following steps when registering a key pair: 803 1. Register the public key and set all required attributes 804 2. Register the private key and set all required attributes 805  Cryptographic Algorithm must be the same for both public and private key 806  Cryptographic Length must be the same for both public and private key 807  Cryptographic Parameters can be set; if set, the value must be the same for both 808 public and private key 809  Cryptographic Usage Mask must be set, but must not contain the same value for both 810 public and private key 811  Link must be set with Link Type Public Key Link and Linked Object Identifier of the 812 corresponding Public Key 813  Link must be set for the Public Key with Link Type Private Key Link and Linked 814 Object Identifier of the corresponding Private Key

8154.25 Non-Cryptographic Objects 816 The KMIP protocol allows clients to register Secret Data objects. Secret Data objects may include 817 passwords or data that will be used to derive keys. 818 KMIP defines Secret Data as Cryptographic Objects. Even if the object is not used for 819 cryptographic purposes, clients are still required to set certain attributes, such as Cryptographic 820 Usage Mask, for this object unless otherwise stated. Similarly, servers must set certain attributes 821 for this object, including Digest, State, and certain Date attributes even if the attributes seem 822 relevant only for cryptographic usages. 823

8245 Conformance 825Server implementations of the KMIP protocol must support all objects, attributes, operations and profiles 826not specified as “optional” in the KMIP Specification in order to be conformant to the specification. Server 827implementations that do not support objects, attributes, operations and profiles defined as “optional” can 828claim KMIP conformance, though they may be limited in terms of interoperability with other KMIP 829implementations. 830Client implementations of the KMIP protocol may implement any subset of the KMIP protocol. For 831example, a client may implement only the Get and Locate operations for symmetric keys. In order to claim 832conformance, however, such a client must implement all aspects of any elements of the protocol (objects, 833attributes, operations, profiles) that it claims to support. In the example of Get/Locate support for 834symmetric keys, therefore, a conforming client implementation must support all required attributes for 835symmetric keys.

61kmip-1.0-ug-ed-0.98 289 April July 2009 62Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 21 of 26 8366 Deferred KMIP Functionality 837The KMIP specification is currently missing items that have been judged candidates for future inclusion in 838the specification. These items currently include: 839  Registration of Clients. This would allow in-band registration and management of clients, which 840 currently can only be registered and/or managed using off-line mechanisms. 841  Client-requested specification of additional clients allowed to use a key. This requires coordinated 842 identities between the client and server, and as such is deferred until registration of clients is 843 addressed. 844  Registration of Notifications. This would allow clients to specify, using an in-band mechanism, 845 information and events that they wish to be notified of, and what mechanisms should be used for 846 such notifications, possibly including the configuration of pushed cryptographic material. This 847 functionality would assume Registration of Clients as a prerequisite. 848  Key Migration. This would standardize migration of keys from one HSM to another, using 849 mechanisms already in the protocol or ones added for this purpose. 850  Server to Server key management. This would extend the protocol to support communication 851 between key management servers in different key management domains, for purposes of 852 exporting and importing of cryptographic material and potentially policy information. 853  Specification by client of key encoding. KMIP does not currently allow the client to specify the 854 encoding in which a key should be returned; the server returns the key in whatever format it has 855 or otherwise determines it should be returned (such as through out-of-band client specification of 856 encoding). Client specification of encoding may be considered for the future. 857  Multiple derived keys. This would allow creation of multiple derived keys from one or more input 858 keys. Note, however, that the current version of KMIP provides the capability to derive multiple 859 keys and initialization vectors by creating a Secret Data object and specifying a cryptographic 860 length equal to the total length of the derived objects. 861  XML encoding. Expression of KMIP in XML rather than in type/tag/length/value may be 862 considered for the future. 863  Specification of Mask Generation Function. KMIP does not currently allow clients to specify the 864 Mask Generation Function and assumes that encryption or signature schemes, such as OAEP or 865 PSS, use MGF1 with the hash function as specified in the Cryptographic Parameters attribute. 866 Client specification of MGFs may be considered for the future. 867  Certificate creation without client-provided Certificate Request. This would allow clients to request 868 the server to perform the Certify or Re-certify operation from the specified key pair IDs without 869 providing a Certificate Request. 870  Server monitoring of client status. This would enable the transfer of information about the client 871 and its cryptographic module to the server. This information would enable the server to generate 872 alarms and/or disallow requests from a client running component versions with known 873 vulnerabilities. 874  Symmetric key pairs. Only a subset of the cryptographic usage bits of the Cryptographic Usage 875 Mask attribute may be permitted for keys distributed to a particular client. KMIP does not currently 876 address how to securely assign and determine the applicable cryptographic usage for a client. 877  Hardware-protected attribute. This attribute would allow clients and servers to determine if a key 878 can only be processed inside a secure cryptographic device such as an HSM. If this attribute is 879 set, the key can only exist in cleartext from inside a secure hardware device, and all security- 880 relevant attributes must be bound to it in such a way that they cannot be modified outside of such 881 a secure device.

64kmip-1.0-ug-ed-0.98 289 April July 2009 65Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 22 of 26 882  Alternative profiles for key establishment. Less capable end-clients may not be able to support 883 TLS and are required to use a proxy to communicate with the key management system. The 884 KMIP protocol does not currently support alternative profiles nor does it allow end-clients relying 885 on the proxy model to securely establish a key with the server.

67kmip-1.0-ug-ed-0.98 289 April July 2009 68Copyright © OASIS® 2009. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 23 of 26 8867 Acronyms 887The following abbreviations and acronyms are used in this document: 888AES - Advanced Encryption Standard specified in FIPS 197 889ANSI - American National Standards Institute 890CA - Certification Authority 891CBC - Cipher Block Chaining 892CRL - Certificate Revocation List 893DES - Data Encryption Standard 894DH - Diffie-Hellman 895HMAC - Keyed-Hash Message Authentication Code specified in FIPS 198 896HSM - Hardware Security Module 897HTTP - Hyper Text Transfer Protocol 898HTTP(S) - Hyper Text Transfer Protocol (Secure socket) 899ID - Identification 900IP - Internet Protocol 901JKS - Java Key Store 902KMIP - Key Management Interoperability Protocol 903MAC - Message Authentication Code 904MD5 - Message Digest 5 Algorithm 905MGF - Mask Generation Function 906NIST - National Institute of Standards and Technology 907RSA - Rivest, Shamir, Adelman (an algorithm) 908SHA-1 - Secure Hash Algorithm Revision One 909SP - Special Publication 910SSL - Secure Sockets Layer 911S/MIME - Secure/Multipurpose Internet Mail Extensions 912TCP - Transport Control Protocol 913TLS - Transport Layer Security 914TTLV - Tag, Type, Length, Value 915URI - Unique Resource Identifier 916WS-I - Web Services-Interoperability Organization 917XML - Extensible Markup Language

919The following individuals have participated in the creation of this specification and are gratefully 920acknowledged: 921Original Authors of the initial contribution: 922 David Babcock, HP 923 Steven Bade, IBM 924 Paolo Bezoari, NetApp 925 Mathias Björkqvist, IBM 926 Bruce Brinson, EMC 927 Christian Cachin, IBM 928 Tony Crossman, Thales/nCipher 929 Stan Feather, HP 930 Indra Fitzgerald, HP 931 Judy Furlong, EMC 932 Jon Geater, Thales/nCipher 933 Bob Griffin, EMC 934 Robert Haas, IBM 935 Timothy Hahn, IBM 936 Jack Harwood, EMC 937 Walt Hubis, LSI 938 Glen Jaquette, IBM 939 Jeff Kravitz, IBM 940 Michael McIntosh, IBM 941 Brian Metzger, HP 942 Anthony Nadalin, IBM 943 Elaine Palmer, IBM 944 Joe Pato, HP 945 René Pawlitzek, IBM 946 Subhash Sankuratripati, NetApp 947 Mark Schiller, HP 948 Martin Skagen, Brocade 949 Marcus Streets, Thales/nCipher 950 John Tattan, EMC 951 Karla Thomas, Brocade 952 Marko Vukolić , IBM 953 Steve Wierenga, HP 954Participants: 955 TBD

Revision Date Editor Changes Made ed-0.98 2009-04-29 Indra Fitzgerald Initial conversion of input document to OASIS format. ed-0.98 2009-07-xx Indra Fitzgerald Added clarifications, examples, and deferred items.