You are on page 1of 84

1

Key Management
Interoperability Protocol
Usage Guide Version 1.2

Committee Note Draft 01

31 October 2013

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

Specification URIs

2
3

1
2

This version:
http://docs.oasis-open.org/kmip/ug/v1.2/cnd01/kmip-ug-v1.2cnd01.doc (Authoritative)
http://docs.oasis-open.org/kmip/ug/v1.2/cnd01/kmip-ug-v1.2cnd01.html
http://docs.oasis-open.org/kmip/ug/v1.2/cnd01/kmip-ug-v1.2cnd01.pdf
Previous version:
N/A
Latest version:
http://docs.oasis-open.org/kmip/ug/v1.2/kmip-ug-v1.2.doc
(Authoritative)
http://docs.oasis-open.org/kmip/ug/v1.2/kmip-ugv1.2.html
http://docs.oasis-open.org/kmip/ug/v1.2/kmip-ug-v1.2.pdf
Technical Committee:
OASIS Key Management Interoperability Protocol (KMIP) TC
Chairs:
Robert Griffin (robert.griffin@rsa.com), EMC Corporation
Subhash Sankuratripati
(Subhash.Sankuratripati@netapp.com), NetApp
Editors:
Indra Fitzgerald (indra.fitzgerald@hp.com), HP
Judith Furlong (Judith.Furlong@emc.com), EMC Corporation
Related work:
This document replaces or supersedes:

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

34
Key Management Interoperability Protocol Usage Guide Version
35
1.1. Latest version. http://docs.oasis-open.org/kmip/ug/v1.1/kmip36
ug-v1.1.html.
37This document is related to:
38
Key Management Interoperability Protocol Specification Version
39
1.2. Latest version. http://docs.oasis-open.org/kmip/spec/v1.2/kmip40
spec-v1.2.html.
41
Key Management Interoperability Protocol Profiles Version 1.2.
42
Work in progress. To be published at: http://docs.oasis43
open.org/kmip/profiles/.
44
Key Management Interoperability Protocol Test Cases Version 1.2.
45
Latest version. http://docs.oasis-open.org/kmip/testcases/v1.2/kmip46
testcases-v1.2.html.
47
Key Management Interoperability Protocol Use Cases Version 1.2.
48
Work in progress. To be published at: http://docs.oasis49
open.org/kmip/usecases/.
50Abstract:
51This document is intended to complement the Key Management
52Interoperability Protocol Specification by providing guidance on how to
53implement KMIP most effectively to ensure interoperability and to
54address key management usage scenarios.
55KMIP v1.2 enhances the KMIP v1.1 standard (established in February
562013) by
571)
defining new functionality in the protocol to improve
58interoperability;
592)
defining additional Test Cases for verifying and validating the
60new functionality;
613)
providing additional information in the KMIP Usage Guide to
62
assist in effective implementation of KMIP in key management
63
clients and servers; and
644)
defining new profiles for establishing KMIP-compliant
65implementations.
66The Key Management Interoperability Protocol (KMIP) is a single,
67comprehensive protocol for communication between clients that
68request any of a wide range of encryption keys and servers that store
69and manage those keys. By replacing redundant, incompatible key
70management protocols, KMIP provides better data security while at the
71same time reducing expenditures on multiple products.
72Status:
73This document was last revised or approved by the OASIS Key
74Management Interoperability Protocol (KMIP) TC on the above date. The
75level of approval is also listed above. Check the Latest version
76location noted above for possible later revisions of this document.
5kmip-ug-v1.2-cnd01
6Non-Standards Track
7

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 2 of 84

[Type the document title]

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

77Technical Committee members should send comments on this


78document to the Technical Committees email list. Others should send
79comments to the Technical Committee by using the Send A Comment
80button on the Technical Committees web page at http://www.oasis81open.org/committees/kmip/.
82Citation format:
83When referencing this document the following citation format should
84be used:
85[kmip-ug-v1.2]
86Key Management Interoperability Protocol Usage Guide Version 1.2. 31
87October 2013. OASIS Committee Note Draft 01. http://docs.oasis88open.org/kmip/ug/v1.2/cnd01/kmip-ug-v1.2-cnd01.html.
89
90

92Copyright OASIS Open 2013. All Rights Reserved.


93All capitalized terms in the following text have the meanings assigned to
94them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy").
95The full Policy may be found at the OASIS website.
96This document and translations of it may be copied and furnished to others,
97and derivative works that comment on or otherwise explain it or assist in its
98implementation may be prepared, copied, published, and distributed, in
99whole or in part, without restriction of any kind, provided that the above
100copyright notice and this section are included on all such copies and
101derivative works. However, this document itself may not be modified in any
102way, including by removing the copyright notice or references to OASIS,
103except as needed for the purpose of developing any document or deliverable
104produced by an OASIS Technical Committee (in which case the rules
105applicable to copyrights, as set forth in the OASIS IPR Policy, must be
106followed) or as required to translate it into languages other than English.
107The limited permissions granted above are perpetual and will not be revoked
108by OASIS or its successors or assigns.
109This document and the information contained herein is provided on an "AS IS"
110basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
111INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
112INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY
113IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
114PURPOSE.
115
10kmip-ug-v1.2-cnd01
11Non-Standards Track
12

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 3 of 84

[Type the document title]

91

13

14

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

[Type the document title]

116

15kmip-ug-v1.2-cnd01
16Non-Standards Track
17

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 4 of 84

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

18

19

117Table
1181

of Contents

Introduction................................................................................................ 8

119 1.1 References (normative)...........................................................................8


120 1.2 References (non-normative)..................................................................11
1212

Assumptions............................................................................................. 12

122 2.1 Island of Trust........................................................................................ 12


123 2.2 Message Security.................................................................................. 12
124 2.3 State-less Server...................................................................................12
125 2.4 Extensible Protocol................................................................................12

127 2.6 Support for Cryptographic Objects........................................................12


128 2.7 Client-Server Message-based Model.....................................................13
129 2.8 Synchronous and Asynchronous Messages...........................................13
130 2.9 Support for Intelligent Clients and Key Using Devices....................13
131 2.10 Batched Requests and Responses.......................................................13
132 2.11 Reliable Message Delivery...................................................................14
133 2.12 Large Responses................................................................................. 14
134 2.13 Key Life-cycle and Key State...............................................................14
1353

Using KMIP Functionality..........................................................................15

136 3.1 Authentication....................................................................................... 15


137

3.1.1 Credential........................................................................................ 15

138

3.1.1.1 Username and Password Credential Type...........................................................................16


3.1.1.2 Device Credential Type.........................................................................................................16

139

140 3.2 Authorization for Revoke, Recover, Destroy and Archive Operations....18
141 3.3 Using Notify and Put Operations...........................................................19
142 3.4 Usage Allocation................................................................................... 19
143 3.5 Key State and Times.............................................................................. 20
144 3.6 Template............................................................................................... 21
20kmip-ug-v1.2-cnd01
21Non-Standards Track
22

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 5 of 84

[Type the document title]

126 2.5 Server Policy......................................................................................... 12

23

24

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

145

3.6.1 Template Usage Examples..............................................................22

146

3.6.1.1.1 Example of Registering a Template..............................................................................22


3.6.1.2 Example of Creating a Symmetric Key using a Template.....................................................23
3.6.1.3 Compatibility Note:............................................................................................................... 23

147
148

149 3.7 Archive Operations................................................................................24


150 3.8 Message Extensions..............................................................................24
151 3.9 Unique Identifiers.................................................................................. 24
152 3.10 Result Message Text............................................................................24
153 3.11 Query.................................................................................................. 24
154 3.12 Canceling Asynchronous Operations...................................................24
155 3.13 Multi-instance Hash............................................................................. 25
156 3.14 Returning Related Objects...................................................................25

158 3.16 Maximum Message Size......................................................................25


159 3.17 Using Offset in Re-key and Re-certify Operations................................26
160 3.18 ID Placeholder..................................................................................... 26
161 3.19 Key Block............................................................................................. 27
162 3.20 Object Group....................................................................................... 28
163 3.21 Certify and Re-certify..........................................................................29
164 3.22 Specifying Attributes during a Create Key Pair or Re-key Key Pair
165 Operation.................................................................................................... 30
166
167

3.22.1 Example of Specifying Attributes during the Create Key Pair


Operation................................................................................................. 30

168 3.23 Registering a Key Pair..........................................................................33


169 3.24 Non-Cryptographic Objects.................................................................34
170 3.25 Asymmetric Concepts with Symmetric Keys.......................................34
171 3.26 Application Specific Information..........................................................36
172 3.27 Mutating Attributes............................................................................. 36
173 3.28 Revocation Reason Codes...................................................................37
174 3.29 Certificate Renewal, Update, and Re-key............................................37
175 3.30 Key Encoding....................................................................................... 38
25kmip-ug-v1.2-cnd01
26Non-Standards Track
27

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 6 of 84

[Type the document title]

157 3.15 Reducing Multiple Requests through the Use of Batch........................25

28

29
176

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

3.30.1 Triple-DES Key Encoding................................................................38

177 3.31 Using the Same Asymmetric Key Pair in Multiple Algorithms..............39
178 3.32 Cryptographic Length of Asymmetric Keys.........................................39
179 3.33 Discover Versions................................................................................39
180 3.34 Vendor Extensions............................................................................... 40
181 3.35 Certificate Revocation Lists.................................................................40
182 3.36 Using the Raw Key Format Type.......................................................40
183 3.37 Use of Meta-Data Only (MDO) Keys.....................................................41
184 3.38 Cryptographic Service.........................................................................41
185 3.39 Passing Attestation Data.....................................................................42

187 3.41 Compromised Objects.........................................................................44


188 3.42 Elliptic Curve Cryptography (ECC) Algorithm Mapping........................44
1894

Applying KMIP Functionality.....................................................................49

190 4.1 Locate Queries...................................................................................... 49


191 4.2 Using Wrapped Keys with KMIP.............................................................50
192
193

4.2.1 Encrypt-only Example with a Symmetric Key as an Encryption Key


for a Get Request and Response..............................................................51

194
195

4.2.2 Encrypt-only Example with a Symmetric Key as an Encryption Key


for a Register Request and Response.......................................................52

196
197

4.2.3 Encrypt-only Example with an Asymmetric Key as an Encryption Key


for a Get Request and Response..............................................................53

198
199

4.2.4 MAC-only Example with an HMAC Key as an Authentication Key for a


Get Request and Response......................................................................53

200

4.2.5 Registering a Wrapped Key as an Opaque Cryptographic Object....54

201

4.2.6 Encoding Option for Wrapped Keys.................................................54

202 4.3 Interoperable Key Naming for Tape.......................................................55


203

4.3.1 Native Tape Encryption by a KMIP Client.........................................56

204

4.3.1.1 Method Overview.................................................................................................................. 56


4.3.1.2 Definitions.............................................................................................................................56
4.3.1.3 Implementation Example of Algorithm 1. Key identifier string to numeric direction
(Converting the ASI string to tape formats KAD)............................................................................56

205
206
207

30kmip-ug-v1.2-cnd01
31Non-Standards Track
32

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 7 of 84

[Type the document title]

186 3.40 Split Key.............................................................................................. 43

33

34
208
209
210

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .
4.3.1.4 Implementation Example of Algorithm 2. Numeric to key identifier string direction
(Converting tape formats KAD to ASI string)...................................................................................57
4.3.1.5 Usage Example.................................................................................................................... 57

211 4.4 Query Extension Information.................................................................60


212 4.5 Registering Extension Information........................................................61
213 4.6 Using KMIP for PGP Keys........................................................................61
214 4.7 KMIP Client Registration Models............................................................62
215

4.7.1 Manual Client Registration..............................................................63

216

4.7.2 Automated Client Registration........................................................64

217

4.7.3 Registering Sub-Clients Based on a Trusted Primary Client.............64

2185

Deprecated KMIP Functionality.................................................................66

219 5.1 KMIP Deprecation Rule..........................................................................66

221 5.3 PGP Certificate and Certificate Request Types......................................67


2226

Implementation Conformance..................................................................69

223Appendix A. Acknowledgements....................................................................70
224Appendix B. Acronyms...................................................................................73
225Appendix C. Table of Figures and Tables........................................................75
226Appendix D. Revision History.........................................................................76
227
228

35kmip-ug-v1.2-cnd01
36Non-Standards Track
37

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 8 of 84

[Type the document title]

220 5.2 Certificate Attribute Related Fields........................................................66

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

38

39

229Introduction
230This Key Management Interoperability Protocol Usage Guide Version 1.2 is intended to
231complement the Key Management Interoperability Protocol Specification [KMIP-Spec] by
232providing guidance on how to implement the Key Management Interoperability Protocol (KMIP)
233most effectively to ensure interoperability and to address key management usage scenarios. In
234particular, it includes the following guidance:

Clarification of assumptions and requirements that drive or influence the


design of KMIP and the implementation of KMIP-compliant key
management.
Specific recommendations for implementation of particular KMIP
functionality.
Clarification of mandatory and optional capabilities for conformant
implementations.

242Descriptions of how to use KMIP functionality to address specific key management usage
243scenarios or to solve key management related issues. A selected set of conformance profiles and
244authentication suites are defined in the KMIP Profiles specification [KMIP-Prof].

245Further assistance for implementing KMIP is provided by the KMIP Test Cases
246document [KMIP-TC] that describes a set of recommended test cases and
247provides the TTLV (Tag/Type/Length/Value) format for the message exchanges
248defined by those test cases.
2491.1 References (normative)
250[FIPS 180-4]

251Secure Hash Standard (SHS), FIPS PUB 180-4, March 2012,


252http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf
253[FIPS186-4]
254Digital Signature Standard (DSS). FIPS PUB 186-4. July 2013.
255http://csrc.nist.gov/publications/fips/fips186-3/fips_186-4.pdf
256
257[FIPS197]
258Advanced Encryption Standard (AES). FIPS PUB 197. November 26, 2001.
259http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
260
261[FIPS198-1]
262The Keyed-Hash Message Authentication Code (HMAC). FIPS PUB 198-1. July 2008.
263http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf
264

265[KMIP-Spec]
266Key Management Interoperability Protocol Specification Version 1.2,
267Committee Specification Draft 01. 12 September 2013. https://www.oasis268open.org/committees/document.php?document_id=50670&wg_abbrev=kmip
269
40kmip-ug-v1.2-cnd01
41Non-Standards Track
42

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 9 of 84

[Type the document title]

235
236
237
238
239
240
241

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

