1 Introduction

For normative definition of the elements of KMIP see the KMIP Specification [KMIP-SPEC] and the KMIP Profiles [KMIP-PROF].

Illustrative guidance for the implementation of KMIP clients and servers is provided in the KMIP Usage Guide [KMIP-UG].

This profile defines the necessary KMIP functionality that a Tape Library operating as a KMIP client SHALL use and a KMIP server conforming to this profile SHALL support in order to interoperate in conformance with this profile.

1.1 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

Key Associated Data (KAD)	Part of the tape format. May be segmented into authenticated and unauthenticated fields. KAD usage is detailed in the SCSI SSC-3 standard from the T10 organization available as ANSI INCITS 335-2000.
Hexadecimal Numeric Characters	Case-sensitive, printable, single byte ASCII characters representing the numbers 0 through 9 and uppercase alpha A through F. (US-ASCII characters 30h-39h and 41h-46h). Each byte (single 8-bit numeric value) is represented as two hexadecimal numeric characters with the high-nibble represented by the first (left-most) hexadecimal numeric character and the low-nibble represented by the second (right-most) hexadecimal numeric character.
N(a)	The maximum number of bytes in the tape authenticated KAD field. For LTO4, N(a) is 12 bytes. For LTO5, N(a) is 60 bytes. For LTO6, N(a) is 60 bytes.
N(u)	The maximum number of bytes in the tape unauthenticated KAD field. For LTO4, N(u) is 32 bytes. For LTO5, N(u) is 32 bytes. For LTO6, N(u) is 32 bytes.
N(k)	The maximum number of bytes in the tape format KAD fields – i.e. N(a) + N(u). For LTO4, N(k) is 44 bytes. For LTO5, N(k) is 92 bytes. For LTO6, N(k) is 92 bytes.

1.2 Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt.

[RFC2246] T. Dierks and C. Allen, The TLS Protocol, Version 1.0, IETF RFC 2246, Jan 1999, http://www.ietf.org/rfc/rfc2246.txt

[KMIP-SPEC] One or more of [KMIP-SPEC-1_0], [KMIP-SPEC-1_1], [KMIP-SPEC-1_2]

[KMIP-SPEC-1_0] Key Management Interoperability Protocol Specification Version 1.0
http://docs.oasis-open.org/kmip/spec/v1.0/os/kmip-spec-1.0-os.doc
OASIS Standard, October 2010.

[KMIP-SPEC-1_1] Key Management Interoperability Protocol Specification Version 1.1.
http://docs.oasis-open.org/kmip/spec/v1.1/os/kmip-spec-v1.1-os.doc
OASIS Standard. 24 January 2013.

[KMIP-SPEC-1_2] Key Management Interoperability Protocol Specification Version 1.2.
URL
Candidate OASIS Standard 01. DD MMM YYYY.

[KMIP-PROF] One or more of [KMIP-PROF-1_0], [KMIP-PROF-1_1], [KMIP-PROF-1_2]

[KMIP-PROF-1_0] Key Management Interoperability Protocol Usage Guide Version 1.0. http://docs.oasis-open.org/kmip/profiles/v1.0/os/kmip-profiles-1.0-os.doc
OASIS Standard. 1 October 2010.

[KMIP-PROF-1_1] Key Management Interoperability Protocol Usage Guide Version 1.1.
http://docs.oasis-open.org/kmip/profiles/v1.1/os/kmip-profiles-v1.1-os.doc
OASIS Standard 01. 24 January 2013.

[KMIP-PROF-1_2] Key Management Interoperability Protocol Usage Guide Version 1.2.
URL
Candidate OASIS Standard 01. DD MMM YYYY.

1.3 Non-Normative References

[KMIP-UG] One or more of [KMIP-UG-1_0], [KMIP-UG-1_1], [KMIP-UG-1_2]

[KMIP-UG-1_0] Key Management Interoperability Protocol Usage Guide Version 1.0. http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc
Committee Note Draft, 1 December 2011

[KMIP-UG-1_1] Key Management Interoperability Protocol Usage Guide Version 1.1. http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.doc
Committee Note 01, 27 July 2012

[KMIP-UG-1_2] Key Management Interoperability Protocol Usage Guide Version 1.2.
URL
Committee Note Draft, DD MMM YYYY

[KMIP-TC-1_1] Key Management Interoperability Protocol Test Cases Version 1.1. http://docs.oasis-open.org/kmip/testcases/v1.1/cn01/kmip-testcases-v1.1-cn01.doc, Committee Note 01, 27 July 2012.

[KMIP-TC-1_2] Key Management Interoperability Protocol Test Cases Version 1.2.
URL, Committee Note Draft, DD MMM YYYY.

[KMIP-UC] Key Management Interoperability Protocol Use Cases Version 1.0. http://docs.oasis-open.org/kmip/usecases/v1.0/cs01/kmip-usecases-1.0-cs-01.doc, Committee Specification, 15 June 2010.

2 Tape Library Profile

The Tape Library Profile specifies the behavior of a tape library operating as a KMIP client interacting with a KMIP server.

2.1 Authentication Suite

Implementations conformant to this profile SHALL support at least one of the Authentication Suites defined within [KMIP-PROF]. The establishment of the trust relationship between the KMIP client and the KMIP server is the same as the defined base profiles for the version of the profile supported.

2.2 Baseline Tape Library

KMIP clients conformant to this profile under [KMIP-SPEC]:

SHALL conform to the KMIP Baseline Client profile in [KMIP-PROF] and [KMIP-SPEC]
SHOULD support Application Specific Information [KMIP-SPEC] with Application Data provided by the client in accordance with section 2.3
SHOULD NOT use a Custom Attribute [KMIP-SPEC] that duplicates information that is already in standard Attributes [KMIP-SPEC]
MAY use x-Barcode as a Custom Attribute [KMIP-SPEC] of type Text String to store the barcode
MAY support any clause within [KMIP-SPEC] provided it does not conflict with any other clause within this section 2.2
MAY support extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not conflict with any KMIP requirements

KMIP clients conformant to this profile under [KMIP-SPEC-1_2]:

SHALL support the following Attributes [KMIP-SPEC]

Alternative Name [KMIP-SPEC-1_2]

SHALL support the following Message Encoding [KMIP-SPEC-1_2]]:

Alternative Name Type Enumeration [KMIP-SPEC-1_2] value:

i. Uninterpreted Text String

SHALL store the media barcode information in an Alternative Name [KMIP-SPEC-1_2] Attribute [KMIP-SPEC-1_2] in accordance with section 2.4

