1 Introduction

This document specifies conformance clauses in accordance with the OASIS TC Process ([TC-PROC] section 2.18 paragraph 8a) for the KMIP Specification ([KMIP-SPEC] 12.1 and 12.2) for a KMIP server or KMIP client through profiles that define the use of KMIP objects, attributes, operations, message elements and authentication methods within specific contexts of KMIP server and client interaction.

These profiles define a set of normative constraints for employing KMIP within a particular environment or context of use. They may, optionally, require the use of specific KMIP functionality or in other respects define the processing rules to be followed by profile actors.

1.0 IPR Policy

This Committee Specification was developed under the RF on RAND Terms Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC’s web page (https://www.oasis-open.org/committees/kmip/ipr.php).

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].

1.2 Normative References

[KMIP-SPEC] Key Management Interoperability Protocol Specification Version 1.4. Edited by Tony Cox and Charles White. Latest version: http://docs.oasis-open.org/kmip/spec/v1.4/kmip-spec-v1.4.html.

[SuiteB] Suite B Cryptography / Cryptographic Interoperability, http://www.nsa.gov/ia/programs/suiteb_cryptography/

[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 & C.Allen, The TLS Protocol, Version 1.0, http://www.ietf.org/rfc/rfc2246.txt, IETF RFC 2246, January 1999

[RFC2818] E. Rescorla, HTTP over TLS, IETF RFC 2818, May 2000, http://www.ietf.org/rfc/rfc2818.txt

[RFC3268] P. Chown, Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS), http://www.ietf.org/rfc/rfc3268.txt, IETF RFC 3268, June 2002

[RFC4346] T. Dierks & E. Rescorla, The Transport Layer Security (TLS) Protocol, Version 1.1, http://www.ietf.org/rfc/rfc4346.txt, IETF RFC 4346, April 2006

[RFC5246] T. Dierks & E. Rescorla, The Transport Layer Security (TLS) Protocol, Version 1.2, http://www.ietf.org/rfc/rfc5246.txt, IETF RFC 5246, August 2008

[RFC7159] Bray, T., Ed., The JavaScript Object Notation (JSON) Data Interchange Format, RFC 7159, March 2014. http://www.ietf.org/rfc/rfc7159.txt

[CNSSP-15] N.S.A., “National Information Assurance Policy on the Use of Public Standards for the Secure Sharing of Information Among National Security Systems”, 1 October 2012, https://www.cnss.gov/CNSS/issuances/Policies.cfm.

[XML] Bray, Tim, et.al. eds, Extensible Markup Language (XML) 1.0 (Fifth Edition),

W3C Recommendation 26 November 2008, available at http://www.w3.org/TR/2008/REC-xml-20081126/

1.3 Non-Normative References

[TC-PROC] OASIS TC Process. 1 May 2014. OASIS Process. https://www.oasis-open.org/policies-guidelines/tc-process.

[XML-SCHEMA] Paul V. Biron, Ashok Malhotra, XML Schema Part 2: Datatypes Second Edition,

W3C Recommendation 26 November 2008, available at http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

2 Profiles

This document defines a list of KMIP Profiles. A profile may be standalone or may be specified in terms of changes relative to another profile.

2.1 Profile Requirements

The following items SHALL be addressed by each profile.

1. Specify the versions of the KMIP specification (protocol versions) that SHALL be supported

2. Specify the list of objects that SHALL be supported

3. Specify the list of Authentication Suites that SHALL be supported

4. Specify the list of Attributes that SHALL be supported

5. Specify the list of Operations that SHALL be supported

6. Specify any additional message content that SHALL be supported

7. Specify any other requirements that SHALL be supported

8. For profiles other than the Baseline Client, Baseline Server and Complete Server the profile SHALL specify the mandatory test cases that SHALL be supported and MAY specify the optional test cases that MAY be supported by conforming implementations

2.2 Guidelines for other Profiles

Any vendor or organization, such as other standards bodies, MAY create a KMIP Profile and publish it.