270[KMIP-Prof]
271Key Management Interoperability Protocol Profiles Version 1.2. Working Draft 02. 25 June 2013.
272https://www.oasis-open.org/committees/document.php?document_id=49689&wg_abbrev=kmip
273
274[PKCS#1]
275RSA Laboratories. PKCS #1 v2.1: RSA Cryptography Standard. June 14, 2002.
276http://www.rsa.com/rsalabs/node.asp?id=2125
277
278[PKCS#10]
279RSA Laboratories. PKCS #10 v1.7: Certification Request Syntax Standard. May 26, 2000.
280http://www.rsa.com/rsalabs/node.asp?id=2132
281
282[RFC1321]
283R. Rivest, The MD5 Message-Digest Algorithm, IETF RFC 1321, Apr 1992,
284http://www.ietf.org/rfc/rfc1321.txt
285
286[RFC1421]
287J. Linn, Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and
288Authentication Procedures, IETF RFC 1421, Feb 1993, http://www.ietf.org/rfc/rfc1421.txt
289
290[RFC3647]
291S. Chokhani, W. Ford, R. Sabett, C. Merrill, and S. Wu. RFC3647: Internet X.509 Public Key
292Infrastructure Certificate Policy and Certification Practices Framework. November 2003.
293http://www.ietf.org/rfc/rfc3647.txt
294
295[RFC4210]
296C. Adams, S. Farrell, T. Kause and T. Mononen, Internet X.509 Public Key Infrastructure
297Certificate Management Protocol (CMP), IETF RFC 2510, Sep 2005,
298http://www.ietf.org/rfc/rfc4210.txt
299
300[RFC4211]
301J. Schaad, Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF),
302IETF RFC 4211, Sep 2005, http://www.ietf.org/rfc/rfc4211.txt
303
304[RFC4949]
305R. Shirey. RFC4949: Internet Security Glossary, Version 2. August 2007.
306http://www.ietf.org/rfc/rfc4949.txt
307
308[RFC4880]
309J. Callas, L. Donnerhacke, H. Finney, D. Shaw and R. Thayer. RFC4880: OpenPGP Message
310Format. November 2007. http://www.ietf.org/rfc/rfc4880.txt
311
312[RFC5272]
313J. Schaad and M. Meyers, Certificate Management over CMS (CMC), IETF RFC 5272, Jun 2008,
314http://www.ietf.org/rfc/rfc5272.txt
315
316[RFC5280]
317D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. RFC5280: Internet
318X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. May
3192008. http://www.ietf.org/rfc/rfc5280.txt
45kmip-ug-v1.2-cnd01
46Non-Standards Track
47

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 10 of 84

[Type the document title]

43

44

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

320
321[RFC6818]
322P. Yee, Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate
323Revocation List (CRL) Profile, IETF RFC6818, January 2013, http://www.rfc324editor.org/rfc/rfc6818.txt
325
326[SP800-38A]
327M. Dworkin. Recommendation for Block Cipher Modes of Operation Methods and Techniques.
328NIST Special Publication 800-38A, Dec 2001. http://csrc.nist.gov/publications/nistpubs/80032938a/sp800-38a.pdf
330
331[SP800-38D]
332M. Dworkin. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode
333(GCM) and GMAC. NIST Special Publication 800-38D. Nov 2007.
334http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
335
336[SP800-56A]
337E. Barker, L. Chen, A. Roginsky, and M. Smid, Recommendations for Pair-Wise Key
338Establishment Schemes Using Discrete Logarithm Cryptography, NIST Special Publication 80033956A Revision 2, May 2013, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.80034056Ar2.pdf
341
342[SP800-57-1]
343E. Barker, W. Barker, W. Burr, W. Polk and M. Smid, Recommendations for Key Management
344Part 1: General (Revision 3), NIST Special Publication 800-57 Part 1 Revision 3, July 2012,
345http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
346
347[SP800-67]
348W. Barker and E. Barker, Recommendations for the Triple Data Encryption Algorithm (TDEA)
349Block Cipher, NIST Special Publication 800-67 Revision 1, January 2012,
350http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdf
351
352[X.509]
353International Telecommunications Union (ITU)-T, X.509: Information technology Open systems
354interconnection The Directory: Public-key and attribute certificate frameworks, November 2008,
355http://www.itu.int/rec/recommendation.asp?lang=en&parent=T-REC-X.509-200811-I
356
357[X9.31]
358ANSI, X9.31: Digital Signatures Using Reversible Public Key Cryptography for the Financial
359Services Industry (rDSA). September 1998.
360
361[X9.42]
362ANSI, X9.42: Public Key Cryptography for the Financial Services Industry: Agreement of
363Symmetric Keys Using Discrete Logarithm Cryptography. 2003.
364
365[X9 TR-31]
366ANSI, X9 TR-31: Interoperable Secure Key Exchange Key Block Specification for Symmetric
367Algorithms. 2010.

368
50kmip-ug-v1.2-cnd01
51Non-Standards Track
52

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 11 of 84

[Type the document title]

48

49

53

54

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

3691.2 References (non-normative)


370[KMIP-TC]
371Key Management Interoperability Protocol Test Cases Version 1.2.Working
372Draft 02. 6 August 2013 https://www.oasis373open.org/committees/document.php?document_id=50188&wg_abbrev=kmip
374

375[KMIP-UC]
376Key Management Interoperability Protocol Use Cases Version 1.2.Working Draft 01. 25 June
3772013. https://www.oasis-open.org/committees/document.php?
378document_id=49644&wg_abbrev=kmip

[Type the document title]

379

55kmip-ug-v1.2-cnd01
56Non-Standards Track
57

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 12 of 84

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

58

59

380Assumptions
381The section describes assumptions that underlie the KMIP protocol and the
382implementation of clients and servers that utilize the protocol.
3831.3 Island of Trust
384Clients may be provided key material by the server, but they only use that
385keying material for the purposes explicitly listed in the delivery payload.
386Clients that ignore these instructions and use the keys in ways not explicitly
387allowed by the server are non-compliant. There is no requirement for the key
388management system, however, to enforce this behavior.

390KMIP relies on the chosen authentication suite as specified in [KMIP-Prof] to authenticate the
391client and on the underlying transport protocol to provide confidentiality, integrity, message
392authentication and protection against replay attack. KMIP offers a wrapping mechanism for the
393Key Value that does not rely on the transport mechanism used for the messages; the wrapping
394mechanism is intended for importing or exporting managed cryptographic objects.

3951.5 State-less Server


396The protocol operates on the assumption that the server is state-less, which
397means that there is no concept of sessions inherent in the protocol. This
398does not mean that the server itself maintains no state, only that the protocol
399does not require this.
4001.6 Extensible Protocol
401The protocol provides for private or vendor-specific extensions, which allow for differentiation
402among vendor implementations. However, any objects, attributes and operations included in an
403implementation are always implemented as specified in [KMIP-Spec], regardless of whether they
404are optional or mandatory.

4051.7 Server Policy


406A server is expected to be conformant to KMIP and supports the conformance clauses as
407specified in[KMIP-Spec]. However, a server may refuse a server-supported operation or client408settable attribute if disallowed by the server policy (whether expressed within or outside KMIP).
409Such a decision by the server may reflect the trust relationship with a particular client,
410performance impact of the requested operation, or any of a number of other considerations.

4111.8 Support for Cryptographic Objects


412The protocol supports key management system-related cryptographic
413objects. This list currently includes:
414

Symmetric Keys

60kmip-ug-v1.2-cnd01
61Non-Standards Track
62

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 13 of 84

[Type the document title]

3891.4 Message Security

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

63

64
415

Split (multi-part) Keys

416

Asymmetric Key Pairs (Public and Private Keys)

417

PGP Keys

418

Certificates

419

Secret Data

420

Opaque (non-interpretable) cryptographic objects

422The protocol operates primarily in a client-server, message-based model. This


423means that most protocol exchanges are initiated by a client sending a
424request message to a server, which then sends a response to the client. The
425protocol also provides optional mechanisms to allow for unsolicited
426notification of events to clients using the Notify operation, and unsolicited
427delivery of cryptographic objects to clients using the Put operation; that is,
428the protocol allows a push model, whereby the server initiates the protocol
429exchange with either a Notify or Put operation. These Notify or Put features
430are optionally supported by servers and clients. Clients may register in order
431to receive such events/notifications. Registration is implementation-specific
432and not described in the specification.
4331.10 Synchronous and Asynchronous Messages
434The protocol allows two modes of operation. Synchronous (mandatory)
435operations are those in which a client sends a request and waits for a
436response from the server. Polled Asynchronous operations (optional) are
437those in which the client sends a request, the server responds with a
438pending status, and the client polls the server for the completed response
439and completion status. Server implementations may choose not to support
440the Polled Asynchronous feature of the protocol.
4411.11 Support for Intelligent Clients and Key Using
442
Devices
443The protocol supports intelligent clients, such as end-user workstations,
444which are capable of requesting all of the functions of KMIP. It also allows
445subsets of the protocol and possible alternate message representations in
446order to support less-capable devices, which only need a subset of the
447features of KMIP.
4481.12 Batched Requests and Responses
449The protocol contains a mechanism for sending batched requests and
450receiving the corresponding batched responses, to allow for higher
451throughput on operations that deal with a large number of entities, e. g.,
452requesting dozens or hundreds of keys from a server at one time, and
65kmip-ug-v1.2-cnd01
66Non-Standards Track
67

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 14 of 84

[Type the document title]

4211.9 Client-Server Message-based Model

68

69

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

453performing operations in a group. An option is provided to indicate whether to


454continue processing requests after an earlier request in the batch fails or to
455stop processing the remaining requests in the batch. Note that there is no
456option to treat an entire batch as atomic, that is, if a request in the batch
457fails, then preceding requests in the batch are not undone or rolled back (see
458Section 1.30). A special ID Placeholder (see Section 1.33) is provided in KMIP
459to allow related requests in a batch to be pipelined.
4601.13 Reliable Message Delivery
461The reliable message delivery function is relegated to the transport protocol,
462and is not part of the key management protocol itself.

464For requests that could result in large responses, a mechanism in the protocol
465allows a client to specify in a request the maximum allowed size of a
466response or in the case of the Locate operation the maximum number of
467items which should be returned. The server indicates in a response to such a
468request that the response would have been too large and, therefore, is not
469returned.
4701.15 Key Life-cycle and Key State
471[KMIP-Spec]describes the key life-cycle model, based on the [SP800-57-1] key state definitions,
472supported by the KMIP protocol. Particular implications of the key life-cycle model in terms of
473defining time-related attributes of objects are discussed in Section 1.20 below.

70kmip-ug-v1.2-cnd01
71Non-Standards Track
72

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 15 of 84

[Type the document title]

4631.14 Large Responses

73

74

474Using

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

KMIP Functionality

475This section provides guidance on using the functionality described in the Key
476Management Interoperability Protocol Specification.
4771.16 Authentication

484KMIP implementations that support the KMIP-defined Credential Types or use


485other vendor-specific mechanisms for authentication may use the optional
486Authentication structure specified inside the Request Header to include
487additional identification information. Depending on the servers configuration,
488the server may interpret the identity of the requestor from the Credential
489structure, contained in the Authentication structure if it is not provided during
490the channel-level authentication. For example, in addition to performing
491mutual authentication during a TLS handshake, the client passes the
492Credential structure (e.g., a username and password) in the request. If the
493requestors username is not specified inside the client certificate and is
494instead specified in the Credential structure, the server interprets the identity
495of the requestor from the Credential structure. This supports use cases where
496channel-level authentication authenticates a machine or service that is used
497by multiple users of the KMIP server. If the client provides the username of
498the requestor in both the client certificate and the Credential structure, the
499server verifies that the usernames are the same. If they differ, the
500authentication fails and the server returns an error. If no Credential structure
501is included in the request, the username of the requestor is expected to be
502provided inside the certificate. If no username is provided in the client
503certificate and no Credential structure is included in the request message, the
504server is expected to refuse authentication and return an error.
505If authentication is unsuccessful, and it is possible to return an
506authentication not successful error, this error should be returned in
507preference to any other result status. This prevents status code probing by a
508client that is not able to authenticate.
509Server decisions regarding which operations to reject if there is insufficiently
510strong authentication of the client are not specified in the protocol. However,
511see Section 1.17 for operations for which authentication and authorization are
512particularly important.
75kmip-ug-v1.2-cnd01
76Non-Standards Track
77

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 16 of 84

[Type the document title]

478As discussed in [KMIP-Spec], a conforming KMIP implementation establishes


479and maintains channel confidentiality and integrity, and provides assurance
480of server authenticity for KMIP messaging. Client authentication is performed
481according to the chosen KMIP authentication suite as specified in [KMIP-Prof].
482Other mechanisms for client and server authentication are possible and
483optional for KMIP implementations.

78

79

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

5131.16.1 Credential
514The Credential object defined in the [KMIP-Spec] is a structure used to convey
515information about the client, but the contents of this object are not managed
516by the key management server. The type of information convey within this
517object varies based on the type of credential. KMIP 1.2 supports three
518credential types: Username and Password, Device Credential and
519Attestation.

521[KMIP-Spec] defines the Username and Password structure for the


522Credential Type Username and Password. The structure consists of two fields:
523Username and Password. Password is a recommended, but optional, field,
524which may be excluded only if the client is authenticated using one of the
525authentication suites defined in [KMIP-Prof] For example, if the client
526performs client certificate authentication during the TLS handshake, and the
527Authentication structure is provided in the Message Request, the Password
528field is an optional field in the Username and Password structure of the
529Credential structure.
530The Credential structure is used to provide additional identification
531information. As described above, for certain use cases, channel-level
532authentication may only authenticate a machine or service that is used by
533multiple clients of the KMIP server. The Credential structure may be used in
534this scenario to identify individual clients by specifying the username in the
535Username and Password structure.
5361.16.1.2 Device Credential Type
537The Device Credential may be used to uniquely identify back-end devices by
538specifying Device as the Credential Type in the Credential structure.
539The Device Credential may be used in a proxy environment where the proxy
540authenticates with the client certificate and supports KMIP while the back-end
541devices may not support KMIP or TLS. An example is illustrated below:
542

80kmip-ug-v1.2-cnd01
81Non-Standards Track
82

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 17 of 84

[Type the document title]

5201.16.1.1 Username and Password Credential Type

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

543
544F IGURE 1: AGGREGATOR C LIENT EXAMPLE

545The end device identifies itself with a device unique set of identifier values
546that include the device hardware serial number, the network identifier, the
547machine identifier, or the media identifier. For many of the self-encrypting
548devices there is a unique serial number assigned to the device during
549manufacturing. The ability to use network, machine, or media identifier
550explicitly should map to different device types and achieve better
551interoperability since different types of identifier values are explicitly
552enumerated. The device identifier is included for more generic usage. An
553optional password or shared secret may be used to further authenticate the
554device.
555Server implementations may choose to enforce rules for uniqueness for
556different types of identifier values, combinations of TLS certificate used in
557combination with the Device Credential, and optionally enforce the use of a
558Device Credential password.
559Four identifiers are optionally provided but are unique in aggregate:
560
561
562
563
564
565
566
567

1. Serial Number, for example the hardware serial number of the device
2. Network Identifier, for example the MAC address for Ethernet connected
devices
3. Machine Identifier, for example the client aggregator identifier, such as a
tape library aggregating tape drives
4. Media Identifier, for example the volume identifier used for a tape
cartridge

85kmip-ug-v1.2-cnd01
86Non-Standards Track
87

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 18 of 84

[Type the document title]

83

84

88

89

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

568The device identifier by choice of server policy may or may not be used in
569conjunction with the above identifiers to insure uniqueness.
570These additional identifiers are generally useful for auditing and monitoring
571encryption and could according to server policy be logged or used in server
572implementation specific validation.
573A specific example for self-encrypting tape drive and tape library would be:
1. the tape drive has a serial number that is unique for that manufacturer
and the vendor has procedures for maintaining and tracking serial
number usage
2. a password optionally is created and stored either on the drive or the
library to help authenticate the drive
3. the tape drives may be connected via fiber channel to the library and
therefore have a World Wide Name assigned
4. a machine identifier can be used to identify the tape library that is
aggregating the device in question
5. the media identifier helps identify the individual media such as a tape
cartridge for proof of encryption reporting

586Another example using self-encrypting disk drives inside of a server would be:
587
588
589
590
591
592
593
594
595
596

1. the disk drive has a unique serial number


2. a password may be supplied by configuration of the drive or the server
where the drive is located
3. the network identifier may come from the internal attachment identifier
for the disk drive in the server
4. the machine identifier may come from a servers motherboard or service
processor identifier,
5. and the media identifier comes from the volume name used by the
servers operating system to identify the volume on the disk drive

597Server implementations could control what devices may read and write keys
598and use the device credential fields to influence access control enforcement.
599
600Another example applied to server virtualization and encryption built into
601virtualization would be:
602
603
604
605
606
607
608
609
610

1. the virtual machine instance has a unique identifier that is used for the
serial number
2. the hypervisor supplies a shared secret that is used as the password to
authenticate the virtual machine
3. the network identifier could be used to identify the MAC address of the
physical server where the virtual machine is running
4. the machine identifier could be used to identify the hypervisor
5. the media identifier could be used to identify the storage volume used by
the virtual machine

90kmip-ug-v1.2-cnd01
91Non-Standards Track
92

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 19 of 84

[Type the document title]

574
575
576
577
578
579
580
581
582
583
584
585

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

93

94
611

612These are examples of usage and are not meant to define all device
613credential usage patterns nor restrict server specific implementations.
614The device credentials may be explicitly added by the administrator or may
615be captured in line with the request and implicitly registered depending upon
616server policy.
617When a server is not able to resolve the identifier values in the device
618credential to a unique client identification, it may choose to reject the request
619with an error code of operation failed and reason code of item not found.
6201.17 Authorization for Revoke, Recover, Destroy and Archive
621
Operations

625Certain operations that may be requested by a client via KMIP, particularly


626Revoke, Recover, Destroy and Archive, may have a significant impact on the
627availability of a key, on server performance and/or on key security. When a
628server receives a request for one of these operations, it should ensure that
629the client has authenticated its identity (see the Authentication Suites section
630in [KMIP-Prof]. The server should also ensure that the client requesting the
631operation is an object owner, security officer or other identity authorized to
632issue the request. It may also require additional authentication to ensure that
633the object owner or a security officer has issued that request. Even with such
634authentication and authorization, requests for these operations should be
635considered only a hint to the key management system, which may or may
636not choose to act upon this request depending on server policy.
6371.18 Using Notify and Put Operations
638The Notify and Put operations are the only operations in the KMIP protocol
639that are initiated by the server, rather than the client. As client-initiated
640requests are able to perform these functions (e.g., by polling to request
641notification), these operations are optional for conforming KMIP
642implementations. However, they provide a mechanism for optimized
643communication between KMIP servers and clients.
644In using Notify and Put, the following constraints and guidelines should be
645observed:
646
647
648
649

The client enrolls with the server, so that the server knows how to
locate the client to which a Notify or Put is being sent and which events
for the Notify are supported. However, such registration is outside the
scope of the KMIP protocol. Registration also includes a specification of

95kmip-ug-v1.2-cnd01
96Non-Standards Track
97

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 20 of 84

[Type the document title]

622The authentication suite, as specified in [KMIP-Prof], describes how the client


623identity is established for KMIP-compliant implementations. This
624authentication is performed for all KMIP operations.

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

98

99

whether a given client supports Put and Notify, and what attributes
may be included in a Put for a particular client.

Communication between the client and the server is authenticated.


Authentication for a particular client/server implementation is at a
minimum accomplished using one of the mandatory authentication
mechanisms (see [KMIP-Prof]). Further strengthening of the
client/server communications integrity by means of signed message
content and/or wrapped keys is recommended.

In order to minimize possible divergence of key or state information


between client and server as a result of server-initiated
communication, any client receiving Notify or Put messages returns
acknowledgements of these messages to the server. This
acknowledgement may be at communication layers below the KMIP
layer, such as by using transport-level acknowledgement provided in
TCP/IP.

For client devices that are incapable of responding to messages from


the server, communication with the server happens via a proxy entity
that communicates with the server, using KMIP, on behalf of the client.
It is possible to secure communication between a proxy entity and the
client using other, potentially proprietary mechanisms.

6701.19 Usage Allocation


671Usage should be allocated and handled carefully at the client, since power
672outages or other types of client failures (crashes) may render allocated usage
673lost. For example, in the case of a key being used for the encryption of tapes,
674such a loss of the usage allocation information following a client failure during
675encryption may result in the necessity for the entire tape backup session to
676be re-encrypted using a different key, if the server is not able to allocate
677more usage. It is possible to address this through such approaches as caching
678usage allocation information on stable storage at the client, and/or having
679conservative allocation policies at the server (e.g., by keeping the maximum
680possible usage allocation per client request moderate). In general, usage
681allocations should be as small as possible; it is preferable to use multiple
682smaller allocation requests rather than a single larger request to minimize the
683likelihood of unused allocation.
6841.20 Key State and Times
685[KMIP-Spec] provides a number of time-related attributes, including the
686following:
687
688

Initial Date: The date and time when the managed cryptographic
object was first created by or registered at the server.

689
690
691

Activation Date: The date and time when the managed cryptographic
object should begin to be used for applying cryptographic protection to
data.

100kmip-ug-v1.2-cnd01
101Non-Standards Track
102

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 21 of 84

[Type the document title]

650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669

692
693
694
695

Process Start Date: The date and time when a managed symmetric key
object should begin to be used for processing cryptographically
protected data. The managed symmetric key object should not be
used prior to this date.

696
697
698

Protect Stop Date: The date and time when a managed symmetric key
object should no longer be used for applying cryptographic protection
to data

699
700
701
702
703
704

Deactivation Date: The date and time when the managed


cryptographic object should no longer be used for applying
cryptographic protection (e.g., encryption, signing, wrapping, MACing,
deriving). Under extraordinary circumstances and when special
permission is granted the managed symmetric key object can be used
for decryption, signature verification, unwrapping, or MAC verification,

705
706

Destroy Date: The date and time when the managed cryptographic
object was destroyed

707
708

Compromise Occurrence Date: The date and time when the managed
cryptographic object was first believed to be compromised.

709
710

Compromise Date: The date and time when the managed


cryptographic object was entered into the compromised state.

711
712

Archive Date: The date and time when the managed object was placed
in Off-Line storage.

713These attributes apply to all cryptographic objects (symmetric keys,


714asymmetric keys, etc.) with exceptions as noted in [KMIP-Spec]. However,
715certain of these attributes (such as the Initial Date) are not specified by the
716client and are implicitly set by the server.
717In using these attributes, the following guidelines should be observed:
718
719
720
721
722
723
724
725
726
727
728
729
730
731

As discussed for each of these attributes in [KMIP-Spec], a number of


these times are set once and it is not possible for the client or server to
modify them. However, several of the time attributes (particularly the
Activation Date, Protect Start Date, Process Stop Date and Deactivation
Date) may be set by the server and/or requested by the client.
Coordination of time-related attributes between client and server,
therefore, is primarily the responsibility of the server, as it manages
the cryptographic object and its state. However, special conditions
related to time-related attributes, governing when the server accepts
client modifications to time-related attributes, may be communicated
out-of-band between the client and server outside the scope of KMIP. In
general, state transitions occur as a result of operational requests,
such as Create, Create Key Pair, Register, Activate, Revoke, and
Destroy. However, clients may need to specify times in the future for

105kmip-ug-v1.2-cnd01
106Non-Standards Track
107

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 22 of 84

[Type the document title]

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

103

104

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

108

109
732
733
734
735
736
737
738
739
740
741
742

It is valid to have a projected Deactivation Date when there is no


Activation Date. This means, however, that the key is not yet active,
even though its projected Deactivation Date has been specified. A valid
Deactivation Date is greater than or equal to the Activation Date (if the
Activation Date has been set).

743
744
745
746
747
748
749

The Protect Stop Date may be equal to, but may not be later than the
Deactivation Date. Similarly, the Process Start Date may be equal to,
but may not precede, the Activation Date. KMIP implementations
should consider specifying both these attributes, particularly for
symmetric keys, as a key may be needed for processing protected data
(e.g., decryption) long after it is no longer appropriate to use it for
applying cryptographic protection to data (e.g., encryption).

750
751
752
753
754
755
756
757
758

KMIP does not allow an Active object to be destroyed with the Destroy
operation. The server returns an error, if the client invokes the Destroy
operation on an Active object. To destroy an Active object, clients first
call the Revoke operation or explicitly set the Deactivation Date of the
object. Once the object is in Deactivated state, clients may destroy the
object by calling the Destroy operation. These operations may be
performed in a batch. If other time-related attributes (e.g., Protect Stop
Date) are set to a future date, the server should set these to the
Deactivation Date.

759
760
761

After a cryptographic object is destroyed, a key management server


may retain certain information about the object, such as the Unique
Identifier.

762KMIP allows the specification of attributes on a per-client basis, such that a


763server could maintain or present different sets of attributes for different
764clients. This flexibility may be necessary in some cases, such as when a
765server maintains the availability of a given key for some clients, even after
766that same key is moved to an inactive state (e.g., Deactivated state) for other
767clients. However, such an approach might result in significant inconsistencies
768regarding the object state from the point of view of all participating clients
769and should, therefore, be avoided. A server should maintain a consistent
770state for each object, across all clients that have or are able to request that
771object.

110kmip-ug-v1.2-cnd01
111Non-Standards Track
112

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 23 of 84

[Type the document title]

such things as Activation Date, Deactivation Date, Process Start Date,


and Protect Stop Date.
KMIP allows clients to specify times in the past for such attributes as
Activation Date and Deactivation Date. This is intended primarily for
clients that were disconnected from the server at the time that the
client performed that operation on a given key.

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

113

114

7721.21 Template
773The usage of templates is an alternative approach for setting attributes in an
774operation request. Instead of individually specifying each attribute, a
775template may be used to provide attribute values.

782The Template-Attribute structure allows for multiple template names (zero or


783more) and individual attributes (zero or more) to be specified in an operation
784request. The structure is used in the Create, Create Key Pair, Register, Re-key,
785Re-key Key Pair, Derive Key, Certify, and Re-certify operations. All of these
786operations with the exception of the Create Key Pair and the Re-key Key Pair
787operations use the Template-Attribute tag. The Create Key Pair and the Re-key
788Key Pair operations use the Common Template-Attribute, Private Key
789Template Attribute, and Public Key Template-Attribute tags allowing
790specification of different attributes for the public and private managed
791cryptographic objects.
792Templates may be the subject of the Register, Locate, Get, Get Attributes, Get
793Attribute List, Add Attribute, Modify Attribute, Delete Attribute, Delete
794Attribute, and Destroy operations. Templates are created using the Register
795operation. When the template is the subject of an operation, the Unique
796Identifier is used to identify the template. The template name is only used to
797identify the template when referenced inside a Template-Attribute structure.
7981.21.1 Template Usage Examples
799The purpose of these examples is to illustrate how templates are used. The
800first example shows how a template is registered. The second example shows
801how the newly registered template is used to create a symmetric key.
8021.21.1.1.1 Example of Registering a Template
803In this example, a client registers a template by encapsulating attributes for
804creating a 256-bit AES key with the Cryptographic Usage Mask set to Encrypt
805and Decrypt.
806The following is specified inside the Register Request Payload:
807

Object Type: Template

808

Template-Attribute:

809
810

Attribute

Attribute Name : Name

115kmip-ug-v1.2-cnd01
116Non-Standards Track
117

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 24 of 84

[Type the document title]

776A template also has attributes that are applicable to the template itself which
777are referred to in the specification as associated attributes to distinguish
778them from the attributes that are contained within the template managed
779object. When registering a template, the Name attribute for the template
780itself must be set. It is used to identify the template in the Template-Attribute
781structure when attributes for a managed object are set in KMIP operations.

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

118

119

Attribute Value: Template1

Template

Attribute

814

Attribute Name: Cryptographic Algorithm

815

Attribute Value: AES

816

Attribute

817

Attribute Name: Cryptographic Length

818

Attribute Value: 256

819

Attribute

820

Attribute Name: Cryptographic Usage Mask

821

Attribute Value: Encrypt and Decrypt

822

Attribute

823

Attribute Name: Operation Policy Name

824
Attribute Value: OperationPolicy1
825The Operation Policy OperationPolicy1 applies to the AES key being created
826using the template. It is not used to control operations on the template itself.
827KMIP does not allow operation policies to be specified for controlling
828operations on the template itself. The default policy for template objects is
829used for this purpose and is specified in the KMIP Specification.
8301.21.1.2 Example of Creating a Symmetric Key using a Template
831In this example, the client uses the template created in example 3.6.1 to
832create a 256-bit AES key.
833The following is specified in the Create Request Payload:
834

Object Type: Symmetric Key

835

Template-Attribute:

836

Name: Template1

837

Attribute:

838

Attribute Name: Name

839
840

Attribute Value: AESkey

841

Attribute:

Attribute Name: x-Custom Attribute1

842
Attribute Value: ID74592
843The Template-Attribute structure specifies both a template name and
844additional associated attributes. It is possible to specify the Custom Attribute
845inside the template when the template is registered; however, this particular
846example sets this attribute separately.
120kmip-ug-v1.2-cnd01
121Non-Standards Track
122

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 25 of 84

[Type the document title]

811
812
813

123

124

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

8471.21.1.3 Compatibility Note:


848Versions of KMIP prior to KMIP version 1.2 contained a fixed list of attributes
849applicable to objects created using a template and those applicable to the
850template managed object. The value returned by the Get operation for a
851template was subject to varying interpretations. KMIP 1.2 alters this handling
852to provide clarification of the expected handling for templates. KMIP clients
853may need to be mindful of this change when registering or performing
854operations which refer to templates as the handling of templates in a KMIP
855server vary depending on the version of the KMIP protocol specified.
856As the baseline server profile does not mandate (require) support for
857templates a KMIP client that requires support for templates cannot be
858guaranteed to interoperate with all servers that conform to the KMIP
859specification.

861When the Archive operation is performed, it is recommended that a unique


862identifier and a minimal set of attributes be retained within the server for
863operational efficiency. In such a case, the retained attributes may include
864Unique Identifier and State.
8651.23 Message Extensions
866Any number of vendor-specific extensions may be included in the Message
867Extension optional structure. This allows KMIP implementations to create
868multiple extensions to the protocol.
8691.24 Unique Identifiers
870For clients that require unique identifiers in a special form, out-of-band
871registration/configuration may be used to communicate this requirement to
872the server.
8731.25 Result Message Text
874KMIP specifies the Result Status, the Result Reason and the Result Message
875as normative message contents. For the Result Status and Result Reason, the
876enumerations provided in [KMIP-Spec] are the normative values. The values
877for the Result Message text are implementation-specific. In consideration of
878internationalization, it is recommended that any vendor implementation of
879KMIP provide appropriate language support for the Return Message. How a
880client specifies the language for Result Messages is outside the scope of the
881KMIP.

125kmip-ug-v1.2-cnd01
126Non-Standards Track
127

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 26 of 84

[Type the document title]

8601.22 Archive Operations

128

129

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

8821.26 Query
883Query does not explicitly support client requests to determine what
884operations require authentication. To determine whether an operation
885requires authentication, a client should request that operation.
8861.27 Canceling Asynchronous Operations
887If an asynchronous operation is cancelled by the client, no information is
888returned by the server in the result code regarding any operations that may
889have been partially completed. Identification and remediation of partially
890completed operations is the responsibility of the server.

895Once a client has received the status on an asynchronous operation other


896than pending, any subsequent request for status of that operation may
897return either the same status as in a previous polling request or an
898unavailable response.
8991.28 Multi-instance Hash
900The Digest attribute contains the output of hashing a managed object, such
901as a key or a certificate. The server always generates the SHA-256 hash value
902when the object is created or generated. KMIP allows multiple instances of
903the digest attribute to be associated with the same managed object. For
904example, it is common practice for publicly trusted CAs to publish two digests
905(often referred to as the fingerprint or the thumbprint) of their certificate: one
906calculated using the SHA-1 algorithm and another using the MD5 algorithm.
907In this case, each digest would be calculated by the server using a different
908hash algorithm.
9091.29 Returning Related Objects
910The key block returns a single object, with associated attributes and other
911data. For those cases in which multiple related objects are needed by a client,
912such as the private key and the related certificate, the client should issue
913multiple Get requests to obtain these related objects.
9141.30 Reducing Multiple Requests through the Use of Batch
915KMIP supports batch operations in order to reduce the number of calls
916between the client and server. For example, Locate and Get are likely to be
917commonly accomplished within a single batch request.
918KMIP does not ensure that batch operations are atomic on the server side. If
919servers implement such atomicity, the client is able to use the optional
130kmip-ug-v1.2-cnd01
131Non-Standards Track
132

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 27 of 84

[Type the document title]

891It is the responsibility of the server to determine when to discard the status of
892asynchronous operations. The determination of how long a server should
893retain the status of an asynchronous operation is implementation-dependent
894and not defined by KMIP.

133

134

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

920undo mode to request roll-back for batch operations implemented as


921atomic transactions. However, support for undo mode is optional in the
922protocol, and there is no guarantee that a server that supports undo mode
923has effectively implemented atomic batches. The use of undo, therefore,
924should be restricted to those cases in which it is possible to assure the client,
925through mechanisms outside of KMIP, of the server effectively supporting
926atomicity for batch operations.
9271.31 Maximum Message Size

935When processing individual requests within the batch, the server that has
936encountered a Maximum Response Size error should not return attribute
937values or other information as part of the error response.
938The Locate operation also supports the concept of a maximum item count to
939include in the returned list of unique identifiers.
9401.32 Using Offset in Re-key and Re-certify Operations
941The Re-key, Re-key Key Pair, and Re-certify operations allow the specification
942of an offset interval.
943The Re-key and the Re-key Key Pair operations allow the client to specify an
944offset interval for activation of the key. This offset specifies the duration of
945time between the time the request is made and the time when the activation
946of the key occurs. If an offset is specified, all other times for the new key are
947determined from the new Activation Date, based on the intervals used by the
948previous key, i.e., from the Activation Date to the Process Start Date, Protect
949Stop Date, etc.
950The Re-certify operation allows the client to specify an offset interval that
951indicates the difference between the Initial Date of the new certificate and
952the Activation Date of the new certificate. As with the Re-key operation, all
953other times for the certificate are determined using the intervals used for the
954previous certificate.
955Note that in re-key operations if activation date, process start date, protect
956stop date and deactivation date are obtained from the existing key, and the
957initial date is obtained from the current time, then the deactivation/activation
958date/process start date/protect stop date is smaller or less than initial date.
135kmip-ug-v1.2-cnd01
136Non-Standards Track
137

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 28 of 84

[Type the document title]

928When a server is processing requests in a batch, it should compare the


929cumulative response size of the message to be returned after each request
930with the specified Maximum Response Size. If the message is too large, it
931should prepare a maximum message size error response message at that
932point, rather than continuing with operations in the batch. This increases the
933clients ability to understand what operations have and have not been
934completed.

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

138

139

959KMIP allows back-dating of these values to prevent this contradiction (see


960[KMIP-Spec] section 1.37).
9611.33 ID Placeholder

Operation

ID
ID Placeholder upon completion of
Placeholder the operation (in case of operation
at the
failure, a batch using the ID
beginning of Placeholder stops)
the operation

Create

ID of new Object

Create Key Pair

ID of new Private Key (ID of new Public


Key may be obtained via a Locate)

Create Split Key

ID of the split whose Key Part Identifier is


1

Join Split Key

ID of returned object

Register

ID of newly registered Object

Derive Key

- (multiple
ID of new Symmetric Key
Unique
Identifiers may
be specified in
the request)

Locate

ID of located Object

Get

ID of Object

no change

Validate

Get Attributes
ID of Object
List/Modify/Add/Del
ete

no change

Activate

ID of Object

no change

Revoke

ID of Object

no change

Destroy

ID of Object

no change

Archive/Recover

ID of Object

no change

140kmip-ug-v1.2-cnd01
141Non-Standards Track
142

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 29 of 84

[Type the document title]

962A number of operations are affected by a mechanism referred to as the ID


963Placeholder. This is a temporary variable consisting of a single Unique
964Identifier that is stored inside the server for the duration of executing a batch
965of operations. The ID Placeholder is obtained from the Unique Identifier
966returned by certain operations; the applicable operations are identified in
967Table 1, along with a list of operations that accept the ID Placeholder as input.

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

Certify

ID of Public KeyID of new Certificate

Re-certify

ID of
Certificate

Re-key

ID of
ID of new Symmetric Key
Symmetric Key
to be rekeyed

Re-key Key Pair

ID of Private
Key to be
rekeyed

ID of new Private Key (ID of new Public


Key may be obtained via a Locate)

Obtain Lease

ID of Object

no change

Get Usage
Allocation

ID of Key

no change

Check

ID of Object

no change

ID of new Certificate

968
T ABLE 1: ID P LACEHOLDER PRIOR TO AND R ESULTING FROM A KMIP
969O PERATION

9701.34 Key Block


971The protocol uses the Key Block structure to transport a key to the client or
972server. This Key Block consists of the Key Value Type, the Key Value, and the
973Key Wrapping Data. The Key Value Type identifies the format of the Key
974Material, e.g., Raw format or Transparent Key structure. The Key Value
975consists of the Key Material and optional attributes. The Key Wrapping Data
976provides information about the wrapping key and the wrapping mechanism,
977and is returned only if the client requests the Key Value to be wrapped by
978specifying the Key Wrapping Specification inside the Get Request Payload.
979The Key Wrapping Data may also be included inside the Key Block if the client
980registers a wrapped key.
981The protocol allows any attribute to be included inside the Key Value and
982allows these attributes to be cryptographically bound to the Key Material (i.e.,
983by signing, MACing, encrypting, or both encrypting and signing/MACing the
984Key Value). Some of the attributes that may be included include the following:
985

Unique Identifier uniquely identifies the key

986

Cryptographic Algorithm (e.g., AES, 3DES, RSA) this attribute is either specified inside
the Key Block structure or the Key Value structure

Cryptographic Length (e.g., 128, 256, 2048) this attribute is either specified inside the
Key Block structure or the Key Value structure

Cryptographic Usage Mask identifies the cryptographic usage of the key (e.g., Encrypt,
Wrap Key, Export)

Cryptographic Parameters provides additional parameters for determining how the key
may be used

987

988
989

990
991

992
993

145kmip-ug-v1.2-cnd01
146Non-Standards Track
147

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 30 of 84

[Type the document title]

143

144

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

148

149
994
995
996
997
998
999
1000
1001
1002
1003
1004

Block Cipher Mode (e.g., CBC, NISTKeyWrap, GCM) this parameter


identifies the mode of operation, including block cipher-based MACs
or wrapping mechanisms

Padding Method (e.g., OAEP, X9.31, PSS) identifies the padding


method and if applicable the signature or encryption scheme

Hashing Algorithm (e.g., SHA-256) identifies the hash algorithm to


be used with the signature/encryption mechanism or Mask
Generation Function; note that the different HMACs are defined
individually as algorithms and do not require the Hashing Algorithm
parameter to be set

Key Role Type Identifies the functional key role (e.g., DEK, KEK)

1005

State (e.g., Active)

1006

Dates (e.g., Activation Date, Process Start Date, Protect Stop Date)

1007

Custom Attribute allows vendors and clients to define vendor-specific attributes; may
also be used to prevent replay attacks by setting a nonce

1008

1010The key management system may specify rules for valid group names which
1011may be created by the client. Clients are informed of such rules by a
1012mechanism that is not specified by [KMIP-Spec]KMIP_Spec. In the protocol,
1013the group names themselves are text strings of no specified format. Specific
1014key management system implementations may choose to support
1015hierarchical naming schemes or other syntax restrictions on the names.
1016Groups may be used to associate objects for a variety of purposes. A set of
1017keys used for a common purpose, but for different time intervals, may be
1018linked by a common Object Group. Servers may create predefined groups and
1019add objects to them independently of client requests.
1020KMIP allows clients to specify whether it wants a fresh or default object
1021from a common Object Group. Fresh is an indication of whether a member of
1022a group has been retrieved by a client with the Get operation. The value of
1023fresh may be set as an attribute when creating or registering an object.
1024Subsequently, the Fresh attribute is modifiable only by the server. For
1025example, a set of symmetric keys belong to the Object Group
1026SymmetricKeyGroup1 and the Fresh attribute is set to true for members of
1027the group at the time of creating or registering the member. To add a new
1028symmetric key to the group, the Object Group attribute is set to
1029SymmetricKeyGroup1 and the Fresh attribute is set to true when creating or
1030registering the symmetric key object.
1031The definition of a default object in a group is based on server policy. One
1032example of server policy is to use round robin selection to serve a key from a
1033group. In this case when a client requests the default key from a group, the
1034server uses round robin selection to serve the key.
150kmip-ug-v1.2-cnd01
151Non-Standards Track
152

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 31 of 84

[Type the document title]

10091.35 Object Group

153

154

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

1035An object may be removed from a group by deleting the Object Group
1036attribute, as long as server policy permits it. A client would need to delete
1037each individual member of a group to remove all members of a group.
1038The Object Group Member flag is specified in the Locate request to indicate
1039the type of group member to return. Object Group Member is an enumeration
1040that can take the value Group Member Fresh or Group Member Default.
1041Following are examples of how the Object Group Member flag is used:

1048When a Locate request is made by specifying the Object Group attribute (e.g.,
1049"symmetricKeyGroup2) and setting the Object Group Member flag to "Group
1050Member Default", a default object is returned from the group. In this example,
1051the server policy defines default to be the next key in the group
1052"symmetricKeyGroup2; the group has three group members whose Unique
1053Identifiers are uuid1, uuid2, uuid3. If the client performs four consecutive
1054batched Locate and Get operations with Object Group set to
1055"symmetricKeyGroup2" and Object Group Member set to Group Member
1056Default in the Locate request, the server returns uuid1, uuid2, uuid3, and
1057uuid1 (restarting from the beginning with uuid1 for the fourth request) in the
1058four Get responses.
10591.36 Certify and Re-certify
1060The key management system may contain multiple embedded CAs or may
1061have access to multiple external CAs. How the server routes a certificate
1062request to a CA is vendor-specific and outside the scope of KMIP. If the server
1063requires and supports the capability for clients to specify the CA to be used
1064for signing a Certificate Request, then this information may be provided by
1065including the X.509 Certificate Issuer attribute in the Certify or Re-certify
1066request.
1067[KMIP-Spec]KMIP_Spec supports multiple options for submitting a certificate
1068request to the key management server within a Certify or Re-Certify
1069operation. It is a vendor decision as to whether the key management server
1070offers certification authority (CA) functionality or proxies the certificate
1071request onto a separate CA for processing. The type of certificate request
1072formats supported is also a vendor decision, and this may, in part, be based
1073upon the request formats supported by any CA to which the server proxies
1074the certificate requests.

155kmip-ug-v1.2-cnd01
156Non-Standards Track
157

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 32 of 84

[Type the document title]

1042When a Locate request is made by specifying the Object Group attribute (e.g.,
1043"symmetricKeyGroup1) and setting the Object Group Member flag to "Group
1044Member Fresh", matching objects from the specified group (e.g.,
1045"symmetricKeyGroup1") have the Fresh attribute set to true. If there are no
1046fresh objects remaining in the group, the server may generate a new object
1047on the fly based on server policy.

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

158

159

1075All certificate request formats for requesting X.509 certificates specified in


1076[KMIP-Spec] (i.e., PKCS#10, PEM and CRMF) provide a means for allowing the
1077CA to verify that the client that created the certificate request possesses the
1078private key corresponding to the public key in the certificate request. This is
1079referred to as Proof-of-Possession (POP). However, it should be noted that in
1080the case of the CRMF format, some CAs may not support the CRMF POP
1081option, but instead rely upon the underlying certificate management
1082protocols (i.e., CMP and CMC) to provide POP. In the case where the CA does
1083not support POP via the CRMF format (including CA functionality within the
1084key management server), an alternative certificate request format (i.e.,
1085PKCS#10, PEM) would need to be used if POP needs to be verified.

1088The Create Key Pair and the Re-key Key Pair operations allow clients to
1089specify attributes using the Common Template-Attribute, Private Key
1090Template-Attribute, and Public Key Template-Attribute. The Common
1091Template-Attribute object includes a list of attributes that apply to both the
1092public and private key. Attributes that are not common to both keys may be
1093specified using the Private Key Template-Attribute or Public Key Template1094Attribute. If a single-instance attribute is specified in multiple Template1095Attribute objects, the server obeys the following order of precedence:
1096
1097
1098
1099

1. Attributes specified explicitly in the Private and Public Key Template-Attribute, then
2. Attributes specified via templates in the Private and Public Key Template-Attribute, then
3. Attributes specified explicitly in the Common Template-Attribute, then
4. Attributes specified via templates in the Common Template-Attribute

11001.37.1 Example of Specifying Attributes during the Create Key


1101
Pair Operation
1102A client specifies several attributes in the Create Key Pair Request Payload.
1103The Common Template-Attribute includes the template name RSACom and
1104other explicitly specified common attributes:
1105RSACom Template
1106
1107

Template

Attribute

1108

Attribute Name: Cryptographic Algorithm

1109

Attribute Value: RSA

1110

Attribute

1111

Attribute Name: Cryptographic Length

1112

Attribute Value: 2048

160kmip-ug-v1.2-cnd01
161Non-Standards Track
162

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 33 of 84

[Type the document title]

10861.37 Specifying Attributes during a Create Key Pair or Re-key


1087
Key Pair Operation

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

163

164

1113

Attribute

1114

Attribute Name: Cryptographic Parameters

1115

Attribute Value:

1116

1117

Padding Method: OAEP

Attribute:

1118

Attribute Name: x-Serial

1119

Attribute Value: 1234

1120

Attribute:

1121

Attribute Name: Object Group:

1122
1123

Attribute Value: Key encryption group 1

1124Common Template-Attribute

Name

1126

Name Value: RSACom

1127

Name Type: Uninterpreted Text String

1128

Attribute

1129

Attribute Name: Cryptographic Length:

1130
1131

Attribute Value: 4096

Attribute

1132

Attribute Name: Cryptographic Parameters

1133

Attribute Value:

1134
1135

Attribute

1136

Padding Method: PKCS1 v1.5

Attribute Name: x-ID

1137
Attribute Value: 56789
1138
1139The Private Key Template-Attribute includes a reference to the template name
1140RSAPriv and other explicitly-specified private key attributes:
1141RSAPriv Template
1142
1143
1144

Template

Attribute

Attribute Name: Object Group

1145
Attribute Value: Key encryption group 2
1146Private Key Template-Attribute
165kmip-ug-v1.2-cnd01
166Non-Standards Track
167

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 34 of 84

[Type the document title]

1125

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

168

169
1147

Name

1148

Name Value: RSAPriv

1149

Name Type: Uninterpreted Text String

1150

Attribute

1151

Attribute Name: Cryptographic Usage Mask

1152
1153

Attribute Value: Unwrap Key

Attribute

1154

Attribute Name: Name

1155

Attribute Value:

1156

Name Value: PrivateKey1

1161Public Key Template-Attribute


1162

Attribute

1163

Attribute Name: Cryptographic Usage Mask

1164
1165
1166

Attribute Value: Wrap Key

1167

Attribute

Attribute Name: Name

Attribute Value:

1168

Name Value: PublicKey1

1169
Name Type: Uninterpreted Text String
1170
1171Following the attribute precedence rule, the server creates a 4096-bit RSA
1172key. The following client-specified attributes are set:
1173Private Key
1174

Cryptographic Algorithm: RSA

1175

Cryptographic Length: 4096

1176

Cryptographic Parameters:

1177
1178

Cryptographic Parameters:

1179

Padding Method: OAEP

Padding Method: PKCS1 v1.5

1180

Cryptographic Usage Mask: Unwrap Key

1181

x-Serial: 1234

170kmip-ug-v1.2-cnd01
171Non-Standards Track
172

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 35 of 84

[Type the document title]

1157
Name Type: Uninterpreted Text String
1158
1159The Public Key Template Attribute includes explicitly-specified public key
1160attributes:

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

173

174
1182

x-ID: 56789

1183

Object Group: Key encryption group 1

1184

Object Group: Key encryption group 2

1185

Name:

1186

Name Value: PrivateKey1

1187
Name Type: Uninterpreted Text String
1188Public Key
1189

Cryptographic Algorithm: RSA

1190

Cryptographic Length: 4096

1191

Cryptographic Parameters:

1193

Cryptographic Parameters:

1194

Padding Method: OAEP

Padding Method: PKCS1 v1.5

1195

Cryptographic Usage Mask: Wrap Key

1196

x-Serial: 1234

1197

x-ID: 56789

1198

Object Group: Key encryption group 1

1199

Name:

1200

Name Value: PublicKey1

1201

Name Type: Uninterpreted Text String

12021.38 Registering a Key Pair


1203During a Create Key Pair or Re-key Key Pair operation, a Link Attribute is
1204automatically created by the server for each object (i.e., a link is created from
1205the private key to the public key and vice versa). Certain attributes are the
1206same for both objects and are set by the server while creating the key pair.
1207The KMIP protocol does not support an equivalent operation for registering a
1208key pair. Clients are able to register the objects independently and manually
1209set the Link attributes to make the server aware that these keys are
1210associated with each other. When the Link attribute is set for both objects,
1211the server should verify that the registered objects indeed correspond to each
1212other and apply similar restrictions as if the key pair was created on the
1213server.
1214Clients should perform the following steps when registering a key pair:
1215 1. Register the public key and set all associated attributes:
1216
a. Cryptographic Algorithm
1217
b. Cryptographic Length
175kmip-ug-v1.2-cnd01
176Non-Standards Track
177

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 36 of 84

[Type the document title]

1192

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

178

179

1218
c. Cryptographic Usage Mask
1219 5. Register the private key and set all associated attributes
1220
a. Cryptographic Algorithm is the same for both public and private key
1221
b. Cryptographic Length is the same for both public and private key
1222
c. Cryptographic Parameters may be set; if set, the value is the same for both the public
1223
and private key
1224
d. Cryptographic Usage Mask is set, but does not contain the same value for both the
1225
public and private key
1226
e. Link is set for the Private Key with Link Type Public Key Link and the Linked Object
1227
Identifier of the corresponding Public Key
1228
f. Link is set for the Public Key with Link Type Private Key Link and the Linked Object
1229
Identifier of the corresponding Private Key
12301.39 Non-Cryptographic Objects

1233KMIP defines Secret Data as cryptographic objects. Even if the object is not
1234used for cryptographic purposes, clients may still set certain attributes, such
1235as the Cryptographic Usage Mask, for this object unless otherwise stated.
1236Similarly, servers set certain attributes for this object, including the Digest,
1237State, and certain Date attributes, even if the attributes may seem relevant
1238only for other types of cryptographic objects.
1239When registering a Secret Data object, the following attributes are set by the
1240server:
1241

Unique Identifier

1242

Object Type

1243

Digest

1244

State

1245

Initial Date

1246
Last Change Date
1247When registering a Secret Data object for non-cryptographic purposes, the
1248following attributes are set by either the client or the server:
1249

Cryptographic Usage Mask

12501.40 Asymmetric Concepts with Symmetric Keys


1251The Cryptographic Usage Mask attribute is intended to support asymmetric
1252concepts using symmetric keys. This is common practice in established
1253crypto systems: the MAC is an example of an operation where a single
1254symmetric key is used at both ends, but policy dictates that one end may
180kmip-ug-v1.2-cnd01
181Non-Standards Track
182

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 37 of 84

[Type the document title]

1231The KMIP protocol allows clients to register Secret Data objects. Secret Data
1232objects may include passwords or data that are used to derive keys.

183

184

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

1255only generate cryptographic tokens using this key (the MAC) and the other
1256end may only verify tokens. The security of the system fails if the verifying
1257end is able to use the key to perform generation operations.

1261
In some of these operations, such as MAC generation and verification,
1262
the same cryptographic primitive is used in both of the complementary
1263
operations. MAC generation involves computing and returning the MAC,
1264
while MAC verification involves computing that same MAC and
1265
comparing it to a supplied value to determine if they are the same.
1266
Thus, both generation and verification use the encrypt operation,
1267
and the two usages are not able to be distinguished by considering
1268
only encrypt vs. decrypt.
1269
Some operations which require separate key types use the same
1270
fundamental cryptographic primitives. For example, encryption of data,
1271
encryption of a key, and computation of a MAC all use the fundamental
1272
operation encrypt, but in many applications, securely differentiated
1273
keys are used for these three operations. Simply looking for an
1274
attribute that permits encrypt is not sufficient.
1275Allowing the use of these keys outside of their specialized purposes may
1276compromise security. Instead, specialized application-level permissions are
1277necessary to control the use of these keys. KMIP provides several pairs of
1278such permissions in the Cryptographic Usage Mask (3.14), such as:
MAC GENERATE
MAC VERIFY

For cryptographic MAC operations.


Although it is possible to compose
certain MACs using a series of encrypt
calls, the security of the MAC relies on
the operation being atomic and specific.

GENERATE CRYPTOGRAM
VALIDATE CRYPTOGRAM

For composite cryptogram operations such as


financial CVC or ARQC. To specify exactly which
cryptogram the key is used for it is also necessary
to specify a role for the key (see Section 1.21
Cryptographic Parameters in [KMIP-Spec]).

TRANSLATE ENCRYPT
TRANSLATE DECRYPT

To accommodate secure routing of


traffic and data. In many areas that
rely on symmetric techniques (notably,
but not exclusively financial networks),
information is sent from place to place
encrypted using shared symmetric
keys. When encryption keys are
changed, it is desirable for the change
to be an atomic operation, otherwise
distinct unwrap-wrap or decrypt-encrypt

TRANSLATE WRAP
TRANSLATE UNWRAP

185kmip-ug-v1.2-cnd01
186Non-Standards Track
187

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 38 of 84

[Type the document title]

1258In these cases it is not sufficient to describe the usage policy on the keys in
1259terms of cryptographic primitives like encrypt vs. decrypt or sign vs.
1260verify. There are two reasons why this is the case.

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

188

189

steps risk leaking the plaintext data


during the translation process.
TRANSLATE ENCRYPT/DECRYPT is used
for data encipherment.
TRANSLATE WRAP/UNWRAP is used for
key wrapping.

1280In order to support asymmetric concepts using symmetric keys in a KMIP


1281system, the server implementation needs to be able to differentiate between
1282clients for generate operations and clients for verify operations. As indicated
1283by Section 3 (Attributes) of [KMIP-Spec] there is a single key object in the
1284system to which all relevant clients refer, but when a client requests that key,
1285the server is able to choose which attributes (permissions) to send with it,
1286based on the identity and configured access rights of that specific client.
1287There is, thus, no need to maintain and synchronize distinct copies of the
1288symmetric key just a need to define access policy for each client or group of
1289clients.
1290The internal implementation of this feature at the server end is a matter of
1291choice for the vendor: storing multiple key blocks with all necessary
1292combinations of attributes or generating key blocks dynamically are both
1293acceptable approaches.
12941.41 Application Specific Information
1295The Application Specific Information attribute is used to store data which is
1296specific to the application(s) using the object. Some examples of Application
1297Namespace and Application Data pairs are given below.
1298

SMIME, 'someuser@company.com'

1299

TLS, 'some.domain.name'

1300

Volume Identification, '123343434'

1301

File Name, 'secret.doc'

1302
Client Generated Key ID, 450994003'
1303The following Application Namespaces are recommended:
1304

SMIME

1305

TLS

1306

IPSEC

1307

HTTPS

1308

PGP

1309

Volume Identification

190kmip-ug-v1.2-cnd01
191Non-Standards Track
192

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 39 of 84

[Type the document title]

1279T ABLE 2: CRYPTOGRAPHIC USAGE MASKS PAIRS

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

193

194
1310

File Name

1311

LTO4, LTO5, and LTO6

1312
LIBRARY-LTO, LIBRARY-LTO4, LIBRARY-LTO5 and LIBRARY-LTO6
1313KMIP provides optional support for server-generated Application Data. Clients
1314may request the server to generate the Application Data for the client by
1315omitting Application Data while setting or modifying the Application Specific
1316Information attribute. A server only generates the Application Data if the
1317Application Data is completely omitted from the request, and the client1318specified Application Namespace is recognized and supported by the server.
1319An example for requesting the server to generate the Application Data is
1320shown below:
1321
AddAttribute(Unique ID, AppSpecInfo{AppNameSpace=LIBRARY1322LTO4});

1325If the Application Data is provided, and the Application Namespace is


1326recognized by the server, the server uses the provided Application Data, and
1327does not generate the Application Data for the client. In the example below,
1328the server stores the Application Specific Information attribute with the
1329Application Data value set to null.
1330
AddAttribute(Unique ID, AppSpecInfo{AppNameSpace=LIBRARY-LTO4,
1331AppData=null});
13321.42 Mutating Attributes
1333KMIP does not support server mutation of client-supplied attributes. If a
1334server does not accept an attribute value that is being specified inside the
1335request by the client, the server returns an error and specifies Invalid Field
1336as Result Reason.
1337Attributes that are not set by the client, but are implicitly set by the server as
1338a result of the operation, may optionally be returned by the server in the
1339operation response inside the TemplateAttribute.
1340If a client sets a time-related attribute to the current date and time (as
1341perceived by the client), but as a result of a clock skew, the specified date of
1342the attribute is earlier than the time perceived by the server, the servers
1343policy is used to determine whether to accept the backdated attribute.
1344KMIP does not require the server to fail a request if a backdated attribute is
1345set by the client.
1346If a server does not support backdated attributes, and cryptographic objects
1347are expected to change state at the specified current date and time (as
1348perceived by the client), clients are recommended to issue the operation that
195kmip-ug-v1.2-cnd01
196Non-Standards Track
197

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 40 of 84

[Type the document title]

1323If the server does not recognize the namespace, the Application Namespace
1324Not Supported error is returned to the client.

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

198

199

1349would implicitly set the date for the client. For example, instead of explicitly
1350setting the Activation Date, clients could issue the Activate operation. This
1351would require the server to set the Activation Date to the current date and
1352time as perceived by the server.
1353If it is not possible to set a date attribute via an operation, and the server
1354does not support backdated attributes, clients need to take into account that
1355potential clock skew issues may cause the server to return an error even if a
1356date attribute is set to the clients current date and time.
1357For additional information, refer to the sections describing the State attribute
1358and the Time Stamp field in [KMIP-Spec].

1360The enumerations for the Revocation Reason attribute specified in KMIP (see table 9.1.3.2.19 in
1361[KMIP-Spec]) are aligned with the Reason Code specified in [X.509] and referenced in [RFC5280]
1362with the following exceptions. The certificateHold and removeFromCRL reason codes have been
1363excluded from [KMIP-Spec] since KMIP does not support certificate suspension (putting a
1364certificate hold) or unsuspension (removing a certificate from hold). The aaCompromise reason
1365code has been excluded from [KMIP-Spec] since it only applies to attribute certificates, which are
1366out-of-scope for [KMIP-Spec]. The privilegeWithdrawn reason code is included in [KMIP-Spec]
1367since it may be used for either attribute or public key certificates. In the context of its use within
1368KMIP it is assumed to only apply to public key certificates.

13691.44 Certificate Renewal, Update, and Re-key


1370The process of generating a new certificate to replace an existing certificate may be referred to by
1371multiple terms, based upon what data within the certificate is changed when the new certificate is
1372created. In all situations, the new certificate includes a new serial number and new validity dates
1373[KMIP-Spec] uses the following terminology which is aligned with the definitions found in IETF
1374[RFC3647] and [RFC4949]:

1375

Certificate Renewal: The issuance of a new certificate to the subject without changing
the subject public key or other information (except the serial number and certificate
validity dates) in the certificate.

Certificate Update: The issuance of a new certificate, due to changes in the information
in the certificate other than the subject public key.

Certificate Rekey: The generation of a new key pair for the subject and the issuance of a
new certificate that certifies the new public key.

1376
1377

1378
1379

1380
1381

1382The KMIP Specification supports certificate renewals using the Re-Certify


1383operation and certificate updates using the Certify operation. Certificate
1384rekey is supported through the submission of a Re-key Key Pair operation,
1385which generates a replacement (new) key pair, followed by a Certify
1386operation, which issues a new certificate containing the replacement (new)
1387public key.
13881.45 Key Encoding
1389Two parties receiving the same key as a Key Value Byte String make use of the key in exactly the
1390same way in order to interoperate. To ensure that, it is necessary to define a correspondence
1391between the abstract syntax of Key and the notation in the standard algorithm description that
200kmip-ug-v1.2-cnd01
201Non-Standards Track
202

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 41 of 84

[Type the document title]

13591.43 Revocation Reason Codes

203

204

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

1392defines how the key is used. The next sections establish that correspondence for the algorithms
1393AES [FIPS197] and Triple-DES [SP800-67].
1394
1395AES Key Encoding [FIPS197] section 5.2, titled Key Expansion, uses the input key as an array of
1396bytes indexed starting at 0. The first byte of the Key becomes the key byte in AES that is labeled
1397index 0 in [FIPS197] and the other key bytes follow in index order.
1398
1399Proper parsing and key load of the contents of the Key for AES is determined by using the
1400following Key byte string to generate and match the key expansion test vectors in [FIPS197]
1401Appendix A for the 128-bit (16 byte) AES Cipher Key: 2B 7E 15 16 28 AE D2 A6 AB F7 15 88 09
1402CF 4F 3C.

14031.45.1 Triple-DES Key Encoding

1409Each key in a Triple-DES key bundle is expanded into a key schedule


1410according to a procedure defined in [SP800-67] Appendix A. That procedure
1411numbers the bits in the key from 1 to 64, with number 1 being the left most,
1412or most significant bit. The first byte of the Key is bits 1 through 8 of Key1,
1413with bit 1 being the most significant bit. The second byte of the Key is bits 9
1414through 16 of Key1, and so forth, so that the last byte of the KEY is bits 57
1415through 64 of Key3 (or Key2 for two-key Triple-DES).
1416Proper parsing and key load of the contents of Key for Triple-DES is
1417determined by using the following Key byte string to generate and match the
1418key expansion test vectors in [SP800-67] Appendix B for the key bundle:
1419Key1 = 0123456789ABCDEF
1420Key2 = 23456789ABCDEF01
1421Key3 = 456789ABCDEF0123
14221.46 Using the Same Asymmetric Key Pair in Multiple
1423
Algorithms
1424There are mathematical relationships between certain asymmetric
1425cryptographic algorithms such as the Digital Signature Algorithm (DSA) and
1426Diffie-Hellman (DH) and their elliptic curve equivalents ECDSA and ECDH that
1427allow the same asymmetric key pair to be used in both algorithms. In
1428addition, there are overlaps in the key format used to represent the
1429asymmetric key pair for each algorithm type.
1430Even though a single key pair may be used in multiple algorithms, the KMIP Specification has
1431chosen to specify separate key formats for representing the asymmetric key pair for use in each
1432algorithm. This approach keeps KMIP in line with the reference standards (e.g., NIST [FIPS186205kmip-ug-v1.2-cnd01
206Non-Standards Track
207

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 42 of 84

[Type the document title]

1404A Triple-DES key consists of three keys for the cryptographic engine (Key1,
1405Key2, and Key3) that are each 64 bits (even though only 56 are used); the
1406three keys are also referred to as a key bundle (KEY) [SP800-67].SP800_67 A
1407key bundle may employ either two or three mutually independent keys. When
1408only two are employed (called two-key Triple-DES), then Key1 = Key3.

208

209

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

14334], ANSI [X9.42], etc.) from which the key formats are obtained and the best practice documents
1434(e.g., NIST [SP800-57-1], NIST [SP800-56A] etc.) which recommend that a key pair only be used
1435for one purpose.

14361.47 Cryptographic Length of Asymmetric Keys

1444The RSA public key is comprised of a modulus (n) and an (public) exponent
1445(e). When one indicates that the RSA public key is 2048 bits in length that is
1446a reference to the bit length of the modulus (n) only. So the full length of the
1447RSA public key is actually longer than 2048 bits, since it also includes the
1448length of the exponent (e) and the overhead of the encoding (e.g., ASN.1) of
1449the key material.
1450The RSA private key is comprised of a modulus (n), the public exponent (e),
1451the private exponent (d), prime 1 (p), prime 2 (q), exponent 1 (d mod (p-1)),
1452exponent 2 (d mod (p-1)), and coefficient ((inverse of q) mod p). Once again
1453the 2048 bit key length is referring only to the length of the modulus (n), so
1454the overall length of the private key would be longer given the number of
1455additional components which comprise the key and the overhead of encoding
1456(e.g., ASN.1) of the key material.
1457KMIP implementations need to ensure they do not make assumptions about
1458the actual length of asymmetric (public and private) key material based on
1459the value specified in the Cryptographic Length attribute.
14601.48 Discover Versions
1461The Discover Versions operation allows clients and servers to identify a KMIP
1462protocol version that both client and server understand. The operation was
1463added to KMIP 1.1. KMIP 1.0 clients and servers may therefore not support
1464this operation. If the Discover Versions request is sent to a KMIP 1.0 server
1465and the server does not support the operation, the server returns the
1466Operation Not Supported error.
1467 The operation addresses both the dumb and smart client scenarios.
1468Dumb clients may simply pick the first protocol version that is returned by the
1469server, assuming that the client provides the server with a list of supported
1470protocol version. Smart clients may request the server to return a complete
1471list of supported protocol versions by sending an empty request payload and
1472picking a protocol version that is supported by both client and server.
210kmip-ug-v1.2-cnd01
211Non-Standards Track
212

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 43 of 84

[Type the document title]

1437The value (e.g., 2048 bits) referred to in the KMIP Cryptographic Length
1438attribute for an asymmetric (public or private) key may be misleading, since
1439this length only refers to certain portions of the mathematical values that
1440comprise the key. The actual length of all the mathematical values
1441comprising the public or the private key is longer than the referenced value.
1442This point may be illustrated by looking at the components of a RSA public
1443and private key.

213

214

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

1473Clients specify the protocol version in the request header and optionally
1474provide a list of protocol versions in the request payload. If the protocol
1475version in the request header is not specified in the request payload and the
1476server does not support any protocol version specified in the request payload,
1477the server returns an empty list in the response payload. In this scenario,
1478clients are aware that the request did not result in an error and could
1479communicate with the server using the protocol version specified in the
1480request header.
14811.49 Vendor Extensions
1483 1. Enumerations have specific ranges which are noted as extensions
1484 2. Item Tag values of the form 0x54xxxx are reserved for vendor extensions
1485 3. Attributes may be defined by the client with a x- prefix or by the server
1486
with a y- prefix
1487Extensions may be used by vendors to communicate information between a
1488KMIP client and a KMIP server that is not currently defined within the KMIP
1489specification.
1490A common use of extensions is to allow for the structured definition of
1491attributes using KMIP TTLV encoding rather than encoding vendor specific
1492information in opaque byte strings.
14931.50 Certificate Revocation Lists
1494Any Certificate Revocation List (CRL) checking which may be required for
1495certificate-related operations such as register and re-key should be performed
1496by the client prior to requesting the operation from a server.
14971.51 Using the Raw Key Format Type
1498As defined in Section 2.1.3 of the KMIP Specification V1.1, the raw key
1499format is intended to be used for a key that contains only cryptographic key
1500material, encoded as a string of bytes. The raw key format supports
1501situations such as non-KMIP-aware end-clients are aware how wrapped
1502cryptographic objects (possibly Raw keys) from the KMIP server should be
1503used without having to rely on the attributes provided by the Get Attributes
1504operation and in that regard is similar to the Opaque key format type.
1505 Raw key format is intended to be applied to symmetric keys and not
1506asymmetric keys; therefore, this format is not specified in the asymmetric
1507key profiles included in KMIP V1.1.
15081.52 Use of Meta-Data Only (MDO) Keys
1509Meta-Data Only ( MDO) keys are those Managed Key Objects for which no Key
1510Value is present, as introduced in version 1.2 of [KMIP-Spec] MDO objects can
215kmip-ug-v1.2-cnd01
216Non-Standards Track
217

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 44 of 84

[Type the document title]

1482KMIP allows for vendor extensions in a number of areas:

218

219

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

1511be one of the following: Symmetric Keys, Private Keys, Split Keys, or Secret
1512Data.
1513This may be a result of the KMIP client only wanting to register information
1514(Meta-Data) about the key with a Key Management System, without having
1515the key itself leave the clients physical boundary. One such example could be
1516for keys created and stored within a Hardware Security Module (HSM), with a
1517policy that does not allow for the keys to leave its hardware. In such cases,
1518the KMIP client will not include a Key Value within the Key Block during a
1519Register operation, although it may optionally include a Key Value Location
1520attribute indicating the location of the Key Value instead. For such keys, as
1521part of the Register operation, the server will create a Key Value Present
1522attribute and set it to false to indicate the key value is not stored on the
1523server.

1528Finally, because there is no Key Value associated with an MDO key on the
1529server, KMIP operations for Re-key, Re-key Key Pair and Derive Key cannot be
1530carried out on an MDO key object. An attempt to do so will return an
1531appropriate error as specified in the Error Handling section of [KMIP-Spec].
15321.53 Cryptographic Service
1533KMIP supports creation and registration of managed objects and retrieval of
1534managed objects in both plaintext and optionally wrapped with another
1535managed object. KMIP also includes support for a subset of the operations
1536necessary for certificate management (certifying certificate requests and
1537validating certificate hierarchies). KMIP defines a range of Hash-based and
1538MAC-based key derivation options.
1539There are certain situations in which having capability for a KMIP client to
1540request cryptographic operations from a KMIP server is beneficial in terms of
1541simplifying the client implementation, strengthening the integration between
1542the key management and cryptographic operations, or improving the overall
1543security of a solution.
1544KMIP 1.2 adds support for cryptographic services in the form of client-to1545server operations for cryptographic services using managed objects for
1546encryption, decryption, signature generation, signature verification, MAC
1547generation, MAC verification, random number generation, and general
1548hashing.
1549This support for cryptographic services is similar to the approach taken in
1550KMIP for certificates. The protocol supports a base set of operations on
1551certificates that enable a key manager to act as a proxy for a Certification
220kmip-ug-v1.2-cnd01
221Non-Standards Track
222

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 45 of 84

[Type the document title]

1524The KMIP protocol does not support the addition of a Key Value to an existing
1525MDO key object on the server. If for some reason the client wanted to do this,
1526it would have to carry out another Register operation and create a new
1527managed object with the Key Value.

223

224

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

1552Authority or in fact operate as a Certification Authority in the contexts where


1553that is appropriate. A KMIP server supporting cryptographic services may be
1554acting as a proxy for another cryptographic device or in fact operating as a
1555cryptographic device in the contexts where that is appropriate.

1562Similarly, server policy regarding accepting random from a client (see section
15631.7 regarding server policy) should reflect the level of confidence that that
1564server has in a particular client or all clients. Issues in the quality or integrity
1565of random provided in RNG Seed can affect key creation, nonce and IV
1566generation, client-server TLS session key creation, and the random delivered
1567to clients with the RNG Retrieve Operation. KMIP, as a protocol, does not
1568itself enforce restrictions on the quality or nature of the random provided by a
1569client in the RNG Seed operation.
1570A KMIP server that supports the RNG Retrieve and RNG Seed operations may
1571have a single RNG for the server, an RNG which is shared in an unspecified
1572manner by KMIP clients or a separate RNG for each KMIP client. There is no
1573requirement for the KMIP server to implement any specific RNG model.
15741.54 Passing Attestation Data
1575In some scenarios the server may want assurance of the integrity of the
1576clients system before honoring a clients request. Additionally, the server
1577may want a guarantee of the freshness of the attestation computation in the
1578integrity measurement.
1579Generally, the process takes four passes:
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589

1. The client sends a request to the server which requires attestation.


2. The server returns a random nonce to the client that will be used in the
attestation computation to guarantee the freshness of the
measurement.
3. The client sends a request to the server which includes the
measurement of the clients system, and the measurement contains
the nonce from the server.
4. The server verifies the measurement and sends the appropriate
response to the client.

1590Passing attestation data with a client request can be achieved in KMIP as


1591follows:

225kmip-ug-v1.2-cnd01
226Non-Standards Track
227

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 46 of 84

[Type the document title]

1556KMIP clients and KMIP servers using cryptographic services operations should
1557be mindful of selecting a level of protection for the communication channel
1558(the TLS connection) that provides sufficient protection of the plaintext data
1559included in cryptographic operations and commensurate with the security
1560strength of the operation. There is no requirement for the KMIP server to
1561enforce selection of a level of protection.

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

1592
1593

1. The client sends a request to the server with the Attestation Capable
Indicator set to True in the request header.

1594
1595
1596
1597

2. If the request requires attestation, the server will return an Attestation


Required error with a Nonce object in the response header. {If the
client request fails for any reason other than Attestation Required,
the server will not include a nonce in the error message.}

1598
1599

3. The client uses the nonce received from the server in the attestation
computation that will be used in the measurement.

1600
1601
1602
1603

a. The client forms an Attestation Credential Object which contains


either the measurement from the client or an assertion from a
third party if the server is not capable or willing to verify the
attestation data from the client.

1604
1605

b. The client then issues a request which contains the Attestation


Credential Object in the request header.

1606
1607
1608
1609
1610
1611
1612
1613

4. The server validates the measurement or assertion data in the


Credential Object, checks that the nonce in the Credential Object
matches one sent recently by the server, then sends the appropriate
response to complete the request issued by the client. {If the
measurement or assertion data in the Credential Object does not
validate or if the nonce does not match one sent recently by the
server, the server will return an Attestation Failed error instead of
completing the request issued by the client.}

1614The server needs to be capable of processing and verifying multiple


1615Credential Objects in the same request header since Attestation Credentials
1616do not provide the same type of authentication as the Username and
1617Password or Device Credential.
1618How frequently (e.g. every request, every 100 requests, etc.) the server
1619generates a new random nonce depends on server policy. The lifetime of the
1620nonce once the server has sent it to the client (i.e., the timeframe in which
1621the client must return the nonce before needs to request a fresh nonce from
1622the server) also depends on server policy.
1623If the client sends a request that requires attestation but the client has not
1624set the Attestation Capable Indicator to True, then the server will send a
1625Permission Denied error and will not include a Nonce object in the response
1626header.
16271.55 Split Key
1628KMIP v1.0 and KMIP v1.1 allow a client to register a Split Key that was created
1629or otherwise obtained by the client, but offer no client operations to request a
1630Split Key be generated or recombined by the server. The Create Split Key
230kmip-ug-v1.2-cnd01
231Non-Standards Track
232

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 47 of 84

[Type the document title]

228

229

233

234

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

1631operation and Join Split Key operation are added to KMIP v1.2 to provide a
1632more complete set of split key functionality.

1641The client may want to add link attributes to more easily locate the complete
1642set of related Split Keys as follows. The client adds a Previous Link from the
1643Split Key with Key Part Identifier K to the Split Key with Key Part Identifier K-1
1644and a Next Link to the Split Key with Key Part Identifier K+1. Denoting the
1645value of Split Key Parts by N, the client adds a Previous Link from the Split
1646Key with Key Part Identifier 1 to the Split Key with Key Part Identifier N and a
1647Next Link from the Split Key with Key Part Identifier N to the Split Key with Key
1648Part Identifier 1. If the client supplies the Unique Identifier of an existing base
1649key in a Create Split Key request, the client may want to add a Parent Link
1650attribute from each newly generated Split Key to the base key that was
1651supplied in the Create Split Key request.
1652To request the server recombine a set of split keys, the client sends a Join
1653Split Key request that includes the type of object to be returned (e.g.
1654Symmetric Key, Private Key, or Secret Data) and a list of Unique Identifiers of
1655the Split Keys to be combined. The number of Unique Identifiers in the
1656request needs to be at least the value of Split Key Threshold in the Split Keys
1657to ensure the server will be able to combine the keys according to the Split
1658Key Method. The server will respond with the Unique Identifier of the key
1659obtained by combining the provided Split Keys.
16601.56 Compromised Objects
1661A Cryptographic Object or Opaque Object may be compromised for a variety
1662of reasons. In KMIP, a client indicates to the server that a Cryptographic
1663Object is to be considered compromised by performing a Revoke Operation
1664with a Revocation Reason of Key Compromise or CA Compromise. The KMIP
1665client must provide a Compromise Occurrence Date (if the Revocation Reason
1666is Key Compromise) and if it is unable to estimate when the compromise
1667occurred then it should provide a Compromise Occurrence Date equal to the
1668Initial Date.
1669The KMIP specification [KMIP-Spec] places no requirements on a KMIP server
1670to perform any action on any Managed Object that references (i.e., via Link
1671attributes) a Cryptographic Object or Opaque Object that a client has
1672performed a Revoke operation with a Revocation Reason of Key Compromise
235kmip-ug-v1.2-cnd01
236Non-Standards Track
237

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 48 of 84

[Type the document title]

1633To request the server generate a split key, the client sends a Create Split Key
1634request that includes the Split Key parameters (Split Key Parts, Split Key
1635Threshold, Split Key Method) and desired key attributes (e.g. Object Type,
1636Cryptographic Length). If the client supplies the Unique Identifier of an
1637existing base key in a Create Split Key request, the server will use the
1638supplied key in the key splitting operation instead of generating a new one.
1639The server will respond with a list of Unique Identifiers for the newly created
1640Split Keys.

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

238

239

1673or CA Compromise. However, KMIP users should be aware that there may be
1674security relevant implications in continuing to use a Managed Cryptographic
1675Object in the following circumstances:
1676

For a compromised Private Key, the linked Public Key and/or Certificate;

1677

For a compromised Public Key, the linked Private Key and/or Certificate;

1678
1679

For a compromised Derived Key, the linked derived key and/or Secret
Data Object

1680In these circumstances, it is the responsibility of the client to either check the
1681state of the referenced Managed Object or to also perform a Revoke
1682operation on the referenced Managed Object.
1683

1685The KMIP Specification [KMIP-Spec] (see section 9.1.3.2.5) specifies a number


1686of ECC algorithms. These algorithms are defined in multiple source
1687documents and in some cases, the same algorithm is known by multiple
1688names since to the algorithm is defined in multiple documents. The following
1689table provides a mapping of the ECC algorithms specified in the KMIP
1690specification [KMIP-Spec]. The table identifies the KMIP enumeration, the
1691Object Identifier (OID) and multiples names (synonyms) for the ECC
1692algorithms.
1693
Algorithm
Name

KMIP
Enumeration
Value

OID

Algorithm
Synonym(s)
secp192r1

NIST P-192

00000001

1.2.840.10045.3.1.1

NIST K-163

00000002

1.3.132.0.1

sect163k1

NIST B-163

00000003

1.3.132.0.15

sect163r2

NIST P-224

00000004

1.3.132.0.33

secp224r1

NIST K-233

00000005

1.3.132.0.26

sect233k1

NIST B-233

00000006

1.3.132.0.27

sect233r1

NIST P-256

00000007

1.2.840.10045.3.1.7

NIST K-283

00000008

1.3.132.0.16

240kmip-ug-v1.2-cnd01
241Non-Standards Track
242

ansix9p192v1

secp256r1
ansix9p256v1
sect283k1

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 49 of 84

[Type the document title]

16841.57 Elliptic Curve Cryptography (ECC) Algorithm Mapping

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

NIST B-283

00000009

1.3.132.0.17

sect283r1

NIST P-384

0000000A

1.3.132.0.34

secp384r1

NIST K-409

0000000B

1.3.132.0.36

sect409k1

NIST B-409

0000000C

1.3.132.0.37

sect409r1

NIST P-521

0000000D

1.3.132.0.35

secp521r1

NIST K-571

0000000E

1.3.132.0.38

sect571k1

NIST B-571

0000000F

1.3.132.0.39

sect571r1

secp112r1

00000010

1.3.132.0.6

secp112r2

00000011

1.3.132.0.7

secp128r1

00000012

1.3.132.0.28

secp128r2

00000013

1.3.132.0.29

secp160k1

00000014

1.3.132.0.9

secp160r1

00000015

1.3.132.0.8

secp160r2

00000016

1.3.132.0.30

secp192k1

00000017

1.3.132.0.31

secp192r1

00000001

1.2.840.10045.3.1.1

secp224k1

00000018

1.3.132.0.32

secp224r1

00000004

1.3.132.0.33

secp256k1

00000019

1.3.132.0.10

secp256r1

00000007

1.2.840.10045.3.1.7

secp384r1

0000000A

1.3.132.0.34

NIST P-384

secp521r1

0000000D

1.3.132.0.35

NIST P-521

sect113r1

0000001A

1.3.132.0.4

sect113r2

0000001B

1.3.132.0.5

sect131r1

0000001C

1.3.132.0.22

sect131r2

0000001D

1.3.132.0.23

sect163k1

00000002

1.3.132.0.1

sect163r1

0000001E

1.3.132.0.2

245kmip-ug-v1.2-cnd01
246Non-Standards Track
247

NIST P-192
ansix9p192v1

NIST P-224

NIST P-256
ansix9p256v1

NIST K-163

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 50 of 84

[Type the document title]

243

244

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

sect163r2

00000003

1.3.132.0.15

sect193r1

0000001F

1.3.132.0.24

sect193r2

00000020

1.3.132.0.25

sect233k1

00000005

1.3.132.0.26

NIST K-233

sect233r1

00000006

1.3.132.0.27

NIST B-233

sect239k1

00000021

1.3.132.0.3

sect283k1

00000008

1.3.132.0.16

NIST K-283

sect283r1

00000009

1.3.132.0.17

NIST B-283

sect409k1

0000000B

1.3.132.0.36

NIST K-409

sect409r1

0000000C

1.3.132.0.37

NIST B-409

sect571k1

0000000E

1.3.132.0.38

NIST K-571

sect571r1

0000000F

1.3.132.0.39

NIST B-571

ansix9p192v1

00000001

1.2.840.10045.3.1.1

ansix9p192v2

00000022

1.2.840.10045.3.1.2

ansix9p192v3

00000023

1.2.840.10045.3.1.3

ansix9p239v1

00000024

1.2.840.10045.3.1.4

ansix9p239v2

00000025

1.2.840.10045.3.1.5

ansix9p239v3

00000026

1.2.840.10045.3.1.6

ansix9p256v1

00000007

1.2.840.10045.3.1.7

ansix9c2pnb16
3v1

00000027

ansix9c2pnb16
3v2

00000028

ansix9c2pnb16
3v3

00000029

ansix9c2pnb17
6v1

0000002A

ansix9c2tnb19
1v1

0000002B

ansix9c2tnb19

0000002C

250kmip-ug-v1.2-cnd01
251Non-Standards Track
252

NIST B-163

NIST P-192
secp192r1

NIST P-256
secp256r1

1.2.840.10045.3.0.1
1.2.840.10045.3.0.2
1.2.840.10045.3.0.3
1.2.840.10045.3.0.4
1.2.840.10045.3.0.5
1.2.840.10045.3.0.6
31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 51 of 84

[Type the document title]

248

249

253

254

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

1v2
ansix9c2tnb19
1v3

0000002D

ansix9c2pnb20
8w1

0000002E

1.2.840.10045.3.0.1
0

ansix9c2tnb23
9v1

0000002F

1.2.840.10045.3.0.1
1

ansix9c2tnb23
9v2

00000030

1.2.840.10045.3.0.1
2

ansix9c2tnb23
9v3

00000031

1.2.840.10045.3.0.1
3

ansix9c2pnb27
2w1

00000032

1.2.840.10045.3.0.1
6

ansix9c2pnb30
4w1

00000033

1.2.840.10045.3.0.1
7

ansix9c2tnb35
9v1

00000034

1.2.840.10045.3.0.1
8

ansix9c2pnb36
8w1

00000035

1.2.840.10045.3.0.1
9

ansix9c2tnb43
1r1

00000036

1.2.840.10045.3.0.2
0

Brainpool_P160
r1

00000037

Brainpool_P160
t1

00000038

Brainpool_P192
r1

00000039

Brainpool_P192
t1

0000003A

Brainpool_P224
r1

0000003B

Brainpool_P224
t1

0000003C

Brainpool_P256
r1

0000003D

Brainpool_P256

0000003E

255kmip-ug-v1.2-cnd01
256Non-Standards Track
257

1.3.36.3.3.2.8.1.1.1
1.3.36.3.3.2.8.1.1.2
1.3.36.3.3.2.8.1.1.3
1.3.36.3.3.2.8.1.1.4
1.3.36.3.3.2.8.1.1.5
1.3.36.3.3.2.8.1.1.6
1.3.36.3.3.2.8.1.1.7
1.3.36.3.3.2.8.1.1.8
31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 52 of 84

[Type the document title]

1.2.840.10045.3.0.7

258

259

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

t1
Brainpool_P320
r1

0000003F

Brainpool_P320
t1

00000040

1.3.36.3.3.2.8.1.1.1
0

Brainpool_P384
r1

00000041

1.3.36.3.3.2.8.1.1.1
1

Brainpool_P384
t1

00000042

1.3.36.3.3.2.8.1.1.1
2

Brainpool_P512
r1

00000043

1.3.36.3.3.2.8.1.1.1
3

Brainpool_P512
t1

00000044

1.3.36.3.3.2.8.1.1.1
4

1.3.36.3.3.2.8.1.1.9

[Type the document title]

1694
1695T ABLE 3: ECC A LGORITHM MAPPING

260kmip-ug-v1.2-cnd01
261Non-Standards Track
262

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 53 of 84

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

263

264

1696Applying

KMIP Functionality

1697This section describes how to apply the functionality described in the Key
1698Management Interoperability Protocol Specification to address specific key
1699management usage scenarios or to solve key management related issues.
17001.58 Locate Queries

1703
Exact match of a transition to a given state. Locate the key(s) with a
1704
transition to a certain state at a specified time (t).
1705
Range match of a transition to a given state. Locate the key(s) with a
1706
transition to a certain state at any time at or between two specified
1707
times (t and t).
1708
Exact match of a state at a specified time. Locate the key(s) that are in
1709
a certain state at a specified time (t).
1710
Match of a state during an entire time range. Locate the key(s) that are
1711
in a certain state during an entire time specified with times (t and t).
1712
Note that the Activation Date could occur at or before t and that the
1713
Deactivation Date could occur at or after t+1.
1714
Match of a state at some point during a time range. Locate the key(s)
1715
that are in a certain state at some time at or between two specified
1716
times (t and t). In this case, the transition to that state could be before
1717
the start of the specified time range.
1718This is accomplished by allowing any date/time attribute to be present either
1719once (for an exact match) or at most twice (for a range match).
1720For instance, if the state we are interested in is Active, the Locate queries
1721would be the following (corresponding to the bulleted list above):
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733

Exact match of a transition to a given state: Locate (ActivationDate(t)).


Locate keys with an Activation Date of t.

Range match of a transition to a given state: Locate (ActivationDate(t),


ActivationDate(t')). Locate keys with an Activation Date at or between t
and t.

Exact match of a state at a specified time: Locate (ActivationDate(0),


ActivationDate(t), DeactivationDate(t+1), DeactivationDate(MAX_INT),
CompromiseDate(t+1), CompromiseDate(MAX_INT) ). Locate keys in
the Active state at time t, by looking for keys with a transition to Active
before or until t, and a transition to Deactivated or Compromised after
t (because we don't want the keys that have a transition to
Deactivated or Compromised before t). The server assumes that keys

265kmip-ug-v1.2-cnd01
266Non-Standards Track
267

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 54 of 84

[Type the document title]

1701It is possible to formulate Locate queries to address any of the following


1702conditions:

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

268

269

1749In the case of the Destroyed-Compromise state, there are two dates
1750recorded: the Destroy Date and the Compromise Date. For this state, the
1751Locate operation would be expressed as follows:
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778

Exact match of a transition to a given state: Locate


(CompromiseDate(t), State(Destroyed-Compromised)) and Locate
(DestroyDate(t), State(Destroyed-Compromised)). KMIP does not
support the OR in the Locate request, so two requests should be
issued. Locate keys that were Destroyed and transitioned to the
Destroyed-Compromised state at time t, and locate keys that were
Compromised and transitioned to the Destroyed-Compromised state at
time t.

Range match of a transition to a given state: Locate


(CompromiseDate(t), CompromiseDate(t'), State(DestroyedCompromised)) and Locate (DestroyDate(t), DestroyDate(t'),
State(Destroyed-Compromised)). Locate keys that are DestroyedCompromised and were Compromised or Destroyed at or between t
and t.

Exact match of a state at a specified time: Locate


(CompromiseDate(0), CompromiseDate(t), DestroyDate(0),
DestroyDate(t)); nothing else is needed, since there is no exit
transition. Locate keys with a Compromise Date at or before t, and with
a Destroy Date at or before t. These keys are, therefore, in the
Destroyed-Compromised state at time t.

Match of a state during an entire time range: Locate


(CompromiseDate(0), CompromiseDate(t), DestroyDate(0),
DestroyDate(t)). Same as above. As there is no exit transition from the
Destroyed-Compromised state, the end of the range (t) is irrelevant.

Match of a state at some point during a time range: Locate


(CompromiseDate(0), CompromiseDate(t'-1), DestroyDate(0),
DestroyDate(t'-1)). Locate keys with a Compromise Date at or before t-

270kmip-ug-v1.2-cnd01
271Non-Standards Track
272

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 55 of 84

[Type the document title]

1734
without a DeactivationDate or CompromiseDate is equivalent to
1735
MAX_INT (i.e., infinite).
1736
Match of a state during an entire time range: Locate
1737
(ActivationDate(0), ActivationDate(t), DeactivationDate(t'+1),
1738
DeactivationDate(MAX_INT), CompromiseDate(t'+1),
1739
CompromiseDate(MAX_INT) ). Locate keys in the Active state during
1740
the entire time from t to t.
1741
Match of a state at some point during a time range: Locate
1742
(ActivationDate(0), ActivationDate(t'-1), DeactivationDate(t+1),
1743
DeactivationDate(MAX_INT), CompromiseDate(t+1),
1744
CompromiseDate(MAX_INT)). Locate keys in the Active state at some
1745
time from t to t, by looking for keys with a transition to Active between
1746
0 and t-1 and exit out of Active on or after t+1.
1747The queries would be similar for Initial Date, Deactivation Date, Compromise
1748Date and Destroy Date.

273

274
1779
1780
1781

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

1, and with a Destroy Date at or before t-1. As there is no exit


transition from the Destroyed-Compromised state, the start of the
range (t) is irrelevant.

17821.59 Using Wrapped Keys with KMIP

1794The Key Value includes both the Key Material and, optionally, attributes of the
1795key; these may be provided by the client in the Register Request Payload; the
1796server only includes attributes when requested in the Key Wrapping
1797Specification of the Get Request Payload. The Key Value may be encrypted,
1798signed/MACed, or both encrypted and signed/MACed (and vice versa). In
1799addition, clients have the option to request or import a wrapped Key Block
1800according to standards, such as ANSI TR-31, or vendor-specific key wrapping
1801methods.
1802It is important to note that if the Key Wrapping Specification is included in the
1803Get Request Payload, the Key Value may not necessarily be encrypted. If the
1804Wrapping Method is MAC/sign, the returned Key Value is in plaintext, and the
1805Key Wrapping Data includes the MAC or Signature of the Key Value.
1806Prior to wrapping or unwrapping a key, the server should verify that the
1807wrapping key is allowed to be used for the specified purpose. For example, if
1808the Unique ID of a symmetric key is specified in the Key Wrapping
1809Specification inside the Get request, the symmetric key should have the
1810Wrap Key bit set in its Cryptographic Usage Mask. Similarly, if the client
1811registers a signed key, the server should verify that the Signature Key, as
1812specified by the client inside the Key Wrapping Data, has the Verify bit set
1813in the Cryptographic Usage Mask. If the wrapping key is not permitted to be
1814used for the requested purpose (e.g., when the Cryptographic Usage Mask is
1815not set), the server should return the Operation Failed result status.
18161.59.1 Encrypt-only Example with a Symmetric Key as an
1817
Encryption Key for a Get Request and Response
1818The client sends a Get request to obtain a key that is stored on the server.
1819When the client sends a Get request to the server, a Key Wrapping
275kmip-ug-v1.2-cnd01
276Non-Standards Track
277

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 56 of 84

[Type the document title]

1783KMIP provides the option to register and get keys in wrapped format. Clients
1784request the server to return a wrapped key by including the Key Wrapping
1785Specification in the Get Request Payload. Similarly, clients register a wrapped
1786key by including the Key Wrapping Data in the Register Request Payload. The
1787Wrapping Method identifies the type of mechanism used to wrap the key, but
1788does not identify the algorithm or block cipher mode. It is possible to
1789determine these from the attributes set for the specified Encryption Key or
1790MAC/Signing Key. If a key has multiple Cryptographic Parameters set, clients
1791may include the applicable parameters in Key Wrapping Specification. If
1792omitted, the server chooses the Cryptographic Parameter attribute with the
1793lowest index.

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

278

279

1820Specification may be included. If a Key Wrapping Specification is included in


1821the Get request, and a client wants the requested key and its Cryptographic
1822Usage Mask attribute to be wrapped with AES key wrap, the client includes
1823the following information in the Key Wrapping Specification:
1824

Wrapping Method: Encrypt

1825

Encryption Key Information

Unique Key ID: Key ID of the AES wrapping key

1827
Cryptographic Parameters: The Block Cipher Mode is NISTKeyWrap
1828
(not necessary if default block cipher mode for wrapping key is
1829
NISTKeyWrap)
1830
Attribute Name: Cryptographic Usage Mask
1831The server uses the Unique Key ID specified by the client to determine the
1832attributes set for the proposed wrapping key. For example, the algorithm of
1833the wrapping key is not explicitly specified inside the Key Wrapping
1834Specification. The server determines the algorithm to be used for wrapping
1835the key by identifying the Algorithm attribute set for the specified Encryption
1836Key.
1837The Cryptographic Parameters attribute should be specified by the client if
1838multiple instances of the Cryptographic Parameters exist, and the lowest
1839index does not correspond to the NIST key wrap mode of operation. The
1840server should verify that the AES wrapping key has NISTKeyWrap set as an
1841allowable Block Cipher Mode, and that the Wrap Key bit is set in the
1842Cryptographic Usage Mask.
1843If the correct data was provided to the server, and no conflicts exist, the
1844server AES key wraps the Key Value (both the Key Material and the
1845Cryptographic Usage Mask attribute) for the requested key with the wrapping
1846key specified in the Encryption Key Information. The wrapped key (byte
1847string) is returned in the servers response inside the Key Value of the Key
1848Block.
1849The Key Wrapping Data of the Key Block in the Get Response Payload
1850includes the same data as specified in the Key Wrapping Specification of the
1851Get Request Payload except for the Attribute Name.
18521.59.2 Encrypt-only Example with a Symmetric Key as an
1853
Encryption Key for a Register Request and Response
1854The client sends a Register request to the server and includes the wrapped
1855key and the Unique ID of the wrapping key inside the Request Payload. The
1856wrapped key is provided to the server inside the Key Block. The Key Block
1857includes the Key Value Type, the Key Value, and the Key Wrapping Data. The
1858Key Value Type identifies the format of the Key Material, the Key Value
1859consists of the Key Material and optional attributes that may be included to
1860cryptographically bind the attributes to the Key Material, and the Key
280kmip-ug-v1.2-cnd01
281Non-Standards Track
282

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 57 of 84

[Type the document title]

1826

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

283

284

1861Wrapping Data identifies the wrapping mechanism and the encryption key
1862used to wrap the object and the wrapping mechanism.
1863Similar to the example in 4.2.1 the key is wrapped using the AES key wrap.
1864The Key Value includes four attributes: Cryptographic Algorithm,
1865Cryptographic Length, Cryptographic Parameters, and Cryptographic Usage
1866Mask.
1867The Key Wrapping Data includes the following information:
1868

Wrapping Method: Encrypt

1869

Encryption Key Information

Unique Key ID: Key ID of the AES wrapping key

1871
Cryptographic Parameters: The Block Cipher Mode is NISTKeyWrap
1872
(not necessary if default block cipher mode for wrapping key is
1873
NISTKeyWrap)
1874Attributes do not need to be specified in the Key Wrapping Data. When
1875registering a wrapped Key Value with attributes, clients may include these
1876attributes inside the Key Value without specifying them inside the Template1877Attribute.
1878Prior to unwrapping the key, the server determines the wrapping algorithm
1879from the Algorithm attribute set for the specified Unique ID in the Encryption
1880Key Information. The server verifies that the wrapping key may be used for
1881the specified purpose. In particular, if the client includes the Cryptographic
1882Parameters in the Encryption Key Information, the server verifies that the
1883specified Block Cipher Mode is set for the wrapping key. The server also
1884verifies that the wrapping key has the Unwrap Key bit set in the
1885Cryptographic Usage Mask.
1886The Register Response Payload includes the Unique ID of the newly registered
1887key and an optional list of attributes that were implicitly set by the server.
18881.59.3 Encrypt-only Example with an Asymmetric Key as an
1889
Encryption Key for a Get Request and Response
1890The client sends a Get request to obtain a key (either symmetric or
1891asymmetric) that is stored on the server. When the client sends a Get request
1892to the server, a Key Wrapping Specification may be included. If a Key
1893Wrapping Specification is included, and the key is to be wrapped with an RSA
1894public key using the OAEP encryption scheme, the client includes the
1895following information in the Key Wrapping Specification. Note that for this
1896example, attributes for the requested key are not requested.
1897

Wrapping Method: Encrypt

1898

Encryption Key Information

1899

Unique Key ID: Key ID of the RSA public key

285kmip-ug-v1.2-cnd01
286Non-Standards Track
287

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 58 of 84

[Type the document title]

1870

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

288

289

1900
1901
1902

Cryptographic Parameters:
Padding Method: OAEP
Hashing Algorithm: SHA-256

1903The Cryptographic Parameters attribute is specified by the client if multiple


1904instances of Cryptographic Parameters exist for the wrapping key, and the
1905lowest index does not correspond to the associated padding method. The
1906server should verify that the specified Cryptographic Parameters in the Key
1907Wrapping Specification and the Wrap Key bit in the Cryptographic Usage
1908Mask are set for the corresponding wrapping key.
1909The Key Wrapping Data returned by the server in the Key Block of the Get
1910Response Payload includes the same data as specified in the Key Wrapping
1911Specification of the Get Request Payload.

19161.59.4 MAC-only Example with an HMAC Key as an Authentication


1917
Key for a Get Request and Response
1918The client sends a Get request to obtain a key that is stored on the server.
1919When the client sends a Get request to the server, a Key Wrapping
1920Specification may be included. If a key and Custom Attribute (i.e., x-Nonce) is
1921to be MACed with HMAC SHA-256, the following Key Wrapping Specification is
1922specified:
1923

Wrapping Method: MAC/sign

1924

MAC/Signature Key Information

1925
Unique Key ID: Key ID of the MACing key (note that the algorithm
1926
associated with this key would be HMAC-SHA256)
1927
Attribute Name: x-Nonce
1928For HMAC, no Cryptographic Parameters need to be specified, since the
1929algorithm, including the hash function, may be determined from the
1930Algorithm attribute set for the specified MAC Key. The server should verify
1931that the HMAC key has the MAC Generate bit set in the Cryptographic
1932Usage Mask. Note that an HMAC key does not require the Wrap Key bit to
1933be set in the Cryptographic Usage Mask.
1934The server creates an HMAC value over the Key Value if the specified MACing
1935key may be used for the specified purpose and no conflicts exist. The Key
1936Value is returned in plaintext, and the Key Block includes the following Key
1937Wrapping Data:
1938

Wrapping Method: MAC/sign

290kmip-ug-v1.2-cnd01
291Non-Standards Track
292

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 59 of 84

[Type the document title]

1912For both OAEP and PSS, KMIP assumes that the Hashing Algorithm specified in
1913the Cryptographic Parameters of the Get request is used for both the Mask
1914Generation Function (MGF) and hashing data. The example above requires
1915the server to use SHA-256 for both purposes.

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

293

294
1939

MAC/Signature Key Information

1940

Unique Key ID: Key ID of the MACing key

1941
MAC/Signature: HMAC result of the Key Value
1942In the example, the custom attribute x-Nonce was included to help clients,
1943who are relying on the proxy model, to detect replay attacks. End-clients, who
1944communicate with the key management server, may not support TLS and
1945may not be able to rely on the message protection mechanisms provided by a
1946security protocol. An alternative approach for these clients would be to use
1947the custom attribute to hold a random number, counter, nonce, date, or time.
1948The custom attribute needs to be created before requesting the server to
1949return a wrapped key and is recommended to be set if clients frequently
1950wrap/sign the same key with the same wrapping/signing key.

1953Clients may want to register and store a wrapped key on the server without
1954the server being able to unwrap the key (i.e., the wrapping key is not known
1955to the server). Instead of storing the wrapped key as an opaque object,
1956clients have the option to store the wrapped key inside the Key Block as an
1957opaque cryptographic object, i.e., the wrapped key is registered as a
1958managed cryptographic object, but the encoding of the key is unknown to the
1959server. Registering an opaque cryptographic object allows clients to set all
1960the applicable attributes that apply to cryptographic objects (e.g.,
1961Cryptographic Algorithm and Cryptographic Length),
1962Opaque cryptographic objects are set by specifying the following inside the
1963Key Block structure:
1964

Key Format Type: Opaque

1965

Key Material: Wrapped key as a Byte String

1966The Key Wrapping Data does not need to be specified.

19671.59.6 Encoding Option for Wrapped Keys


1968KMIP provides the option to specify the Encoding Option inside the Key
1969Wrapping Specification and Key Wrapping Data. This option allows users to
1970Get or Register the Key Value in a non-TTLV encoded format. This may be
1971desirable in a proxy environment, where the end-client is not KMIP-aware.
1972The Encoding Option is only available if no attributes are specified inside the
1973Key Value. The server returns the Encoding Option Error if both the Encoding
1974Option and Attribute Names are specified inside the Key Wrapping
1975Specification. Similarly, the server is expected to return the Encoding Option
1976Error when registering a wrapped object with attributes inside the Key Value
1977and the Encoding Option is set in the Key Wrapping Data. If no Encoding
1978Option is specified, KMIP assumes that the Key Value is TTLV-encoded. Thus,
295kmip-ug-v1.2-cnd01
296Non-Standards Track
297

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 60 of 84

[Type the document title]

19511.59.5 Registering a Wrapped Key as an Opaque Cryptographic


1952
Object

298

299

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

1979by default, the complete TTLV-encoded Key Value content, as shown in the
1980example below, is wrapped:
1981Key Material || Byte String

|| Length

1982420043

|| 00000010 || 0123456789ABCDEF0123456789ABCDEF

|| 08

|| Key Material Value

1991It is important to be aware of the risks involved when excluding the attributes
1992from the Key Value. Binding the attributes to the key material in certain
1993environments is essential to the security of the end-client. An untrusted proxy
1994could change the attributes (provided separately via the Get Attributes
1995operation) that determine how the key is being used (e.g., Cryptographic
1996Usage). Including the attributes inside the Key Value and cryptographically
1997binding it to the Key Material could prevent potential misuse of the
1998cryptographic object and may prevent a replay attack if, for example, a nonce
1999is included as a custom attribute. The exclusion of attributes and therefore
2000the usage of the Encoding Option are only recommended in at least one of
2001the following scenarios:
2002 1. End-clients are registered with the KMIP server and are communicating
2003
with the server directly (i.e., the TLS connection is between the server and
2004
client).
2005 2. The environment is controlled and non-KMIP-aware end-clients are aware
2006
how wrapped cryptographic objects (possibly Raw keys) from the KMIP
2007
server should be used without having to rely on the attributes provided by
2008
the Get Attributes operation.
2009 3. The wrapped cryptographic object consists of attributes inside the Key
2010
Material value. These attributes are not interpreted by the KMIP server,
2011
but are understood by the end-client. This may be the case if the Key
2012
Format Type is opaque or vendor-specific.
2013 4. The proxy communicating with the KMIP server on behalf of the end-client
2014
is considered to be trusted and is operating in a secure environment.
2015Registering a wrapped object without attributes is not recommended in a
2016proxy environment, unless scenario 4 is met.
20171.60 Interoperable Key Naming for Tape
2018This section describes methods and provides examples for creating and
2019storing key identifiers that are interoperable across multi-vendor KMIP clients,
2020using the KMIP Tape Library Profile Version 1.0.
300kmip-ug-v1.2-cnd01
301Non-Standards Track
302

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 61 of 84

[Type the document title]

1983Some end-clients may not understand or have the space for anything more
1984than the actual key material (i.e., 0123456789ABCDEF0123456789ABCDEF in
1985the above example). To wrap only the Key Material value during a Get
1986operation, the Encoding Option (00001 for no encoding) should be specified
1987inside the Key Wrapping Specification. The same Encoding Option should be
1988specified in the Key Wrapping Data when returning the non-TTLV encoded
1989wrapped object inside the Get Response Payload or when registering a
1990wrapped object in non-TTLV encoded format.

303

304

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

20211.60.1 Native Tape Encryption by a KMIP Client


2022A common method for naming and retrieving keys is needed to support
2023moving tape cartridges between 2 or more KMIP-compliant tape libraries that
2024are all registered with the same KMIP key manager.
20251.60.1.1 Method Overview
2026The method uses the KMIP Tape Library Profile. This profile specifies use of
2027the KMIP Application Specific Information (ASI) attribute. The method
2028supports both client-generated and server-generated key identifiers.
2029The key identifier is a KMIP string, composed of hexadecimal numeric
2030characters. This string of characters is unique within a chosen namespace.
2031Methods of generating the string are determined by policy. The LIBRARY-LTO
2032namespace is preferred for maximum interoperability.

2036Interoperability is achieved by a) standardized algorithms to map byte values


2037between the numeric (KAD) and text (ASI) representations of the identifier;
2038and b) standardized ordering of bytes within the KAD so the identifier can be
2039re-assembled in the correct sequence by other compliant implementations.
2040Examples of the algorithms are provided below.
20411.60.1.2 Definitions
2042Key Associated Data (KAD): Part of the tape format. May be segmented into
2043authenticated and unauthenticated fields. KAD usage is detailed in the SCSI
2044SSC-3 standard from the T10 organization.
2045Application Specific Information (ASI): A KMIP attribute.
2046Hexadecimal numeric characters: Case-sensitive, printable, single byte ASCII
2047characters representing the numbers 0 through 9 and uppercase alpha A
2048through F. (US-ASCII characters 30h-39h and 41h-46h).
2049
2050Hexadecimal numeric characters are always paired, each pair representing a
2051single 8-bit numeric value. A leading zero character is provided, if necessary,
2052so that every byte in the tapes KAD is represented by exactly 2 hexadecimal
2053numeric characters.
2054N(k): The number of bytes in the tape format combined KAD fields (both
2055authenticated and unauthenticated).
2056N(a), N(u): The number of bytes in the tape formats authenticated, and
2057unauthenticated KAD fields, respectively.

305kmip-ug-v1.2-cnd01
306Non-Standards Track
307

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 62 of 84

[Type the document title]

2033A compressed (numeric) transformation of the identifier string is stored in the


2034tape formats Key Associated Data. This allows for future retrieval of the key
2035for decryption.

308

309

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

20581.60.1.3 Implementation Example of Algorithm 1. Key identifier string


2059
to numeric direction (Converting the ASI string to tape formats
2060
KAD)
2061Refer to the KMIP Tape profile for algorithm 1.
2062This algorithm is associated with writing the KAD, typically to allow future
2063retrieval of a key. An example implementation is as follows.
The client creates a key identifier or obtains one from the server. The
identifier is a KMIP string of hexadecimal numeric characters. Copy the
string to an input buffer of size 2*N(k) bytes. For LTO4, an 88 character
string is sufficient to represent any key name stored directly in the KAD
fields. For LTO5, a 184 character string is sufficient to represent any key
name stored directly in the KAD fields.
Define output buffers for unauthenticated KAD, and authenticated KAD, of
size N(u) and N(a) respectively. For LTO4, this would be 32 bytes of
unauthenticated data, and 12 bytes of authenticated data. For LTO5, this
would be 32 bytes of unauthenticated data and 60 bytes of authenticated
data.
Define the standard POSIX (also known as C) locale. Each character in the
string is a single-byte US-ASCII character.
First, populate the authenticated KAD buffer, converting a sub-string
consisting of the last (rightmost) 2*N(a) characters of the key identifier
string.
When the authenticated KAD is filled, next populate the unauthenticated
KAD buffer, by converting the remaining hexadecimal character pairs (if
any) of the identifier string.

20831.60.1.4 Implementation Example of Algorithm 2. Numeric to key


2084
identifier string direction (Converting tape formats KAD to ASI
2085
string)
2086This algorithm is associated with reading the KAD, typically in preparation for
2087retrieving a key. An example implementation is as follows
20881. Define an input buffer sized for N(k). For LTO4, N(k) is 44 bytes (12 bytes
2089
authenticated, 32 unauthenticated). For LTO5, N(k) is 92 bytes (60 bytes
2090
authenticated, 32 bytes unauthenticated).
20912. Define an output buffer sufficient to contain a string with a maximum
2092
length of 2*N(k) bytes.
20933. Define the standard POSIX (also known as C) locale. Each character in the
2094
string is a single-byte US-ASCII character.
20954.
2096
2097
2098
2099

First, copy the tape formats unauthenticated KAD data (if any) to the
input buffer. Next, bytes from the authenticated KAD are concatenated,
after the unauthenticated bytes. In many implementations the
unauthenticated KAD is empty, and in those cases the entire input buffer
will be populated with bytes from authenticated KAD.

310kmip-ug-v1.2-cnd01
311Non-Standards Track
312

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 63 of 84

[Type the document title]

20641.
2065
2066
2067
2068
2069
20702.
2071
2072
2073
2074
20753.
2076
20774.
2078
2079
20805.
2081
2082

313

314

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

21005. For each byte in the input buffer, convert to US-ASCII as follows:
21016.
2102
2103
2104

Convert the byte's value to exactly 2 hexadecimal numeric characters,


including a leading 0 where necessary. Append these 2 numeric
characters to the output buffer, with the high-nibble represented by the
left-most hexadecimal numeric character.

21051.60.1.5 Usage Example


2106The following usage example will create a key identifier which can be stored
2107in ASI. The identifier will then be translated for storage into a tape formats
2108KAD, using algorithm 1. Both LTO4 and LTO5 examples of KAD contents are
2109provided.

2113Example of creating a key identifier. Implementation-specific material is


2114used to generate a key identifier. The content of this material is based on
2115server or client policy. An example of a text string which could be used to
2116generate a KMIP key identifier for tape is as follows.
2117SN123456_MFR:XYZ INC_BAR12345_TM20131234
2118This example is a set of 40 characters which will be used to create a KMIP key
2119identifier for use as specified in the KMIP Tape Profile. Every 8 th character is
2120bold.
2121This set of characters is suitable as a key identifier for either LTO4 or LTO5,
2122since it will fit within the smaller 44 character KAD space of LTO4.
2123The corresponding KMIP key identifier, which is a string of hexadecimal
2124numeric character pairs, is shown below. This string will be stored in ASI
2125Application Data.
212653 4E 31 32 33 34 35 36 5F 4D 46 52 3A 58 59 5A 20 49 4E 43 5F 42 41 52
2127 31 32 33 34 35 5F 54 4D 32 30 31 33 31 32 33 34
2128Spaces are shown for to improve readability, but are NOT part of the ASI
2129string. Every 8th hexadecimal numeric pair is bold.
2130Note the identifier has exactly 2x more characters than the material used to
2131generate the KMIP key identifier.
2132Translating the key identifier to KAD bytes (LTO4). The corresponding
2133KAD content, for use with an LTO4 tape cartridge is shown in the following
2134figure.

315kmip-ug-v1.2-cnd01
316Non-Standards Track
317

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 64 of 84

[Type the document title]

2110The reverse translation from KAD bytes to the KMIP key identifier is not
2111shown, but would be accomplished via algorithm 2. This re-constructed key
2112identifier string would be used to Locate the key via ASI.

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

2135
2136

FIGURE 2: KAD C ONTENT

FOR

LTO4

2137Each square is 1 byte (8 bits). The contents of each square is the 8 bit value
2138which represents a pair of hexadecimal numeric characters in the KMIP key
2139identifier string.
2140Every 8th byte of KAD is shaded.
2141The KAD was populated by converting the rightmost 24 characters (12
2142character pairs) of the identifier string into bytes of authenticated KAD. The
2143remaining characters of the identifier were written to unauthenticated KAD.
2144Translating the key identifier to KAD bytes (LTO5). The corresponding
2145KAD for use with an LTO5 and later tape cartridge is shown in the following
2146figure.

320kmip-ug-v1.2-cnd01
321Non-Standards Track
322

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 65 of 84

[Type the document title]

318

319

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

2147
FIGURE 3: KAD C ONTENT

2148

FOR

LTO5

2149Each square is 1 byte (8 bits). The contents of each square is the 8 bit value
2150which represents a pair of hexadecimal numeric characters in the key
2151identifier string.
2152Every 8th byte of KAD is shaded.
2153The KAD was populated by converting the rightmost 80 characters (40
2154character pairs) of the identifier string into bytes of authenticated KAD. The
2155unauthenticated KAD is not used because all of the data fits within
2156authenticated KAD.
21571.61 Query Extension Information
2158The Extension Information structure added to KMIP 1.1 and the Query
2159Extension List and Query Extension Map functions of the Query Operation
2160provide a mechanism for a KMIP client to be able to determine which
2161extensions a KMIP server supports.
2162A client may request the list of Extensions supported by a KMIP 1.1 server by
2163specifying the Query Extension List value in the Query Function field. This
2164provides the names of the supported extensions.
2165Example output:
2166

Extension Information

325kmip-ug-v1.2-cnd01
326Non-Standards Track
327

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 66 of 84

[Type the document title]

323

324

328

329

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

2167
2168

Extension Name: ACME LOCATION


Extension Information

2169

Extension Name: ACME ZIP CODE

2171A client may request the details of Extensions supported by a KMIP 1.1 server
2172by specifying the Query Extension Map value in the Query Function field. This
2173provides the names of the supported extensions.
2174Example output:
Extension Information

2176

Extension Name: ACME LOCATION

2177

Extension Tag: 0x54AA01

2178

Extension Type: Text String

2179

Extension Information

2180

Extension Name: ACME ZIP CODE

2181

Extension Tag: 0x54AA02

2182

Extension Type: Integer

21831.62 Registering Extension Information


2184As tag values and their interpretation for the most part should be known for a
2185client and server to meaningfully use an extension, the following registration
2186procedure should be used.
2187 1. Document the Extensions including:
2188
a.
Extension Tag, Extension Name, Extension Type values to be
2189
reserved
2190
b.
A brief description of the purpose of the Extension
2191
c.
Example use case messages (requests and responses)
2192
d.
Example Guidance
2193 2. Send the Document to the KMIP TC requesting review
2194 3. Request a KMIP TC ballot on accepting the reservation of the Extension
2195It is anticipated that a template document may be produced for this
2196registration process.
21971.63 Using KMIP for PGP Keys
2198PGP, both as vendor product and as standard, provides a rich environment for
2199key management that addresses significant use cases related to such areas
2200as secure exchange of email, documents and other resources. Although KMIP
2201is by no means required for support of PGP environments, it can provide a
330kmip-ug-v1.2-cnd01
331Non-Standards Track
332

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 67 of 84

[Type the document title]

2175

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

333

334

2202valuable mechanism for movement of PGP keys between a particular PGP


2203environment, such as Symantec Encryption Management Server (SEMS, ne
2204PGP Universal), and another key management environment.
2205KMIP does not attempt to represent the full range of functionality in PGP
2206environments. However, the use cases related to movement of PGP keys
2207across environments, described in the KMIP Use Cases document, can be
2208supported by taking advantage both of the PGP-specific capabilities in KMIP,
2209such as the PGP Key object introduced in KMIP V1.2, and of KMIP messages,
2210objects, operations and attributes in general.
2211In order to support the PGP use cases, KMIP V1.2 introduces new capabilities:

PGP Key managed object


Alternative Name attribute
Enhancements to Link attribute

2215The PGP Key managed object contains a PGP key (specified in [RFC4880]) as an opaque blob.
2216KMIP compliant servers do not need to understand the fine structure of PGP keys. The intention
2217here is that PGP-enabled clients be able to discover the PGP Key managed cryptographic
2218objects by searching for one of the various names contained within the block. The Alternative
2219Name attribute can be used to specify one or more names (e.g. User IDs) that are attached to the
2220PGP Key object. The PGP-enabled clients are expected to digest the PGP Key object and
2221properly assign these Alternative Name attributes on to the cryptographic managed object. The
2222KMIP server does not have to do this work.

2223Internally, PGP keys may contain many public-private key pairs, each tied to a
2224specific type of encryption operations (one key for signing, one for
2225encryption, and one to tie the other two together in a trust relationship is one
2226typical arrangement.) The Link attribute supports new values that enable the
2227description of this set of PGP Key relationships. The new values are parent,
2228child, previous and next. For example, the private and public keys associated
2229with a PGP Key can be pointed to from the PGP Key with the child link
2230attribute. Additional Decryption Keys (ADK) can be pointed to from the PGP
2231Key with the child link attribute and can be point to each other with the
2232previous and next link attributes. In this way, the link attributes can be
2233used to define the structural relationships required to establish the web of
2234trust for a PGP Key.
2235As mentioned above, KMIP does not attempt to represent all the information
2236about PGP keys that would be managed within a PGP implementation. For
2237example, policies such as algorithms supported, by a PGP key are not
2238expressed within KMIP. Instead, KMIP enables the specification of these
2239attributes, if necessary, as information enclosed within the opaque value
2240defined for a given PGP key. This information would be handled by security
2241administration and out-of-band coordination between the PGP environments
2242that participate in the KMIP exchanges related to PGP keys.
2243KMIP complaint servers are not expected to be able to create PGP Key objects
2244from scratch. PGP-enabled clients will do the key creation and pass the
2245resulting information up to KMIP.
335kmip-ug-v1.2-cnd01
336Non-Standards Track
337

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 68 of 84

[Type the document title]

2212
2213
2214

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

338

339

22461.64 KMIP Client Registration Models


2247The KMIP V1.2 Use Cases [KMIP-UC] document describes several common
2248approaches to registering KMIP clients with KMIP servers:
2249
Manual client registration within a single trust boundary
2250

Automatic client registration across multiple trust boundaries

2251

Configuring a KMIP Server for use with Automatic Client Registration

2252As described in that document, the goal of these three use cases is to
2253establish the KMIP-interoperable secure channel or channels between KMIP
2254servers and clients, such as a mutually-authenticated TLS channel.

2260Reflecting common usage for KMIP, all three of the scenarios described below
2261discuss the use of X.509 certificates for trust establishment; other
2262mechanisms, such as quantum key distribution, may be used instead but are
2263not described here. Similarly, all three scenarios describe the establishment
2264of a mutually-authenticated TLS connection as the basis trusted exchange of
2265KMIP messages, corresponding to the published KMIP authentication suite
2266profiles; other authentication mechanisms can be used with KMIP, but are not
2267described here.
22681.64.1 Manual Client Registration
2269The use case process flow in section 7.1 of the KMIP Use Cases [KMIP-UC]
2270document describes the interaction between human actors responsible for
2271the client and server systems, resulting in the client administrator receiving a
2272registration packet that can be used to authenticate the client to the server
2273and to confirm the authentication of the server by the client.
2274In this approach, there is no assumption of pre-population of authentication
2275credentials in the client, such as by installing an X.509 certificate into a tape
2276library or drive during the manufacturing process. Rather, a credential is
2277propagated out-of-band to the client administrator, who installs it into the
2278client environment. The credential is then used on initial and subsequent
2279contact between the client and server systems.

340kmip-ug-v1.2-cnd01
341Non-Standards Track
342

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 69 of 84

[Type the document title]

2255The use cases establish high-level process flows for these three approaches
2256to establishing the mutually-authenticated TLS channel described in the KMIP
2257authentication suite profiles. In order to support the goal of establishing an
2258interoperable approach to establishing this channel, this section provides
2259more detailed information about these approaches to client registration.

343

344

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

2286possibly additional information that can be included in the credential of the


2287KMIP message sent across the established channel, such as to provide finer
2288granularity for particular drives within a tape library. As indicated, the use of
2289this package of materials takes place during two phases: first during the
2290establishment of the TLS secure channel; second during the transmission of
2291KMIP messages. The server administrator must have configured the server to
2292recognize the X.509 certificate presented by the client, to present the correct
2293X.509 certificate of its own to the client in return and to recognize the
2294additional information provided in the credential object in the KMIP message,
2295if any.

2303The use of additional information as the credential in the KMIP message is


2304also neither required nor a default. Inclusion of such a credential in the
2305package distributed to the client administrator and in one or more KMIP
2306messages is also, therefore, likely to vary across vendors.
23071.64.2 Automated Client Registration
2308The use case in section 7.2 of the KMIP Use Cases [KMIP-UC] document that
2309the credential used to establish a mutually-authenticated TLS connection is
2310not provided in the package provided by the server administrator. Instead,
2311the establishment of trust between the client and server is accomplished by
2312some other mechanism. In one common version of this approach, an X.509
2313certificate is installed in a client device during the manufacturing process.
2314This certificate is then used as a bootstrap mechanism for the subsequent
2315exchange of the kind of information exchanged between client administrator
2316and server administrator in section 1.64.1.
2317As described in this use case (see KMIP Use Case [KMIP-UC] section 7.2),
2318there will be typically be configuration activity for the client device based on
2319information, such as a Service ID, received from the server administrator.
2320Once the client administrator initiates auto-registration, the client device
2321sends the X.509 certificate to the server, for example in order to use it to
2322establish an initial TLS session. The server then sends the equivalent of the
2323registration packet in section 1.64.1 above to the client and the client returns
2324the certificate to be used for establishing the secure TLS channel with the
2325server.
2326In this model, one common variant is to require administrator intervention to
2327determine whether the initial client certificate should be accepted. The
345kmip-ug-v1.2-cnd01
346Non-Standards Track
347

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 70 of 84

[Type the document title]

2296In this model, KMIP is not used to transmit the X.509 certificate and server
2297information used in establishing the secure channel. There is nothing to
2298prevent KMIP being used to send this information; but commonly this is done
2299using mechanisms other than KMIP, nor is there any expectation that KMIP is
2300a required or default mechanism for propagating the credential and the
2301information. The distribution mechanism, therefore, may well vary across
2302vendors.

348

349

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

2328scenario above assumes that the return of the servers packet of registration
2329is immediate and automatic; alternatively, the return of the packet of
2330information may be done manually by the server administrator, as in section
23311.64.1 above; or the return of the packet of server information may be done
2332by the server, but only after that action has been approved by an
2333administrator.
2334As discussed in section 1.64.1, KMIP can be used by the client in sending the
2335X.509 certificates to the server. However, this is not required and is currently
2336not typical. If it is sent to the server using a KMIP register operation, the
2337server must be able to distinguish that this operation is intended not only to
2338register the cryptographic object, but also to initiate the registration of the
2339client as a legitimate participant in KMIP message exchange.

2341The third use case described in the KMIP Use Cases [KMIP-UC] document
2342contains additional information about setting up the KMIP server to
2343participate in automatic client registration described in section 1.64.2,
2344particularly in terms of the distribution of the service ID for the server.
2345Although not described in this use case, it does point to a third common
2346model for registering sub-clients of a trusted client. In this model, the
2347establishment of trust between the client and server can be accomplished
2348using either of the approaches in section 1.64.1 or 1.64.2. However, the
2349server may also send additional information to the client, such as a tenant
2350identifier, which it will have to provide to sub-clients for them to use they
2351attempt to register individually. The individual sub-clients would follow a
2352registration model such a s that described in section 1.64.2, but would also
2353provide the tenant identifier along with the X.509 certificate so that the
2354server can decide whether to accept the client, based on such criteria as the
2355TCP/IP address of the sub-client relative to that of the primary client.
2356This approach is common for tiered clients such as virtual machines that
2357need to be grouped based on their association with a larger trusted entity,
2358but that also need individual identities and trust relationships established
2359based on those identities.
2360KMIP can be used for sending both the client certificate and the tenant
2361identifier to the server. But again this is no currently common practice.
2362

350kmip-ug-v1.2-cnd01
351Non-Standards Track
352

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 71 of 84

[Type the document title]

23401.64.3 Registering Sub-Clients Based on a Trusted Primary Client

353

354

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

2363Deprecated

KMIP Functionality

2364This section describes KMIP functionality that has been deprecated.


2365Use of deprecated functionality is discouraged since such functionality may
2366be dropped in a future release of the [KMIP-Spec].

2368Items in the normative KMIP Specification [KMIP-Spec] document can be


2369marked deprecated in any document version, but will be removed only in a
2370major version. Similarly, conformance clauses or other normative information
2371in the KMIP Profiles [KMIP-Prof]KMIP_Prof document can be deprecated in any
2372document version, but removed only in a major version. Information in the
2373non-normative KMIP Use Cases [KMIP-UC], KMIP Usage Guide [this document]
2374and KMIP Test Cases [KMIP-TC] documents may be removed in any document
2375version.
23761.66 Certificate Attribute Related Fields
2377The KMIP v1.0 Certificate Identifier, Certificate Subject and Certificate Issuer
2378attributes are populated from values found within X.509 public key or PGP
2379certificates. In KMIP v1.0 these fields were encoded as Text String, but the
2380values of these fields are obtained from certificates which are ASN.1 (X.509)
2381or octet (PGP) encoded. In KMIP v1.1, the data type associated with these
2382fields was changed from Text String to Byte String so that the values of these
2383fields parsed from the certificates can be preserved and no conversion from
2384the encoded values into a text string is necessary.
2385Since these certificate-related attributes and associated fields were included
2386as part of the v1.0 KMIP specification and that there may be implementations
2387supporting these attributes using the Text String encoding, a decision was
2388made to deprecate these attributes in KMIP v1.1 and replace them with newly
2389named attributes and fields. As part of this change, separate certificate2390related attributes for X.509 certificates were introduced.
2391Table 4 provides a list of the deprecated certificate-related attributes and
2392fields along with their corresponding tag value.
Deprecated Attribute/Field

Deprecated Tag Value

Certificate Identifier

420014

Certificate Issuer

420015

355kmip-ug-v1.2-cnd01
356Non-Standards Track
357

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 72 of 84

[Type the document title]

23671.65 KMIP Deprecation Rule

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

358

359

Certificate Issuer Alternative


Name

420016

Certificate Issuer Distinguished 420017


Name

2393T ABLE

Certificate Subject

42001A

Certificate Subject Alternative


Name

42001B

Certificate Subject
Distinguished Name

42001C

Issuer

42003B

Serial Number
420087
4: D EPRECATED C ERTIFICATE R ELATED ATTRIBUTES

AND

FIELDS

2394Table 5 provides a mapping of v1.0 to v1.1 certificate attributes and fields.

Certificate Identifier

Certificate Issuer

Certificate Subject

2395T ABLE 5: MAPPING OF

Deprecated V1.0
Field
Issuer

New V1.1 Attribute


X.509 Certificate
Identifier

New V1.1 Field


Issuer Distinguished
Name

Serial Number

Certificate Serial
Number

Certificate Issuer
X.509 Certificate
Distinguished Name Issuer

Issuer Distinguished
Name

Certificate Issuer
Alternative Name

Issuer Alternative
Name

Certificate Subject
X.509 Certificate
Distinguished Name Subject

Subject
Distinguished Name

Certificate Subject
Subject Alternative
Alternative Name
Name
V 1.0 TO V 1.1 C ERTIFICATE R ELATED A TTRIBUTES AND F IELDS

23961.67 PGP Certificate and Certificate Request Types


2397KMIP 1.0 and 1.1 included support for PGP via a PGP Certificate Type and associated PGP
2398Certificate Request Type. However the certificate concept, which is typically associated with
2399X.509 public key certificates, is not well suited for describing PGP keys and associated
2400credentials as specified in [RFC4880]. For example, PGP may associate multiple asymmetric
2401key pairs and associated public key certificates to the same subject, while a X.509 certificate
2402associates a single public key to a subject. As a result of these differences it was difficult to apply
2403the X.509 public key certificate structure and attributes to PGP credentials in a meaningful way.
2404KMIP 1.2 introduces changes and additions to KMIP that allow PGP usage scenarios as specified
2405in [RFC4880] to be better supported within KMIP. (See Section 1.63 for more information.)
2406These changes include the deprecation of the PGP Certificate Type and PGP Certificate Request
2407Type concepts and the introduction of a new PGP Key managed cryptographic object.

2408Table 6 lists the PGP Certificate Type enumeration which has been deprecated
2409as of KMIP 1.2.

360kmip-ug-v1.2-cnd01
361Non-Standards Track
362

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 73 of 84

[Type the document title]

Deprecated V1.0
Attribute

363

364

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

Certificate Type
Name

Value

PGP

00000002(deprecated)

2410T ABLE 6: D EPRECATED PGP C ERTIFICATE TYPE

2411Table 7 lists the PGP Certificate Request Type enumeration which has been
2412deprecated as of KMIP 1.2
Certificate Request Type
Name

Value

PGP

00000004(deprecated)

2413T ABLE 7: D EPRECATED PGP-C ERTIFICATE R EQUEST TYPE

2414

[Type the document title]

2415

365kmip-ug-v1.2-cnd01
366Non-Standards Track
367

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 74 of 84

368

369

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

2416Implementation

Conformance

[Type the document title]

2417This document is intended to be informational only and as such has no


2418conformance clauses. The conformance requirements for the KMIP
2419Specification can be found in the "KMIP Specification" document itself, at the
2420URL noted in the Normative References section of this document.

370kmip-ug-v1.2-cnd01
371Non-Standards Track
372

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 75 of 84

373

374

2421

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

Appendix A. Acknowledgements

2422The following individuals have participated in the creation of this specification


2423and are gratefully acknowledged:

2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470

Hal Aldridge, Sypris Electronics


Mike Allen, Symantec
Gordon Arnold, IBM
Todd Arnold, IBM
Richard Austin, Hewlett-Packard
Lars Bagnert, PrimeKey
Elaine Barker, NIST
Peter Bartok, Venafi, Inc.
Tom Benjamin, IBM
Anthony Berglas, Cryptsoft
Mathias Bjrkqvist, IBM
Kevin Bocket, Venafi
Anne Bolgert, IBM
Alan Brown, Thales e-Security
Tim Bruce, CA Technologies
Chris Burchett, Credant Technologies, Inc.
Kelley Burgin, National Security Agency
Robert Burns, Thales e-Security
Chuck Castleton, Venafi
Kenli Chong, QuintessenceLabs
John Clark, Hewlett-Packard
Tom Clifford, Symantec Corp.
Tony Cox, Cryptsoft
Russell Dietz, SafeNet, Inc
Graydon Dodson, Lexmark International Inc.
Vinod Duggirala, EMC Corporation
Chris Dunn, SafeNet, Inc.
Michael Duren, Sypris Electronics
James Dzierzanowski, American Express CCoE
Faisal Faruqui, Thales e-Security
Stan Feather, Hewlett-Packard
David Finkelstein, Symantec Corp.
James Fitzgerald, SafeNet, Inc.
Indra Fitzgerald, Hewlett-Packard
Judith Furlong, EMC Corporation
Susan Gleeson, Oracle
Robert Griffin, EMC Corporation
Paul Grojean, Individual
Robert Haas, IBM
Thomas Hardjono, M.I.T.
ChengDong He, Huawei Technologies Co., Ltd.
Steve He, Vormetric
Kurt Heberlein, Hewlett-Packard
Larry Hofer, Emulex Corporation
Maryann Hondo, IBM

375kmip-ug-v1.2-cnd01
376Non-Standards Track
377

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 76 of 84

[Type the document title]

2424Participants in KMIP Usage Guide V1.2


2425

2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

Walt Hubis, NetApp


Tim Hudson, Cryptsoft
Jonas Iggbom, Venafi, Inc.
Sitaram Inguva, American Express CCoE
Jay Jacobs, Target Corporation
Glen Jaquette, IBM
Mahadev Karadiguddi, NetApp
Greg Kazmierczak, Wave Systems Corp.
Marc Kenig, SafeNet, Inc.
Mark Knight, Thales e-Security
Kathy Kriese, Symantec Corporation
Mark Lambiase, SecureAuth
John Leiseboer, Quintenssence Labs
Hal Lockhart, Oracle Corporation
Robert Lockhart, Thales e-Security
Anne Luk, Cryptsoft
Sairam Manidi, Freescale
Luther Martin, Voltage Security
Neil McEvoy, iFOSSF
Marina Milshtein, Individual
Dale Moberg, Axway Software
Jishnu Mukeri, Hewlett-Packard
Bryan Olson, Hewlett-Packard
John Peck, IBM
Rob Philpott, EMC Corporation
Denis Pochuev, SafeNet, Inc.
Reid Poole, Venafi, Inc.
Ajai Puri, SafeNet, Inc.
Saravanan Ramalingam, Thales e-Security
Peter Reed, SafeNet, Inc.
Bruce Rich, IBM
Christina Richards, American Express CCoE
Warren Robbins, Dell
Peter Robinson, EMC Corporation
Scott Rotondo, Oracle
Saikat Saha, Oracle
Anil Saldhana, Red Hat
Subhash Sankuratripati, NetApp
Boris Schumperli, Cryptomathic
Greg Singh, QuintessenceLabs
David Smith, Venafi, Inc.
Brian Spector, Certivox
Terence Spies, Voltage Security
Deborah Steckroth, RouteOne LLC
Michael Stevens, QuintessenceLabs
Marcus Streets, Thales e-Security
Satish Sundar, IBM
Kiran Thota, VMware
Somanchi Trinath, Freescale Semiconductor, Inc.
Nathan Turajski, Thales e-Security
Sean Turner, IECA, Inc.
Paul Turner, Venafi, Inc.
Rod Wideman, Quantum Corporation
Steven Wierenga, Hewlett-Packard
Jin Wong, QuintessenceLabs
Sameer Yami, Thales e-Security

380kmip-ug-v1.2-cnd01
381Non-Standards Track
382

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 77 of 84

[Type the document title]

378

379

383

384

Peter Yee, EMC Corporation


Krishna Yellepeddy, IBM
Catherine Ying, SafeNet, Inc.
Tatu Ylonen, SSH Communications Security (Tectia Corp)
Michael Yoder, Vormetric. Inc.
Magda Zdunkiewicz, Cryptsoft
Peter Zelechoski, Election Systems & Software

[Type the document title]

2527
2528
2529
2530
2531
2532
2533

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

385kmip-ug-v1.2-cnd01
386Non-Standards Track
387

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 78 of 84

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

388

389

2534Appendix

B.

Acronyms

25363DES

- Triple Data Encryption Standard

2537ADK

- Additional Decryption Key

2538AES

- Advanced Encryption Standard specified in [FIPS197]

2539ANSI

- American National Standards Institute

2540ARQC

- Authorization Request Cryptogram

2541ASCII

- American Standard Code for Information Interchange

2542ASI

- Application Specific Information

2543ASN.1

- Abstract Syntax Notation One

2544CA

- Certification Authority

2545CBC

- Cipher Block Chaining specified in [SP800-38A]

2546CMC
- Certificate Management Messages over CMS specified in
2547[RFC5272]
2548CMP
2549CRL

- Certificate Management Protocol specified in [RFC4210]


- Certificate Revocation List specified in [X.509]

2550CRMF

- Certificate Request Message Format specified in [RFC4211]

2551CVC

- Card Verification Code

2552DEK

- Data Encryption Key

2553DH

- Diffie-Hellman specified in [X9.42]

2554DSA

- Digital Signature Algorithm specified in [FIPS186-4]

2555DSS

- Digital Signature Standard

2556ECC

- Elliptic Curve Cryptography

2557ECDH

- Elliptic Curve Diffie Hellman

2558ECDSA

- Elliptic Curve Digital Signature Algorithm

2559FIPS

- Federal Information Processing Standard

2560GCM

- Galois/Counter Mode specified in [SP800-38D]

2561HMAC

- Keyed-Hash Message Authentication Code specified in [FIPS198-1]

2562HSM

- Hardware Security Module

2563HTTP

- Hyper Text Transfer Protocol

2564HTTPS

- Hyper Text Transfer Protocol (Secure socket)

2565ID

- Identification

390kmip-ug-v1.2-cnd01
391Non-Standards Track
392

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 79 of 84

[Type the document title]

2535The following abbreviations and acronyms are used in this document:

2566IP

- Internet Protocol

2567IPSec

- Internet Protocol Security

2568ITU

- International Telecommunication Union

2569KAD

- Key Associated Data

2570KEK

- Key Encryption Key

2571KMIP

- Key Management Interoperability Protocol

2572LTO4

- Linear Tape-Open, Generation 4

2573LTO5

- Linear Tape-Open, Generation 5

2574LTO6

- Linear Tape-Open, Generation 6

2575MAC

- Message Authentication Code

2576MD5

- Message Digest 5 Algorithm specified in [RFC1321]

2577MDO

- Meta-Data Only

2578MGF

- Mask Generation Function

2579NIST

- National Institute of Standards and Technology

2580OAEP - Optimal Asymmetric Encryption Padding specified in [PKCS#1]

2581OID

- Object Identifier

2582PEM

- Privacy Enhanced Mail specified in [RFC1421]

2583PGP

- OpenPGP specified in [RFC4880]

2584PKCS

- Public-Key Cryptography Standards

2585POP

- Proof of Possession

2586POSIX

- Portable Operating System Interface

2587PSS

- Probabilistic Signature Scheme specified in [PKCS#1]

2588RNG

- Random Number Generator

2589RSA

- Rivest, Shamir, Adelman (an algorithm)

2590SEMS

- Symantec Encryption Management Server

2591SHA

- Secure Hash Algorithm specified in [FIPS 180-4]

2592SP

- Special Publication

2593SMIME

- Secure Multipurpose Internet Mail Extensions

2594TCP

- Transport Control Protocol

2595TDEA

- Triple Data Encryption Algorithm

2596TLS

- Transport Layer Security

2597TTLV

- Tag, Type, Length, Value

2598URI

- Uniform Resource Identifier

395kmip-ug-v1.2-cnd01
396Non-Standards Track
397

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 80 of 84

[Type the document title]

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

393

394

398

399

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

2599Appendix

C.

Table of Figures and Tables

2600Table of Figures
2601Figure 1: Aggregator Client Example............................................................................................17
2602Table 1: ID Placeholder Prior to and Resulting from a KMIP Operation........................................27
2603Table 2: Cryptographic Usage Masks Pairs..................................................................................35
2604Table 3: ECC Algorithm Mapping.................................................................................................. 48
2605Figure 2: KAD Content for LTO4................................................................................................... 59
2606Figure 3: KAD Content for LTO5................................................................................................... 60
2607Table 4: Deprecated Certificate Related Attributes and Fields......................................................67
2608Table 5: Mapping of v1.0 to v1.1 Certificate Related Attributes and Fields...................................67
2609Table 6: Deprecated PGP Certificate Type....................................................................................67

2611Table of Tables
2612Figure 1: Aggregator Client Example............................................................................................17
2613Table 1: ID Placeholder Prior to and Resulting from a KMIP Operation........................................27
2614Table 2: Cryptographic Usage Masks Pairs..................................................................................35
2615Table 3: ECC Algorithm Mapping.................................................................................................. 48
2616Figure 2: KAD Content for LTO4................................................................................................... 59
2617Figure 3: KAD Content for LTO5................................................................................................... 60
2618Table 4: Deprecated Certificate Related Attributes and Fields......................................................67
2619Table 5: Mapping of v1.0 to v1.1 Certificate Related Attributes and Fields...................................67
2620Table 6: Deprecated PGP Certificate Type....................................................................................67
2621Table 7: Deprecated PGP-Certificate Request Type.....................................................................68

2622
2623Figure 1: Aggregator Client Example............................................................................................17
2624Table 1: ID Placeholder Prior to and Resulting from a KMIP Operation........................................27
2625Table 2: Cryptographic Usage Masks Pairs..................................................................................35
2626Table 3: ECC Algorithm Mapping.................................................................................................. 48
2627Figure 2: KAD Content for LTO4................................................................................................... 59
2628Figure 3: KAD Content for LTO5................................................................................................... 60
2629Table 4: Deprecated Certificate Related Attributes and Fields......................................................67
2630Table 5: Mapping of v1.0 to v1.1 Certificate Related Attributes and Fields...................................67
2631Table 6: Deprecated PGP Certificate Type....................................................................................67
2632Table 7: Deprecated PGP-Certificate Request Type.....................................................................68

2633

400kmip-ug-v1.2-cnd01
401Non-Standards Track
402

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 81 of 84

[Type the document title]

2610Table 7: Deprecated PGP-Certificate Request Type.....................................................................68

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

2634Appendix

D.

Revision

Date

Revision History
Editor

Changes Made

V1.2wd01-01

3/18/13

Indra Fitzgerald

Conversion of UG into current


OASIS template

V1.2wd01-02

5/9/13

Judy Furlong

Restructuring of UG

Split section 3 into two section


(Using vs. Applying KMIP
functionality)

Section 3.18 Locate Queries


now 4.1
Section 3.21 Using Wrapped
Keys now 4.2
Section 3.30 Interoperable Key
Naming for Tape now section
4.3
Section 3.37 Vendor
Extensions the intro remains
in Section 3 (now section 3.34)
and the subsections (3.37.1
and 3.37.2) moved to Section 4
(4.4 and 4.5 respectively

Added a deprecation section


Removed the deferred item
section (going to Use Case
document).
Other editorial changes.
V1.2wd01-03

5/16/13

Judy Furlong

Incorporation of the following


balloted proposals:
Metadata-only Object
Deprecation Rule
PGP and Alternative Name
Attested Operations
Split Key
Incorporation of other UG related
content:

V1.2-wd02

5/30/13

405kmip-ug-v1.2-cnd01
406Non-Standards Track
407

Judy Furlong

Compromised State of
Linked Objects
Client Registration
PGP Cert and Cert Type
Deprecation
Incorporation of the UG text for

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 82 of 84

[Type the document title]

403

404

408

409

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

the following balloted proposals:

Templates

Cryptographic Services

Other UG related content changes:

V1.2-wd03

6/27/13

Judy Furlong

Application Specification
Information
Removed Compromised
State of Linked Objects
section until wording can be
agreed upon
Incorporated 1.1 Errata for
the Usage Guide
Other UG related content changes:

V1.2-wd04

V1.2-wd05

7/11/13

8/19/13

410kmip-ug-v1.2-cnd01
411Non-Standards Track
412

Judy Furlong

Judy Furlong

Updated section 4.3 Tape


Key Name Space to bring inline with profile
Readded Compromised
Objects section
Updated participant list
Other editorial changes
Incorporated review comments
from TC members

Added ECC Algorithm Mapping


information to close out
incorporation of all KMIP 1.2
balloted proposals.

Removed Acronym list in


appendix (a single list will be
included in the KMIP
Specification)

Other editorial and format


changes.

Incorporated review comments


from TC members

Added new version of ECC


Algorithm Mapping table.

Edits to 3.5 to align with latest


KMIP Spec wording.

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 83 of 84

[Type the document title]

413

414

V1.2-wd06

V1.2cnd01

This is a Non-Standards Track Work Product.


The patent provisions of the OASIS IPR Policy do not apply .

8/22/13

9/13/13

Judy Furlong

Judy Furlong

Other editorial changes

Updated References

Re-added Acronym List

Other editorial and format


changes

Converted to Committee Note


Draft
Incorporated applicable updated
references
Incorporated updated Participants
List
Fixed Cross-references

[Rev
Date]

[Modified By]

[Summary of Changes]
[Type the document title]

[Rev
number]

2635
2636

415kmip-ug-v1.2-cnd01
416Non-Standards Track
417

31 October 2013
Copyright OASIS Open 2013. All Rights Reserved.
Page 84 of 84