KMIP servers conformant to this profile under [KMIP-SPEC]:

SHALL conform to the KMIP Baseline Server profile in [KMIP-PROF] and [KMIP-SPEC]
SHALL support the following Objects [KMIP-SPEC]

Symmetric Key [KMIP-SPEC]

SHALL support the following Attributes [KMIP-SPEC]

Name [KMIP-SPEC]
Cryptographic Algorithm [KMIP-SPEC]
Custom Attribute [KMIP SPEC]
Application Specific Information [KMIP SPEC]

SHALL support the following Client-to-Server Operations [KMIP-SPEC]:

Create [KMIP-SPEC]

SHALL support the following Message Contents [KMIP-SPEC]:

Batch Order Option [KMIP-SPEC] value:

i. True

Batch Count [KMIP-SPEC] value:

i. 1 to 32

SHALL support the following Message Encoding [KMIP-SPEC]:

Cryptographic Algorithm Enumeration [KMIP-SPEC] value:

i. AES

Object Type Enumeration [KMIP-SPEC] value:

i. Symmetric Key

Key Format Type Enumeration [KMIP-SPEC] value:

i. Raw

Cryptographic Length [KMIP-SPEC] value :

i. 256-bit

Name Type Enumeration [KMIP-SPEC] value:

i. Uninterpreted Text String

SHALL support Custom Attribute [KMIP-SPEC] with the following data types and properties:

Text String
Integer
Date Time

SHALL support a minimum length of 256 characters for Custom Attribute [KMIP-SPEC] and Name [KMIP-SPEC] values where the attribute type is of variable length
SHALL support a minimum of 30 Custom Attribute [KMIP-SPEC] per managed object
SHALL support a minimum of 64 characters in Custom Attribute [KMIP-SPEC] names
SHALL support the Tape Library Profile Test Cases, returning results in accordance with the test cases
MAY support any clause within [KMIP-SPEC] provided it does not conflict with any other clause within this section 2.2
MAY support extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not conflict with any KMIP requirements

KMIP servers conformant to this profile under [KMIP-SPEC-1_2]:

SHALL support the following Attributes [KMIP-SPEC]

Alternative Name [KMIP-SPEC-1_2]

SHALL support the following Message Encoding [KMIP-SPEC-1_2]]:

Alternative Name Type Enumeration [KMIP-SPEC-1_2] value:

i. Uninterpreted Text String

2.3 Using Application Specific Information for Key Identifiers

This information applies to Tape Libraries that use the Application Specific Information [KMIP-SPEC] attribute to store key identifiers. KMIP clients are NOT required to use Application Specific Information [KMIP-SPEC] however KMIP servers are required to support KMIP clients that use Application Specific Information [KMIP-SPEC] and KMIP clients that do not use Application Specific Information [KMIP-SPEC].

The Application Specific Information [KMIP-SPEC] MAY be used to store data that is specific to the application (Tape Library) using the object.

The following Application Namespaces SHOULD be used in the Application Namespace field of the Application Specific Information [KMIP-SPEC]:

· LIBRARY-LTO, LIBRARY-LTO4, LIBRARY-LTO5, and LIBRARY-LTO6

For backwards compatibility with deployed Tape Library implementations, servers MAY support VENDOR-LIBRARY-LTO as an Application Namespace, where VENDOR is an ASCII string that SHALL NOT be further interpreted and SHALL be handled by the server as if the Application Namespace was set to LIBRARY-LTO.

Application Specific Information [KMIP-SPEC] supports key identifiers being created either on the server or on the client (Tape Library), but not both. This profile specifies key identifiers created by the client.

The Application Specific Information [KMIP-SPEC] method of key identification relies on the ability to uniquely identify a key based only on its Application Data (preferably), or (alternatively) on some combination of Application Data and Custom Attributes [KMIP-SPEC], which the key creator guarantees to be unique within the Application Namespace.

Key identifiers stored in the KMIP server's Application Specific Information [KMIP-SPEC] are in ASCII format. Key identifiers stored in the KMIP client's tape format KAD fields are numeric format. The specific algorithm for converting between text and numeric formats is specified below.

All information contained in the tape format’s KAD fields is converted to an ASCII string consisting of hexadecimal numeric character pairs as follows:

The unauthenticated KAD is converted to text;
The authenticated KAD is converted to text and;
The converted authenticated KAD text is concatenated to the end of the converted unauthenticated KAD text.

If the implementation uses client-created key identifiers, then the client generates a new identifier in ASCII format that SHALL be unique within the chosen namespace. The source material for generating the string is dependent on client policy. The numeric representation of this identifier SHALL be no larger than the N(k) bytes of the KAD for the tape media being used.

For KMIP clients and servers conforming to this profile, Application Specific Information [KMIP-SPEC] SHALL be created by the Tape Library KMIP client based on the tape format's KAD fields as follows:

1. Define an empty output buffer sufficient to contain a string with a maximum length of 2*N(k) bytes.

2. Copy the tape format’s unauthenticated KAD (if present) to the output buffer, converting each byte value to exactly two Hexadecimal Numeric Characters. The first byte (i.e., byte 0) of the output buffer is the first byte of unauthenticated KAD.

3. Concatenate the tape format’s authenticated KAD to the output buffer, converting each byte value to exactly two Hexadecimal Numeric Characters.

Note: the contents of the unauthenticated KAD and authenticated KAD fields may be less than the maximum permitted lengths; the implementation provides the correct length values to use in the algorithm rather than using fixed maximum length fields.

If Application Specific Information [KMIP-SPEC] is supported, then it SHALL be used by the client for locating the object for the purpose of encrypting and decrypting data on tape. The Application Specific Information [KMIP-SPEC] value SHALL solely be used for this purpose.

Refer to [KMIP-UG] for further non-normative details of conversion to and from KAD values.

2.4 Using Alternative Name for tape media barcode

The Tape Library client SHALL assign a text (i.e., human-readable) representation of the media barcode to the Alternative Name [KMIP-SPEC-1_2] of the object. This SHALL occur on first use of the object for encryption, which normally is when the library requests the server to create the object.

The relationship between key identifiers in Application Specific Information [KMIP-SPEC] and Alternative Name [KMIP-SPEC-1_2] is as follows:

a) The values for both are provided by the client

b) The identifier in Alternative Name [KMIP-SPEC-1_2] (i.e., the barcode) SHALL be used by the server administrator for finding keys associated with specific tape media (e.g., a server administrator may want to find the key(s) associated with a missing tape cartridge, where the barcode of that tape cartridge is known).