1. The profile SHALL be publicly available.

2. The KMIP Technical Committee SHALL be formally advised of the availability of the profile and the location of the published profile.

3. The profile SHALL meet all the requirements of section 2.1

4. The KMIP Technical Committee SHOULD review the profile prior to publication.

3 Authentication Suites

This section contains the list of the channel security, channel options, and server and client authentication requirements for a KMIP profile. Other Authentication Suites MAY be defined for other KMIP Profiles.

An Authentication Suite provides at least the following:

1. All communication over the security channel SHALL provide confidentiality and integrity

2. All communication over the security channel SHALL provide assurance of server authenticity

3. All communication over the security channel for Operations other than Query and Discover Versions SHALL provide assurance of client authenticity

4. All options such as channel protocol version and cipher suites for the secuity channel SHALL be specified

3.1 Basic Authentication Suite

This authentication suite stipulates that a profile conforming to the Basic Authentication Suite SHALL use TLS to negotiate a secure channel.

3.1.1 Basic Authentication Protocols

Conformant KMIP clients or servers SHALL support:

· TLS v1.2 [RFC5246]

Conformant KMIP clients or servers SHALL NOT support:

· TLS v1.0

· SSL v3.0

· SSL v2.0

· SSL v1.0

3.1.2 Basic Authentication Cipher Suites

Conformant KMIP clients or servers SHALL support the following cipher suites:

· TLS_RSA_WITH_AES_256_CBC_SHA256

· TLS_RSA_WITH_AES_128_CBC_SHA256

Conformant KMIP clients and servers MAY support the following cipher suites:

· TLS_RSA_WITH_AES_128_CBC_SHA

· TLS_RSA_WITH_AES_256_CBC_SHA

· TLS_DH_DSS_WITH_AES_128_CBC_SHA

· TLS_DH_RSA_WITH_AES_128_CBC_SHA

· TLS_DHE_DSS_WITH_AES_128_CBC_SHA

· TLS_DHE_RSA_WITH_AES_128_CBC_SHA

· TLS_DH_DSS_WITH_AES_256_CBC_SHA

· TLS_DH_RSA_WITH_AES_256_CBC_SHA

· TLS_DHE_DSS_WITH_AES_256_CBC_SHA

· TLS_DHE_RSA_WITH_AES_256_CBC_SHA

· TLS_DH_DSS_WITH_AES_128_CBC_SHA256

· TLS_DH_RSA_WITH_AES_128_CBC_SHA256

· TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

· TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

· TLS_DH_DSS_WITH_AES_256_CBC_SHA256

· TLS_DH_RSA_WITH_AES_256_CBC_SHA256

· TLS_DHE_DSS_WITH_AES_256_CBC_SHA256

· TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

· TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA

· TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

· TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384

· TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

· TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

· TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

· TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256

· TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384

· TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

· TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

· TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

· TLS_PSK_WITH_AES_128_CBC_SHA

· TLS_PSK_WITH_AES_256_CBC_SHA

· TLS_DHE_PSK_WITH_AES_128_CBC_SHA

· TLS_DHE_PSK_WITH_AES_256_CBC_SHA

· TLS_RSA_PSK_WITH_AES_128_CBC_SHA

· TLS_RSA_PSK_WITH_AES_256_CBC_SHA

· TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

· TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

· TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

· TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

Conformant KMIP clients or servers SHALL NOT support any cipher suite not listed above.

3.1.3 Basic Authentication Client Authenticity

Conformant KMIP servers SHALL require the use of channel (TLS) mutual authentication to provide assurance of client authenticity for all operations other than:

· Query

· Discover Versions

Conformant KMIP servers SHALL use the identity derived from the channel mutual authentication to determine the client identity if the KMIP client requests do not contain an Authentication object.

Conformant KMIP servers SHALL use the identity derived from the channel mutual authentication along with the Credential information to determine the client identity if the KMIP client requests contain an Authentication object.