c) The Alternative Name [KMIP-SPEC-1_2] SHALL NOT be used by a client for locating the object to encrypt or decrypt data, since the value (barcode) is NOT required to be unique and therefore does not ensure retrieval of the correct key.

Refer to [KMIP-UG-1_2] for further non-normative details of Alternative Name [KMIP-SPEC-1_2] usage.

3 Tape Library Profile Test Cases

This section documents the test cases that a client or server conformant to the Tape Library Profile SHALL support.

Note: the values for the returned items and the Custom Attributes are illustrative. Actual values from a real client system will vary. These test cases demonstrate usage of all of the mandatory types that are required to be supported in a server implementation.

3.1 Mandatory Test Cases

This section documents the test cases that a client or server conformant to the Tape Library Profile SHALL support for each version of the KMIP protocol (major and minor).

3.1.1 TL-M-1-10 - Configuration

Determine server configuration details including operations supported (only the mandatory operations are listed in the response example), objects supported (only the mandatory objects types are listed in the response example), optional server information, and optional list of application name spaces.

0001

0002

0003

0004

0005

0006

0007

0008

0009

0010

0011

0012

0013

0014

0015

0016

0017

0018

0019

# TIME 0

</ProtocolVersion>

</RequestHeader>

</RequestPayload>

</BatchItem>

</RequestMessage>

0020

0021

0022

0023

0024

0025

0026

0027

0028

0029

0030

0031

0032

0033

0034

0035

0036

0037

0038

0039

0040

0041

0042

0043

0044

0045

0046

0047

0048

0049

0050

0051

0052

0053

0054

0055

</ProtocolVersion>

</ResponseHeader>

</ServerInformation>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

3.1.2 TL-M-2-10 - Write with new (created) key

This case may occur when the Write operation starts with the first block on a tape. The implementation may choose which Write operations qualify for creation of a new key. Regardless of the initiating circumstances, the Tape Library requests the server to create a new AES-256 symmetric key with appropriate identifying information which is unique within the Application Namespace.

Additional custom attributes MAY be specified in order to:

- ensure uniqueness of the key identifier when later Locating the key via ASI

- provide human-readable information (such as the tape Barcode value)

- provide information to support client-specific purposes

0001

0002

0003

0004

0005

0006

0007

0008

0009

0010

0011

0012

0013

0014

0015

0016

0017

0018

0019

0020

0021

0022

0023

0024

0025

0026

0027

0028

0029

0030

0031

0032

0033

0034

0035

0036

0037

0038

0039

0040

0041

0042

0043

0044

0045

0046

0047

0048

0049

0050

0051

0052

0053

0054

0055

0056

0057

0058

0059

0060

0061

0062

0063

0064

0065

0066

0067

0068

0069

0070

0071

# TIME 0

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</TemplateAttribute>

</RequestPayload>

</BatchItem>

</RequestPayload>

</BatchItem>

</RequestMessage>

0072

0073

0074

0075

0076

0077

0078

0079

0080

0081

0082

0083

0084

0085

0086

0087

0088

0089

0090

0091

0092

0093

0094

0095

0096

0097

0098

0099

0100

0101

0102

0103

0104

0105

0106

0107

0108

0109

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</KeyValue>

</KeyBlock>

</SymmetricKey>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

3.1.3 TL-M-3-10 - Read an encrypted tape

The Tape Library constructs an identifier string based on the method in 2.3, then requests the server to Locate that string via ASI. A Get is then requested based on the key's unique identifier. The Tape Library MAY update attributes associated with the Symmetric Key Managed Object. The following test case shows extensive use of custom attributes. Custom attributes are not required if the Application Name is unique within the Application Namespace. An implementation may also use custom attributes for vendor-unique purposes, or to improve usability.

The test case destroys the key created in the previous test case to clean up after the test. Tape Library implementations MAY not perform this step.

0001

0002

0003

0004

0005

0006

0007

0008

0009

0010

0011

0012

0013

0014

0015

0016

0017

0018

0019

0020

0021

0022

0023

0024

0025

0026

0027

0028

0029

0030

0031

0032

0033

# TIME 0

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</RequestPayload>

</BatchItem>

</RequestPayload>

</BatchItem>

</RequestMessage>

0034

0035

0036

0037

0038

0039

0040

0041

0042

0043

0044

0045

0046

0047

0048

0049

0050

0051

0052

0053

0054

0055

0056

0057

0058

0059

0060

0061

0062

0063

0064

0065

0066

0067

0068

0069

0070

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</KeyValue>

</KeyBlock>

</SymmetricKey>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

0071

0072

0073

0074

0075

0076

0077

0078

0079

0080

0081

0082

0083

0084

0085

0086

0087

0088

0089

0090

0091

0092

0093

0094

0095

0096

0097

0098

0099

0100

0101

0102

0103

# TIME 1

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</RequestPayload>

</BatchItem>

</RequestPayload>

</BatchItem>

</RequestMessage>

0104

0105

0106

0107

0108

0109

0110

0111

0112

0113

0114

0115

0116

0117

0118

0119

0120

0121

0122

0123

0124

0125

0126

0127

0128

0129

0130

0131

0132

0133

0134

0135

0136

0137

0138

0139

0140

0141

0142

0143

0144

0145

0146

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

0147

0148

0149

0150

0151

0152

0153

0154

0155

0156

0157

0158

0159

0160

0161

0162

0163

0164

0165

0166

0167

0168

0169

0170

0171

0172

0173

0174

0175

0176

0177

0178

0179

# TIME 2

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</RequestPayload>

</BatchItem>

</RequestPayload>

</BatchItem>

</RequestMessage>

0180

0181

0182

0183

0184

0185

0186

0187

0188

0189

0190

0191

0192

0193

0194

0195

0196

0197

0198

0199

0200

0201

0202

0203

0204

0205

0206

0207

0208

0209

0210

0211

0212

0213

0214

0215

0216

0217

0218

0219

0220

0221

0222

0223

0224

0225

0226

0227

0228

0229

0230

0231

0232

0233

0234

0235

0236

0237

0238

0239

0240

0241

0242

0243

0244

0245

0246

0247

0248

0249

0250

0251

0252

0253

0254

0255

0256

0257

0258

0259

0260

0261

0262

0263

0264

0265

0266

0267

0268

0269

0270

0271

0272

0273

0274

0275

0276

0277

0278

0279

0280

0281

0282

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

0283

0284

0285

0286

0287

0288

0289

0290

0291

0292

0293

0294

0295

0296

0297

0298

0299

0300

0301

0302

0303

0304

0305

0306

0307

0308

0309

0310

0311

0312

0313

0314

0315

0316

0317

0318

0319

0320

0321

0322

0323

0324

0325

0326

0327

0328

0329

# TIME 3

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</RequestPayload>

</BatchItem>

</Attribute>

</RequestPayload>

</BatchItem>

</Attribute>

</RequestPayload>

</BatchItem>

</RequestMessage>

0330

0331

0332

0333

0334

0335

0336

0337

0338

0339

0340

0341

0342

0343

0344

0345

0346

0347

0348

0349

0350

0351

0352

0353

0354

0355

0356

0357

0358

0359

0360

0361

0362

0363

0364

0365

0366

0367

0368

0369

0370

0371

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</Attribute>

</ResponsePayload>

</BatchItem>

</Attribute>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

0372

0373

0374

0375

0376

0377

0378

0379

0380

0381

0382

0383

0384

0385

0386

# TIME 4

</ProtocolVersion>

</RequestHeader>

</RequestPayload>

</BatchItem>

</RequestMessage>

0387

0388

0389

0390

0391

0392

0393

0394

0395

0396

0397

0398

0399

0400

0401

0402

0403

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

3.1.4 TL-M-1-11 - Configuration

0001

0002

0003

0004

0005

0006

0007

0008

0009

0010

0011

0012

0013

0014

0015

0016

0017

0018

0019

# TIME 0

</ProtocolVersion>

</RequestHeader>

</RequestPayload>

</BatchItem>

</RequestMessage>

0020

0021

0022

0023

0024

0025

0026

0027

0028

0029

0030

0031

0032

0033

0034

0035

0036

0037

0038

0039

0040

0041

0042

0043

0044

0045

0046

0047

0048

0049

0050

0051

0052

0053

0054

0055

</ProtocolVersion>

</ResponseHeader>

</ServerInformation>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

3.1.5 TL-M-2-11 - Write with new (created) key

Additional custom attributes MAY be specified in order to:

- ensure uniqueness of the key identifier when later Locating the key via ASI

- provide human-readable information (such as the tape Barcode value)

- provide information to support client-specific purposes

0001

0002

0003

0004

0005

0006

0007

0008

0009

0010

0011

0012

0013

0014

0015

0016

0017

0018

0019

0020

0021

0022

0023

0024

0025

0026

0027

0028

0029

0030

0031

0032

0033

0034

0035

0036

0037

0038

0039

0040

0041

0042

0043

0044

0045

0046

0047

0048

0049

0050

0051

0052

0053

0054

0055

0056

0057

0058

0059

0060

0061

0062

0063

0064

0065

0066

0067

0068

0069

0070

0071

# TIME 0

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</TemplateAttribute>

</RequestPayload>

</BatchItem>

</RequestPayload>

</BatchItem>

</RequestMessage>

0072

0073

0074

0075

0076

0077

0078

0079

0080

0081

0082

0083

0084

0085

0086

0087

0088

0089

0090

0091

0092

0093

0094

0095

0096

0097

0098

0099

0100

0101

0102

0103

0104

0105

0106

0107

0108

0109

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</KeyValue>

</KeyBlock>

</SymmetricKey>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

3.1.6 TL-M-3-11 - Read an encrypted tape

The test case destroys the key created in the previous test case to clean up after the test. Tape Library implementations MAY not perform this step.

0001

0002

0003

0004

0005

0006

0007

0008

0009

0010

0011

0012

0013

0014

0015

0016

0017

0018

0019

0020

0021

0022

0023

0024

0025

0026

0027

0028

0029

0030

0031

0032

0033

# TIME 0

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</RequestPayload>

</BatchItem>

</RequestPayload>

</BatchItem>

</RequestMessage>

0034

0035

0036

0037

0038

0039

0040

0041

0042

0043

0044

0045

0046

0047

0048

0049

0050

0051

0052

0053

0054

0055

0056

0057

0058

0059

0060

0061

0062

0063

0064

0065

0066

0067

0068

0069

0070

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</KeyValue>

</KeyBlock>

</SymmetricKey>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

0071

0072

0073

0074

0075

0076

0077

0078

0079

0080

0081

0082

0083

0084

0085

0086

0087

0088

0089

0090

0091

0092

0093

0094

0095

0096

0097

0098

0099

0100

0101

0102

0103

# TIME 1

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</RequestPayload>

</BatchItem>

</RequestPayload>

</BatchItem>

</RequestMessage>

0104

0105

0106

0107

0108

0109

0110

0111

0112

0113

0114

0115

0116

0117

0118

0119

0120

0121

0122

0123

0124

0125

0126

0127

0128

0129

0130

0131

0132

0133

0134

0135

0136

0137

0138

0139

0140

0141

0142

0143

0144

0145

0146

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

0147

0148

0149

0150

0151

0152

0153

0154

0155

0156

0157

0158

0159

0160

0161

0162

0163

0164

0165

0166

0167

0168

0169

0170

0171

0172

0173

0174

0175

0176

0177

0178

0179

# TIME 2

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</RequestPayload>

</BatchItem>

</RequestPayload>

</BatchItem>

</RequestMessage>

0180

0181

0182

0183

0184

0185

0186

0187

0188

0189

0190

0191

0192

0193

0194

0195

0196

0197

0198

0199

0200

0201

0202

0203

0204

0205

0206

0207

0208

0209

0210

0211

0212

0213

0214

0215

0216

0217

0218

0219

0220

0221

0222

0223

0224

0225

0226

0227

0228

0229

0230

0231

0232

0233

0234

0235

0236

0237

0238

0239

0240

0241

0242

0243

0244

0245

0246

0247

0248

0249

0250

0251

0252

0253

0254

0255

0256

0257

0258

0259

0260

0261

0262

0263

0264

0265

0266

0267

0268

0269

0270

0271

0272

0273

0274

0275

0276

0277

0278

0279

0280

0281

0282

0283

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

0284

0285

0286

0287

0288

0289

0290

0291

0292

0293

0294

0295

0296

0297

0298

0299

0300

0301

0302

0303

0304

0305

0306

0307

0308

0309

0310

0311

0312

0313

0314

0315

0316

0317

0318

0319

0320

0321

0322

0323

0324

0325

0326

0327

0328

0329

0330

# TIME 3

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</RequestPayload>

</BatchItem>

</Attribute>

</RequestPayload>

</BatchItem>

</Attribute>

</RequestPayload>

</BatchItem>

</RequestMessage>

0331

0332

0333

0334

0335

0336

0337

0338