The exact mechanisms determining the client identity are outside the scope of this specification.

3.1.4 Basic Authentication KMIP Port Number

Conformant KMIP servers SHALL use TCP port number 5696, as assigned by IANA.

3.2 TLS 1.2 Authentication Suite

This authentication suite stipulates that a profile conforming to the TLS 1.2 Authentication Suite SHALL use TLS version 1.2 to negotiate a secure channel.

3.2.1 TLS 1.2 Authentication Protocols

Conformant KMIP clients and servers SHALL support:

· TLS v1.2 [RFC2246]

3.2.2 TLS 1.2 Authentication Cipher Suites

Conformant KMIP servers SHALL support the following cipher suites:

· TLS_RSA_WITH_AES_256_CBC_SHA256

· TLS_RSA_WITH_AES_128_CBC_SHA256

Conformant KMIP servers and clients MAY support the cipher suites specified as MAY in Basic Authentication Cipher Suites (3.1.2) of the Basic Authentication Suite.

3.2.3 TLS 1.2 Authentication Client Authenticity

Conformant KMIP servers and clients SHALL handle client authenticity in accordance with Basic Authentication Client Authenticity (3.1.3) of the Basic Authentication Suite

3.2.4 TLS 1.2 Authentication KMIP Port Number

Conformant KMIP servers and clients SHALL handle the KMIP port number in in accordance with Basic Authentication KMIP Port Number (3.1.4) of the Basic Authentication Suite.

3.3 Suite B minLOS_128 Authentication Suite

Implementations conformant to this profile SHALL use TLS to negotiate a mutually-authenticated connection.

3.3.1 Suite B minLOS_128 Protocols

Conformant KMIP clients and servers SHALL support:

TLS v1.2 [RFC5246]

3.3.2 Suite B minLOS_128 Cipher Suites

Conformant KMIP servers SHALL support the following cipher suites:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

3.3.3 Suite B minLOS_128 Client Authenticity

Conformant KMIP servers and clients SHALL handle client authenticity in accordance with TLS 1.2 Authentication Client Authenticity (3.2.3).

3.3.4 Suite B minLOS_128 KMIP Port Number

Conformant KMIP servers and clients SHALL handle the KMIP port number in accordance with TLS 1.2 Authentication KMIP Port Number (3.2.4).

3.4 Suite B minLOS_192 Authentication Suite

Implementations conformant to this profile SHALL use TLS to negotiate a mutually-authenticated connection.

3.4.1 Suite B minLOS_192 Protocols

Conformant KMIP clients and servers SHALL support:

TLS v1.2 [RFC5246]

3.4.2 Suite B minLOS_192 Cipher Suites

Conformant KMIP servers SHALL support the following cipher suites:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

3.4.3 Suite B minLOS_192 Client Authenticity

Conformant KMIP servers and clients SHALL handle client authenticity in accordance with TLS 1.2 Authentication Client Authenticity (3.2.3).

3.4.4 Suite B minLOS_192 KMIP Port Number

Conformant KMIP servers and clients SHALL handle the KMIP port number in accordance with TLS 1.2 Authentication KMIP Port Number (3.2.4).

3.5 HTTPS Authentication Suite

This authentication suite stipulates that a profile conforming to the HTTPS Authentication Suite SHALL use HTTP over TLS [RFC2818] to negotiate a secure channel.

3.5.1 HTTPS Protocols

Conformant KMIP servers and clients SHALL handle client authenticity in accordance with Basic Authentication Protocols (3.1.1).

3.5.2 HTTPS Cipher Suites

Conformant KMIP servers and clients SHALL handle client authenticity in accordance with Basic Authentication Cipher Suites (3.1.2).

3.5.3 HTTPS Authenticity

Conformant KMIP servers and clients SHALL handle client authenticity in accordance with Basic Authentication Client Authenticity (3.1.3).

3.5.4 HTTPS KMIP Port Number