0339

0340

0341

0342

0343

0344

0345

0346

0347

0348

0349

0350

0351

0352

0353

0354

0355

0356

0357

0358

0359

0360

0361

0362

0363

0364

0365

0366

0367

0368

0369

0370

0371

0372

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</Attribute>

</ResponsePayload>

</BatchItem>

</Attribute>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

0373

0374

0375

0376

0377

0378

0379

0380

0381

0382

0383

0384

0385

0386

0387

# TIME 4

</ProtocolVersion>

</RequestHeader>

</RequestPayload>

</BatchItem>

</RequestMessage>

0388

0389

0390

0391

0392

0393

0394

0395

0396

0397

0398

0399

0400

0401

0402

0403

0404

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

3.1.7 TL-M-1-12 - Configuration

0001

0002

0003

0004

0005

0006

0007

0008

0009

0010

0011

0012

0013

0014

0015

0016

0017

0018

0019

# TIME 0

</ProtocolVersion>

</RequestHeader>

</RequestPayload>

</BatchItem>

</RequestMessage>

0020

0021

0022

0023

0024

0025

0026

0027

0028

0029

0030

0031

0032

0033

0034

0035

0036

0037

0038

0039

0040

0041

0042

0043

0044

0045

0046

0047

0048

0049

0050

0051

0052

0053

0054

0055

</ProtocolVersion>

</ResponseHeader>

</ServerInformation>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

3.1.8 TL-M-2-12 - Write with new (created) key

Additional custom attributes MAY be specified in order to:

- ensure uniqueness of the key identifier when later Locating the key via ASI

- provide human-readable information (such as the tape Barcode value)

- provide information to support client-specific purposes

0001

0002

0003

0004

0005

0006

0007

0008

0009

0010

0011

0012

0013

0014

0015

0016

0017

0018

0019

0020

0021

0022

0023

0024

0025

0026

0027

0028

0029

0030

0031

0032

0033

0034

0035

0036

0037

0038

0039

0040

0041

0042

0043

0044

0045

0046

0047

0048

0049

0050

0051

0052

0053

0054

0055

0056

0057

0058

0059

0060

0061

0062

0063

0064

0065

0066

0067

0068

0069

0070

0071

0072

0073

0074

0075

0076

0077

0078

# TIME 0

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</TemplateAttribute>

</RequestPayload>

</BatchItem>

</RequestPayload>

</BatchItem>

</RequestMessage>

0079

0080

0081

0082

0083

0084

0085

0086

0087

0088

0089

0090

0091

0092

0093

0094

0095

0096

0097

0098

0099

0100

0101

0102

0103

0104

0105

0106

0107

0108

0109

0110

0111

0112

0113

0114

0115

0116

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</KeyValue>

</KeyBlock>

</SymmetricKey>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

3.1.9 TL-M-3-12 - Read an encrypted tape

The test case destroys the key created in the previous test case to clean up after the test. Tape Library implementations MAY not perform this step.

0001

0002

0003

0004

0005

0006

0007

0008

0009

0010

0011

0012

0013

0014

0015

0016

0017

0018

0019

0020

0021

0022

0023

0024

0025

0026

0027

0028

0029

0030

0031

0032

0033

# TIME 0

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</RequestPayload>

</BatchItem>

</RequestPayload>

</BatchItem>

</RequestMessage>

0034

0035

0036

0037

0038

0039

0040

0041

0042

0043

0044

0045

0046

0047

0048

0049

0050

0051

0052

0053

0054

0055

0056

0057

0058

0059

0060

0061

0062

0063

0064

0065

0066

0067

0068

0069

0070

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</KeyValue>

</KeyBlock>

</SymmetricKey>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

0071

0072

0073

0074

0075

0076

0077

0078

0079

0080

0081

0082

0083

0084

0085

0086

0087

0088

0089

0090

0091

0092

0093

0094

0095

0096

0097

0098

0099

0100

0101

0102

0103

# TIME 1

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</RequestPayload>

</BatchItem>

</RequestPayload>

</BatchItem>

</RequestMessage>

0104

0105

0106

0107

0108

0109

0110

0111

0112

0113

0114

0115

0116

0117

0118

0119

0120

0121

0122

0123

0124

0125

0126

0127

0128

0129

0130

0131

0132

0133

0134

0135

0136

0137

0138

0139

0140

0141

0142

0143

0144

0145

0146

0147

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

0148

0149

0150

0151

0152

0153

0154

0155

0156

0157

0158

0159

0160

0161

0162

0163

0164

0165

0166

0167

0168

0169

0170

0171

0172

0173

0174

0175

0176

0177

0178

0179

0180

# TIME 2

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</RequestPayload>

</BatchItem>

</RequestPayload>

</BatchItem>

</RequestMessage>

0181

0182

0183

0184

0185

0186

0187

0188

0189

0190

0191

0192

0193

0194

0195

0196

0197

0198

0199

0200

0201

0202

0203

0204

0205

0206

0207

0208

0209

0210

0211

0212

0213

0214

0215

0216

0217

0218

0219

0220

0221

0222

0223

0224

0225

0226

0227

0228

0229

0230

0231

0232

0233

0234

0235

0236

0237

0238

0239

0240

0241

0242

0243

0244

0245

0246

0247

0248

0249

0250

0251

0252

0253

0254

0255

0256

0257

0258

0259

0260

0261

0262

0263

0264

0265

0266

0267

0268

0269

0270

0271

0272

0273

0274

0275

0276

0277

0278

0279

0280

0281

0282

0283

0284

0285

0286

0287

0288

0289

0290

0291

0292

0293

0294

0295

0296

0297

0298

0299

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</AttributeValue>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</Attribute>

</AttributeValue>

</Attribute>

</Attribute>

</Attribute>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

0300

0301

0302

0303

0304

0305

0306

0307

0308

0309

0310

0311

0312

0313

0314

0315

0316

0317

0318

0319

0320

0321

0322

0323

0324

0325

0326

0327

0328

0329

0330

0331

0332

0333

0334

0335

0336

0337

0338

0339

0340

0341

0342

0343

0344

0345

0346

# TIME 3

</ProtocolVersion>

</RequestHeader>

</Attribute>

</AttributeValue>

</Attribute>

</RequestPayload>

</BatchItem>

</Attribute>

</RequestPayload>

</BatchItem>

</Attribute>

</RequestPayload>

</BatchItem>

</RequestMessage>

0347

0348

0349

0350

0351

0352

0353

0354

0355

0356

0357

0358

0359

0360

0361

0362

0363

0364

0365

0366

0367

0368

0369

0370

0371

0372

0373

0374

0375

0376

0377

0378

0379

0380

0381

0382

0383

0384

0385

0386

0387

0388

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</Attribute>

</ResponsePayload>

</BatchItem>

</Attribute>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

0389

0390

0391

0392

0393

0394

0395

0396

0397

0398

0399

0400

0401

0402

0403

# TIME 4

</ProtocolVersion>

</RequestHeader>

</RequestPayload>

</BatchItem>

</RequestMessage>

0404

0405

0406

0407

0408

0409

0410

0411

0412

0413

0414

0415

0416

0417

0418

0419

0420

</ProtocolVersion>

</ResponseHeader>

</ResponsePayload>

</BatchItem>

</ResponseMessage>

4 Conformance

4.1 Conformance Statement

KMIP client and server implementations conformant to this profile:SHALL support the Authentication Suite conditions (2.1);
SHALL support the Baseline Tape Library conditions (2.2);
SHALL support the Using Application Specific Information for Key Identifiers conditions (2.3);
SHALL support the Using Alternative Name for tape media barcode conditions (2.4); and
SHALL support all the Mandatory Test Cases (3.1) for each supported protocol version (major and minor).

4.2 Permitted Test Case Variations

Whilst the test cases provided in this Profile define the allowed request and response content, some inherent variations MAY occur and are permitted within a successfully completed test case.

Each test case MAY include allowed variations in the description of the test case in addition to the variations noted in this section.

Other variations not explicitly noted in this Profile SHALL be deemed non-conformant.

4.2.1 Variable Items

An implementation conformant to this Profile MAY vary the following values:

UniqueIdentifier
PrivateKeyUniqueIdentifier
PublicKeyUniqueIdentifier
UniqueBatchItemIdentifier
AsynchronousCorrelationValue
TimeStamp
KeyValue / KeyMaterial including:

key material content returned for managed cryptographic objects which are generated by the server
wrapped versions of keys where the wrapping key is dynamic or the wrapping contains variable output for each wrap operation

For response containing the output of cryptographic operation in Data / SignatureData/ MACData / IVCounterNonce where:

the managed object is generated by the server; or
the operation inherently contains variable output

For the following DateTime attributes where the value is not specified in the request as a fixed DateTime value:

ActivationDate
ArchiveDate
CompromiseDate
CompromiseOccurrenceDate
DeactivationDate
DestroyDate
InitialDate
LastChangeDate
ProtectStartDate
ProcessStopDate
ValidityDate
OriginalCreationDate

LinkedObjectIdentifier
DigestValue

For those managed cryptographic objects which are dynamically generated

KeyFormatType

The key format type selected by the server when it creates managed objects

Digest

a. The HashingAlgorithm selected by the server when it calculates the digest for a managed object for which it has access to the key material

b. The Digest Value

Extensions reported in Query for ExtensionList and ExtensionMap
Application Namespaces reported in Query
Object Types reported in Query other than those noted as required in this profile
Operation Types reported in Query other than those noted as required in this profile (or any referenced profile documents)
For TextString attribute values containing test identifiers:

a. Additional vendor or application prefixes

Additional attributes beyond those noted in the response

An implementation conformant to this Profile MAY allow the following response variations:

Object Group values – May or may not return one or more Object Group values not included in the requests
y-CustomAttributes – May or may not include additional server-specific associated attributes not included in requests
Message Extensions – May or may not include additional (non-critical) vendor extensions
TemplateAttribute – May or may not be included in responses where the Template Attribute response is noted as optional in [KMIP-SPEC]
AttributeIndex – May or may not include Attribute Index value where the Attribute Index value is 0 for Protocol Versions 1.1 and above.
ResultMessage – May or may not be included in responses and the value (if included) may vary from the text contained within the test case.
The list of Protocol Versions returned in a DiscoverVersion response may include additional protocol versions if the request has not specified a list of client supported Protocol Versions.
VendorIdentification - The value (if included) may vary from the text contained within the test case.

4.2.2 Variable behavior

An implementation conformant to this Profile SHALL allow variation of the following behavior:

A test may omit the clean-up requests and responses (containing Revoke and/or Destroy) at the end of the test provided there is a separate mechanism to remove the created objects during testing.
A test may omit the test identifiers if the client is unable to include them in requests. This includes the following attributes:

Name; and
x-ID

Appendix A. Acknowledgments

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

Participants:

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 Björkqvist, 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.

Doron Cohen, SafeNet, Inc

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

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, SafeNet, Inc.

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

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

Appendix B. KMIP Specification Cross Reference

Reference Term	KMIP 1.0	KMIP 1.1	KMIP 1.2
1 Introduction
Non-Normative References	1.3.	1.3.	1.3.
Normative References	1.2.	1.2.	1.2.
Terminology	1.1.	1.1.	1.1.

2 Objects
Attribute	2.1.1.	2.1.1.	2.1.1.
Base Objects	2.1.	2.1.	2.1.
Certificate	2.2.1.	2.2.1.	2.2.1.
Credential	2.1.2.	2.1.2.	2.1.2.
Data	-	-	2.1.10.
Data Length	-	-	2.1.11.
Extension Information	-	2.1.9.	2.1.9.
Key Block	2.1.3.	2.1.3.	2.1.3.
Key Value	2.1.4.	2.1.4.	2.1.4.
Key Wrapping Data	2.1.5.	2.1.5.	2.1.5.
Key Wrapping Specification	2.1.6.	2.1.6.	2.1.6.
MAC Data	-	-	2.1.13.
Managed Objects	2.2.	2.2.	2.2.
Nonce	-	-	2.1.14.
Opaque Object	2.2.8.	2.2.8.	2.2.8.
PGP Key	-	-	2.2.9.
Private Key	2.2.4.	2.2.4.	2.2.4.
Public Key	2.2.3.	2.2.3.	2.2.3.
Secret Data	2.2.7.	2.2.7.	2.2.7.
Signature Data	-	-	2.1.12.
Split Key	2.2.5.	2.2.5.	2.2.5.
Symmetric Key	2.2.2.	2.2.2.	2.2.2.
Template	2.2.6.	2.2.6.	2.2.6.
Template-Attribute Structures	2.1.8.	2.1.8.	2.1.8.
Transparent DH Private Key	2.1.7.6.	2.1.7.6.	2.1.7.6.
Transparent DH Public Key	2.1.7.7.	2.1.7.7.	2.1.7.7.
Transparent DSA Private Key	2.1.7.2.	2.1.7.2.	2.1.7.2.
Transparent DSA Public Key	2.1.7.3.	2.1.7.3.	2.1.7.3.
Transparent ECDH Private Key	2.1.7.10.	2.1.7.10.	2.1.7.10.
Transparent ECDH Public Key	2.1.7.11.	2.1.7.11.	2.1.7.11.
Transparent ECDSA Private Key	2.1.7.8.	2.1.7.8.	2.1.7.8.
Transparent ECDSA Public Key	2.1.7.9.	2.1.7.9.	2.1.7.9.
Transparent ECMQV Private Key	2.1.7.12.	2.1.7.12.	2.1.7.12.
Transparent ECMQV Public Key	2.1.7.13.	2.1.7.13.	2.1.7.13.
Transparent Key Structures	2.1.7.	2.1.7.	2.1.7.
Transparent RSA Private Key	2.1.7.4.	2.1.7.4.	2.1.7.4.
Transparent RSA Public Key	2.1.7.5.	2.1.7.5.	2.1.7.5.
Transparent Symmetric Key	2.1.7.1.	2.1.7.1.	2.1.7.1.