KMIP servers conformant to this profile MAY use TCP port number 5696, as assigned by IANA, to receive and send KMIP messages provided that both HTTPS and non-HTTPS encoded messages are supported.

KMIP clients SHALL enable end user configuration of the TCP port number used, as a KMIP server MAY specify a different TCP port number for HTTPS usage.

4 Conformance Test Cases

The test cases define a number of request-response pairs for KMIP operations. Each test case is provided in the XML format specified in XML Encoding (5.4.1) intended to be both human-readable and usable by automated tools.

Each test case has a unique label (the section name) which includes indication of mandatory (-M-) or optional (-O-) status and the protocol version major and minor numbers as part of the identifier.

The test cases may depend on a specific configuration of a KMIP client and server being configured in a manner consistent with the test case assumptions.

Where possible the flow of unique identifiers between tests, the date-time values, and other dynamic items are indicated using symbolic identifiers – in actual request and response messages these dynamic values will be filled in with valid values.

Symbolic identifiers are of the form $UPPERCASE_NAME followed by optional unique index value. Wherever a symbolic identifier occurs in a test cases the implementation must replace it with a reasonable appearing datum of the expected type. Time values can be specified in terms of an offset from the current time in seconds of the form $NOW or $NOW-n or $NOW+n.

Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real client or server system may vary as specified in section 4.1.

4.1 Permitted Test Case Variations

Whilst the test cases provided in a 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 section SHALL be deemed non-conformant.

4.1.1 Variable Items

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

Unique Identifier
Private Key Unique Identifier
Public Key Unique Identifier
Unique Batch Item ID
Asynchronous Correlation Value
Time Stamp
Key Value / Key Material 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 / Signature Data/ MAC Data / IV Counter Nonce 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:

Activation Date
Archive Date
Compromise Date
Compromise Occurrence Date
Deactivation Date
Destroy Date
Initial Date
Last Change Date
Protect Start Date
Process Stop Date
Validity Date
Original Creation Date

Linked Object Identifier
Digest Value

For those managed cryptographic objects which are dynamically generated

Key Format Type

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

Digest

a. The Hashing Algorithm 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 Extension List and Extension Map
Application Namespaces reported in Query
Object Types reported in Query other than those noted as required in the profile
Operation Types reported in Query other than those noted as required in the profile
For TextString attribute values containing test identifiers:

a. Additional vendor or application prefixes

Server Correlation Value
Client Correlation Value
Additional attributes beyond those noted in the response

An implementation conformant to a 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-Custom Attributes – 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
Template Attribute – May or may not be included in responses where the Template Attribute response is noted as optional in [KMIP-SPEC]
Attribute Index – May or may not include Attribute Index value where the Attribute Index value is 0 for Protocol Versions 1.1 and above.
Result Message – 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 Discover Version response may include additional protocol versions if the request has not specified a list of client supported Protocol Versions.
Vendor Identification - The value (if included) may vary from the text contained within the test case.
Random Number Generator – The value returned may vary from the value returned including any of the defined values for the RNG Algorithm field within the Random Number Generator attribute including Unspecified. The other fields within the Random Number Generator (all of which are defined as optional) may be present or omitted and their value each field may be set to any value that is permitted for such a field.
Located Items – The field MAY be present in responses to Locate even if an Offset Items field is not present in the request.

4.1.2 Variable behavior

An implementation conformant to a 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

A test MAY perform requests with multiple batch items or as multiple requests with a single batch item provided the sequence of operations are equivalent
A request MAY contain an optional Authentication [KMIP_SPEC] structure within each request
The order of Attributes returned in a Get Attributes operation is not specified in [KMIP-SPEC] and an implementation MAY return the list of items in any order provided all noted items are present. Any permutation of the order of the required entries is allowed.
For all profiles in each Batch Item of a client request including multiple batch items (i.e. Batch Count is greater than one) the Unique Batch Item ID must be specified. Unique Batch Item ID MAY be specified for client requests containing a single batch item (Batch Count equals one) or MAY be omitted. Any reasonable appearing datum of the expected type is permitted.