3 Attributes
Activation Date	3.19.	3.24.	3.24.
Alternative Name	-	-	3.40.
Application Specific Information	3.30.	3.36.	3.36.
Archive Date	3.27.	3.32.	3.32.
Attributes	3	3	3
Certificate Identifier	3.9.	3.13.	3.13.
Certificate Issuer	3.11.	3.15.	3.15.
Certificate Length	-	3.9.	3.9.
Certificate Subject	3.10.	3.14.	3.14.
Certificate Type	3.8.	3.8.	3.8.
Compromise Date	3.25.	3.30.	3.30.
Compromise Occurrence Date	3.24.	3.29.	3.29.
Contact Information	3.31.	3.37.	3.37.
Cryptographic Algorithm	3.4.	3.4.	3.4.
Cryptographic Domain Parameters	3.7.	3.7.	3.7.
Cryptographic Length	3.5.	3.5.	3.5.
Cryptographic Parameters	3.6.	3.6.	3.6.
Custom Attribute	3.33.	3.39.	3.39.
Deactivation Date	3.22.	3.27.	3.27.
Default Operation Policy	3.13.2.	3.18.2.	3.18.2.
Default Operation Policy for Certificates and Public Key Objects	3.13.2.2.	3.18.2.2.	3.18.2.2.
Default Operation Policy for Secret Objects	3.13.2.1.	3.18.2.1.	3.18.2.1.
Default Operation Policy for Template Objects	3.13.2.3.	3.18.2.3.	3.18.2.3.
Destroy Date	3.23.	3.28.	3.28.
Digest	3.12.	3.17.	3.17.
Digital Signature Algorithm	-	3.16.	3.16.
Fresh	-	3.34.	3.34.
Initial Date	3.18.	3.23.	3.23.
Key Value Location	-	-	3.42.
Key Value Present	-	-	3.41.
Last Change Date	3.32.	3.38.	3.38.
Lease Time	3.15.	3.20.	3.20.
Link	3.29.	3.35.	3.35.
Name	3.2.	3.2.	3.2.
Object Group	3.28.	3.33.	3.33.
Object Type	3.3.	3.3.	3.3.
Operation Policy Name	3.13.	3.18.	3.18.
Operations outside of operation policy control	3.13.1.	3.18.1.	3.18.1.
Original Creation Date	-	-	3.43.
Process Start Date	3.20.	3.25.	3.25.
Protect Stop Date	3.21.	3.26.	3.26.
Revocation Reason	3.26.	3.31.	3.31.
State	3.17.	3.22.	3.22.
Unique Identifier	3.1.	3.1.	3.1.
Usage Limits	3.16.	3.21.	3.21.
X.509 Certificate Identifier	-	3.10.	3.10.
X.509 Certificate Issuer	-	3.12.	3.12.
X.509 Certificate Subject	-	3.11.	3.11.

4 Client-to-Server Operations
Activate	4.18.	4.19.	4.19.
Add Attribute	4.13.	4.14.	4.14.
Archive	4.21.	4.22.	4.22.
Cancel	4.25.	4.27.	4.27.
Certify	4.6.	4.7.	4.7.
Check	4.9.	4.10.	4.10.
Create	4.1.	4.1.	4.1.
Create Key Pair	4.2.	4.2.	4.2.
Create Split Key	-	-	4.38.
Decrypt	-	-	4.30.
Delete Attribute	4.15.	4.16.	4.16.
Derive Key	4.5.	4.6.	4.6.
Destroy	4.20.	4.21.	4.21.
Discover Versions	-	4.26.	4.26.
Encrypt	-	-	4.29.
Get	4.10.	4.11.	4.11.
Get Attribute List	4.12.	4.13.	4.13.
Get Attributes	4.11.	4.12.	4.12.
Get Usage Allocation	4.17.	4.18.	4.18.
Hash	-	-	4.37.
Join Split Key	-	-	4.39.
Locate	4.8.	4.9.	4.9.
MAC	-	-	4.33.
MAC Verify	-	-	4.34.
Modify Attribute	4.14.	4.15.	4.15.
Obtain Lease	4.16.	4.17.	4.17.
Poll	4.26.	4.28.	4.28.
Query	4.24.	4.25.	4.25.
Re-certify	4.7.	4.8.	4.8.
Recover	4.22.	4.23.	4.23.
Register	4.3.	4.3.	4.3.
Re-key	4.4.	4.4.	4.4.
Re-key Key Pair	-	4.5.	4.5.
Revoke	4.19.	4.20.	4.20.
RNG Retrieve	-	-	4.35.
RNG Seed	-	-	4.36.
Sign	-	-	4.31.
Signature Verify	-	-	4.32.
Validate	4.23.	4.24.	4.24.

5 Server-to-Client Operations
Notify	5.1.	5.1.	5.1.
Put	5.2.	5.2.	5.2.

6 Message Contents
Asynchronous Correlation Value	6.8.	6.8.	6.8.
Asynchronous Indicator	6.7.	6.7.	6.7.
Attestation Capable Indicator	-	-	6.17.
Batch Count	6.14.	6.14.	6.14.
Batch Error Continuation Option	6.13.	6.13.	6.13.
Batch Item	6.15.	6.15.	6.15.
Batch Order Option	6.12.	6.12.	6.12.
Maximum Response Size	6.3.	6.3.	6.3.
Message Extension	6.16.	6.16.	6.16.
Operation	6.2.	6.2.	6.2.
Protocol Version	6.1.	6.1.	6.1.
Result Message	6.11.	6.11.	6.11.
Result Reason	6.10.	6.10.	6.10.
Result Status	6.9.	6.9.	6.9.
Time Stamp	6.5.	6.5.	6.5.
Unique Batch Item ID	6.4.	6.4.	6.4.