5 Profiles

5.1 Base Profiles

5.1.1 Baseline Client

A Baseline Client provides some of the most basic functionality that is expected of a conformant KMIP client – the ability to request information about the server.

An implementation is a conforming Baseline Client if it meets the following conditions:

Supports the conditions required by the KMIP Client conformance clauses ([KMIP-SPEC] 12.2)
Supports the following objects:

Attribute ([KMIP-SPEC] 2.1.1)
Template-Attribute Structure ([KMIP-SPEC] 2.1.8)

Supports the following subsets of attributes:

Unique Identifier ([KMIP-SPEC] 3.1)
Object Type ([KMIP-SPEC] 3.3)
Digest ([KMIP-SPEC] 3.17)
Default Operation Policy ([KMIP-SPEC] 3.18.2)
State ([KMIP-SPEC] 3.22)
Initial Date ([KMIP-SPEC] 3.23)
Activation Date ([KMIP-SPEC] 3.24)
Deactivation Date ([KMIP-SPEC] 3.27)
Last Change Date ([KMIP-SPEC] 3.38)

Supports the ID Placeholder ([KMIP-SPEC] 4)
Supports the following client-to-server operations:

Locate ([KMIP-SPEC] 4.9)
Get ([KMIP-SPEC] 4.11)
Get Attributes ([KMIP-SPEC] 4.12)
Query ([KMIP-SPEC] 4.25)

Supports the following message contents:

Protocol Version ([KMIP-SPEC] 6.1)
Operation ([KMIP-SPEC] 6.2)
Maximum Response Size ([KMIP-SPEC] 6.3)
Unique Batch Item ID ([KMIP-SPEC] 6.4)
Time Stamp ([KMIP-SPEC] 6.5)
Asynchronous Indicator ([KMIP-SPEC] 6.7)
Result Status ([KMIP-SPEC] 6.9)
Result Reason ([KMIP-SPEC] 6.10)
Batch Order Option ([KMIP-SPEC] 6.12)
Batch Error Continuation Option ([KMIP-SPEC] 6.13)
Batch Count ([KMIP-SPEC] 6.14)
Batch Item ([KMIP-SPEC] 6.15)
Server Correlation Value ([KMIP-SPEC] 6.19)
Message Extension ([KMIP-SPEC] 6.16)

Supports Message Format ([KMIP-SPEC] 7)
Supports Authentication ([KMIP-SPEC] 8)
Supports the TTLV encoding ([KMIP-SPEC] 9.1)
Supports the transport requirements ([KMIP-SPEC] 10)
Supports Error Handling ([KMIP-SPEC] 11) for any supported object, attribute, or operation
Optionally supports any clause within [KMIP-SPEC] that is not listed above.
Optionally supports extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not contradict any KMIP requirements

5.1.2 Baseline Server

A Baseline Server provides the most basic functionality that is expected of a conformant KMIP server – the ability to provide information about the server and the managed objects supported by the server.

An implementation is a conforming Baseline Server if it meets the following conditions:

Supports the conditions required by the KMIP Server conformance clauses ([KMIP-SPEC] 12.1)
Supports the following objects:

Attribute ([KMIP-SPEC] 2.1.1)
Credential ([KMIP-SPEC] 2.1.2)
Key Block ([KMIP-SPEC] 2.1.3)
Key Value ([KMIP-SPEC] 2.1.4)
Template-Attribute Structure ([KMIP-SPEC] 2.1.8)
Extension Information ([KMIP-SPEC] 2.1.9)
Profile Information ([KMIP-SPEC] 2.1.19)
Validation Information ([KMIP-SPEC] 2.1.20)

Capability Information ([KMIP-SPEC] 2.1.21)Supports the following subsets of attributes:

Unique Identifier ([KMIP-SPEC] 3.1)
Name ([KMIP-SPEC] 3.2)
Object Type ([KMIP-SPEC] 3.3)
Cryptographic Algorithm ([KMIP-SPEC] 3.4)
Cryptographic Length ([KMIP-SPEC] 3.5)
Cryptographic Parameters ([KMIP-SPEC] 3.6)
Digest ([KMIP-SPEC] 3.17)
Cryptographic Usage Mask ([KMIP-SPEC] 3.19)
State ([KMIP-SPEC] 3.22)
Initial Date ([KMIP-SPEC] 3.23)
Process Start Date ([KMIP-SPEC] 3.25)
Protect Stop Date ([KMIP-SPEC] 3.26)
Activation Date ([KMIP-SPEC] 3.24)
Deactivation Date ([KMIP-SPEC] 3.27)
Compromise Occurrence Date ([KMIP-SPEC] 3.29)
Compromise Date ([KMIP-SPEC] 3.30)
Revocation Reason ([KMIP-SPEC] 3.31)
Object Group ([KMIP-SPEC] 3.33)
Fresh ([KMIP-SPEC] 3.34)
Link ([KMIP-SPEC] 3.35)
Last Change Date ([KMIP-SPEC] 3.38)
Alternative Name ([KMIP-SPEC] 3.40)
Key Value Present ([KMIP-SPEC] 3.41)
Key Value Location ([KMIP-SPEC] 3.42)
Original Creation Date ([KMIP-SPEC] 3.43)
Random Number Generator ([KMIP-SPEC] 3.44)
Description ([KMIP-SPEC] 3.46)
Comment ([KMIP-SPEC] 3.47)
Sensitive ([KMIP-SPEC] 3.48])
Always Sensitive ([KMIP-SPEC] 3.49])
Extractable ([KMIP-SPEC] 3.50])
Never Extractable ([KMIP-SPEC] 3.51])

Supports the ID Placeholder ([KMIP-SPEC] 4)
Supports the following client-to-server operations:

Locate ([KMIP-SPEC] 4.9)
Check ([KMIP-SPEC] 4.10)
Get ([KMIP-SPEC] 4.11)
Get Attributes ([KMIP-SPEC] 4.12)
Get Attribute List ([KMIP-SPEC] 4.13)
Add Attribute ([KMIP-SPEC] 4.14)
Modify Attribute ([KMIP-SPEC] 4.15)
Delete Attribute ([KMIP-SPEC] 4.16)
Activate ([KMIP-SPEC] 4.19)
Revoke ([KMIP-SPEC] 4.20)
Destroy ([KMIP-SPEC] 4.21)
Query ([KMIP-SPEC] 4.25)
Discover Versions ([KMIP-SPEC] 4.26)

Supports the following message contents:

Protocol Version ([KMIP-SPEC] 6.1)
Operation ([KMIP-SPEC] 6.2)
Maximum Response Size ([KMIP-SPEC] 6.3)
Unique Batch Item ID ([KMIP-SPEC] 6.4)
Time Stamp ([KMIP-SPEC] 6.5)
Asynchronous Indicator ([KMIP-SPEC] 6.7)
Result Status ([KMIP-SPEC] 6.9)
Result Reason ([KMIP-SPEC] 6.10)
Batch Order Option ([KMIP-SPEC] 6.12)
Batch Error Continuation Option ([KMIP-SPEC] 6.13)
Batch Count ([KMIP-SPEC] 6.14)
Batch Item ([KMIP-SPEC] 6.15)
Attestation Capable Indicator ([KMIP-SPEC] 6.17)
Client Correlation Value ([KMIP-SPEC] 6.18)
Server Correlation Value ([KMIP-SPEC] 6.19)
Message Extension ([KMIP-SPEC] 6.16)

Supports Message Format ([KMIP-SPEC] 7)
Supports Authentication ([KMIP-SPEC] 8)
Supports the TTLV encoding ([KMIP-SPEC] 9.1)
Supports the transport requirements ([KMIP-SPEC] 10)
Supports Error Handling ([KMIP-SPEC] 11) for any supported object, attribute, or operation
Optionally supports any clause within [KMIP-SPEC] that is not listed above
Optionally supports extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not contradict any KMIP requirements