7 Message Format
Message Structure	7.1.	7.1.	7.1.
Operations	7.2.	7.2.	7.2.

8 Authentication
Authentication	8	8	8

9 Message Encoding
Alternative Name Type Enumeration	-	-	9.1.3.2.34.
Attestation Type Enumeration	-	-	9.1.3.2.36.
Batch Error Continuation Option Enumeration	9.1.3.2.29.	9.1.3.2.30.	9.1.3.2.30.
Bit Masks	9.1.3.3.	9.1.3.3.	9.1.3.3.
Block Cipher Mode Enumeration	9.1.3.2.13.	9.1.3.2.14.	9.1.3.2.14.
Cancellation Result Enumeration	9.1.3.2.24.	9.1.3.2.25.	9.1.3.2.25.
Certificate Request Type Enumeration	9.1.3.2.21.	9.1.3.2.22.	9.1.3.2.22.
Certificate Type Enumeration	9.1.3.2.6.	9.1.3.2.6.	9.1.3.2.6.
Credential Type Enumeration	9.1.3.2.1.	9.1.3.2.1.	9.1.3.2.1.
Cryptographic Algorithm Enumeration	9.1.3.2.12.	9.1.3.2.13.	9.1.3.2.13.
Cryptographic Usage Mask	9.1.3.3.1.	9.1.3.3.1.	9.1.3.3.1.
Defined Values	9.1.3.	9.1.3.	9.1.3.
Derivation Method Enumeration	9.1.3.2.20.	9.1.3.2.21.	9.1.3.2.21.
Digital Signature Algorithm Enumeration	-	9.1.3.2.7.	9.1.3.2.7.
Encoding Option Enumeration	-	9.1.3.2.32.	9.1.3.2.32.
Enumerations	9.1.3.2.	9.1.3.2.	9.1.3.2.
Examples	9.1.2.	9.1.2.	9.1.2.
Hashing Algorithm Enumeration	9.1.3.2.15.	9.1.3.2.16.	9.1.3.2.16.
Item Length	9.1.1.3.	9.1.1.3.	9.1.1.3.
Item Tag	9.1.1.1.	9.1.1.1.	9.1.1.1.
Item Type	9.1.1.2.	9.1.1.2.	9.1.1.2.
Item Value	9.1.1.4.	9.1.1.4.	9.1.1.4.
Key Compression Type Enumeration	9.1.3.2.2.	9.1.3.2.2.	9.1.3.2.2.
Key Format Type Enumeration	9.1.3.2.3.	9.1.3.2.3.	9.1.3.2.3.
Key Role Type Enumeration	9.1.3.2.16.	9.1.3.2.17.	9.1.3.2.17.
Key Value Location Type Enumeration	-	-	9.1.3.2.35.
Link Type Enumeration	9.1.3.2.19.	9.1.3.2.20.	9.1.3.2.20.
Name Type Enumeration	9.1.3.2.10.	9.1.3.2.11.	9.1.3.2.11.
Object Group Member Enumeration	-	9.1.3.2.33.	9.1.3.2.33.
Object Type Enumeration	9.1.3.2.11.	9.1.3.2.12.	9.1.3.2.12.
Opaque Data Type Enumeration	9.1.3.2.9.	9.1.3.2.10.	9.1.3.2.10.
Operation Enumeration	9.1.3.2.26.	9.1.3.2.27.	9.1.3.2.27.
Padding Method Enumeration	9.1.3.2.14.	9.1.3.2.15.	9.1.3.2.15.
Put Function Enumeration	9.1.3.2.25.	9.1.3.2.26.	9.1.3.2.26.
Query Function Enumeration	9.1.3.2.23.	9.1.3.2.24.	9.1.3.2.24.
Recommended Curve Enumeration for ECDSA, ECDH, and ECMQV	9.1.3.2.5.	9.1.3.2.5.	9.1.3.2.5.
Result Reason Enumeration	9.1.3.2.28.	9.1.3.2.29.	9.1.3.2.29.
Result Status Enumeration	9.1.3.2.27.	9.1.3.2.28.	9.1.3.2.28.
Revocation Reason Code Enumeration	9.1.3.2.18.	9.1.3.2.19.	9.1.3.2.19.
Secret Data Type Enumeration	9.1.3.2.8.	9.1.3.2.9.	9.1.3.2.9.
Split Key Method Enumeration	9.1.3.2.7.	9.1.3.2.8.	9.1.3.2.8.
State Enumeration	9.1.3.2.17.	9.1.3.2.18.	9.1.3.2.18.
Storage Status Mask	9.1.3.3.2.	9.1.3.3.2.	9.1.3.3.2.
Tags	9.1.3.1.	9.1.3.1.	9.1.3.1.
TTLV Encoding	9.1.	9.1.	9.1.
TTLV Encoding Fields	9.1.1.	9.1.1.	9.1.1.
Usage Limits Unit Enumeration	9.1.3.2.30.	9.1.3.2.31.	9.1.3.2.31.
Validity Indicator Enumeration	9.1.3.2.22.	9.1.3.2.23.	9.1.3.2.23.
Wrapping Method Enumeration	9.1.3.2.4.	9.1.3.2.4.	9.1.3.2.4.
XML Encoding	9.2.	-	-

10 Transport
Transport	10	10	10

12 KMIP Server and Client Implementation Conformance
Conformance clauses for a KMIP Server	12.1.	-	-
KMIP Client Implementation Conformance	-	12.2.	12.2.
KMIP Server Implementation Conformance	-	12.1.	12.1.

Appendix C. Revision History

Revision	Date	Editor	Changes Made
wd01	27-Jun-2013	Tim Hudson / Rod Wideman / Stan Feather	Converted from draft proposal to OASIS template incorporating updates from Stan Feather and inclusion of references to KMIP 1.2 documents. Editorial and formatting cleanup.
wd02	6-August-2013	Tim Hudson	Updated to include Permitted Test Case Variations and updated Test Cases based on July 2013 Interop
wd03	8-August-2013	Stan Feater / Rod Wideman	Editorial changes to section 3
wd04	10-August-2013	Tim Hudson	Updated Permitted Test Case Variations
wd04a	24-October-2013	Tim Hudson	Editorial update to include VendorIdentification in the list of allowed variations as per TC motion.