5.2 Complete Server Profile

A Complete Server provides functionality that is expected of a conformant KMIP server that implements the entire specification.

An implementation is a conforming Complete Server if it meets the following conditions:

Supports the conditions required by the KMIP Server conformance clauses ([KMIP-SPEC] 12.1)
Supports Objects ([KMIP-SPEC] 2)
Supports Attributes ([KMIP-SPEC] 3)
Supports Client-to-Server operations ([KMIP-SPEC] 4)
Supports Server-to-Client operations ([KMIP-SPEC] 5)
Supports Message Contents ([KMIP-SPEC] 6)
Supports Message Formats ([KMIP-SPEC] 7)
Supports Authentication ([KMIP-SPEC] 8)
Supports Message Encodings ([KMIP-SPEC] 9)
Supports Error Handling ([KMIP-SPEC] 11)
Optionally supports extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not contradict any KMIP requirements

5.3 HTTPS Profiles

The Hypertext Transfer Protocol over Transport Layer Security (HTTPS) is simply the use of HTTP over TLS in the same manner that HTTP is used over TCP.

KMIP over HTTPS is simply the use of KMIP messages over HTTPS in the same manner that KMIP is used over TLS.

5.3.1 HTTPS Client

KMIP clients conformant to this profile:

SHALL support HTTP/1.0 and/or HTTP/1.1 over TLS conformant to [RFC2818]
SHALL use the POST request method
SHOULD support the value /kmip as the target URI.
SHALL enable end user configuration of the target URI used as a KMIP server MAY specify a different target URI.
SHALL specify a Content-Type of “application/octet-stream” if the message encoding is TTLV
SHALL specify a Content-Type of “text/xml" if the message encoding is XML
SHALL specify a Content-Type of “application/json" if the message encoding is JSON
SHALL specify a Content-Length
SHALL specify a Cache-Control of “no-cache”
SHALL send KMIP TTLV message in binary format as the body of the HTTP request

KMIP clients that support responding to server to client operations SHALL behave as a HTTPS server.

5.3.2 HTTPS Server

KMIP servers conformant to this profile:

SHALL support HTTP/1.0 and HTTP/1.1 over TLS conformant to [RFC2818]
SHALL return HTTP response code 200 if a KMIP response is available
SHOULD support the value /kmip as the target URI.
SHALL specify a Content-Type of “application/octet-stream” if the message encoding is TTLV
SHALL specify a Content-Type of “text/xml" if the message encoding is XML
SHALL specify a Content-Type of “application/json" if the message encoding is JSON
SHALL specify a Content-Length
SHALL specify a Cache-Control of “no-cache”
SHALL send KMIP TTLV message in binary format as the body of the HTTP request

KMIP servers that support server to client operations SHALL behave as a HTTPS client.

5.3.3 HTTPS Mandatory Test Cases KMIP v1.4

5.3.3.1 MSGENC-HTTPS-M-1-14

Perform a Query operation, querying the Operations and Objects supported by the server, with a restriction on the Maximum Response Size set in the request header. Since the resulting Query response is too big, an error is returned. Increase the Maximum Response Size, resubmit the Query request, and get a successful response.

The specific list of operations and object types returned in the response MAY vary.

See test-cases/kmip-v1.4/mandatory/MSGENC-HTTPS-M-1-14.xml.

The informative corresponding wire encoding for the test case is:

Request Time 0

00000000: 50 4f 53 54 20 2f 6b 6d-69 70 20 48 54 54 50 2f POST /kmip HTTP/

00000010: 31 2e 30 0d 0a 50 72 61-67 6d 61 3a 20 6e 6f 2d 1.0..Pragma: no-

00000020: 63 61 63 68 65 0d 0a 43-61 63 68 65 2d 43 6f 6e cache..Cache-Con

00000030: 74 72 6f 6c 3a 20 6e 6f-2d 63 61 63 68 65 0d 0a trol: no-cache..

00000040: 43 6f 6e 6e 65 63 74 69-6f 6e 3a 20 6b 65 65 70 Connection: keep

00000050: 2d 61 6c 69 76 65 0d 0a-43 6f 6e 74 65 6e 74 2d -alive..Content-

00000060: 54 79 70 65 3a 20 61 70-70 6c 69 63 61 74 69 6f Type: applicatio

00000070: 6e 2f 6f 63 74 65 74 2d-73 74 72 65 61 6d 0d 0a n/octet-stream..

00000080: 43 6f 6e 74 65 6e 74 2d-4c 65 6e 67 74 68 3a 20 Content-Length:

00000090: 31 35 32 20 20 20 20 20-20 20 0d 0a 0d 0a 42 00 152 ....B.

000000a0: 15 32 78 01 00 00 00 90-42 00 77 01 00 00 00 48 .2x.....B.w....H

000000b0: 42 00 69 01 00 00 00 20-42 00 6a 02 00 00 00 04 B.i.... B.j.....

000000c0: 00 00 00 01 00 00 00 00-42 00 6b 02 00 00 00 04 ........B.k.....

000000d0: 00 00 00 03 00 00 00 00-42 00 50 02 00 00 00 04 ........B.P.....

000000e0: 00 00 01 00 00 00 00 00-42 00 0d 02 00 00 00 04 ........B.......

000000f0: 00 00 00 01 00 00 00 00-42 00 0f 01 00 00 00 38 ........B......8

00000100: 42 00 5c 05 00 00 00 04-00 00 00 18 00 00 00 00 B.\.............

00000110: 42 00 79 01 00 00 00 20-42 00 74 05 00 00 00 04 B.y.... B.t.....

00000120: 00 00 00 01 00 00 00 00-42 00 74 05 00 00 00 04 ........B.t.....

00000130: 00 00 00 02 00 00 00 00- ........

Response Time 0

00000000: 48 54 54 50 2f 31 2e 31-20 32 30 30 20 4f 4b 0d HTTP/1.1 200 OK.

00000010: 0a 43 6f 6e 74 65 6e 74-2d 54 79 70 65 3a 20 61 .Content-Type: a

00000020: 70 70 6c 69 63 61 74 69-6f 6e 2f 6f 63 74 65 74 pplication/octet

00000030: 2d 73 74 72 65 61 6d 0d-0a 43 6f 6e 74 65 6e 74 -stream..Content

00000040: 2d 4c 65 6e 67 74 68 3a-20 31 36 38 0d 0a 0d 0a -Length: 168....

00000050: 42 00 7b 01 00 00 00 a0-42 00 7a 01 00 00 00 48 B.{.... B.z....H

00000060: 42 00 69 01 00 00 00 20-42 00 6a 02 00 00 00 04 B.i.... B.j.....

00000070: 00 00 00 01 00 00 00 00-42 00 6b 02 00 00 00 04 ........B.k.....

00000080: 00 00 00 03 00 00 00 00-42 00 92 09 00 00 00 08 ........B.......

00000090: 00 00 00 00 56 8a 5b e2-42 00 0d 02 00 00 00 04 ....V.[bB.......

000000a0: 00 00 00 01 00 00 00 00-42 00 0f 01 00 00 00 48 ........B......H

000000b0: 42 00 5c 05 00 00 00 04-00 00 00 18 00 00 00 00 B.\.............

000000c0: 42 00 7f 05 00 00 00 04-00 00 00 01 00 00 00 00 B...............

000000d0: 42 00 7e 05 00 00 00 04-00 00 00 02 00 00 00 00 B.~.............

000000e0: 42 00 7d 07 00 00 00 09-54 4f 4f 5f 4c 41 52 47 B.}.....TOO_LARG

000000f0: 45 00 00 00 00 00 00 00- E.......

Request Time 1