1 Introduction

This document specifies conformance clauses in accordance with the OASIS TC Process ([TC-PROC] section 2.2.6 for the KMIP Specification [KMIP-SPEC] 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.1 IPR Policy

This specification is provided 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.2 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] and [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.3 Normative References

[KMIP-SPEC] Key Management Interoperability Protocol Specification Version 3.0. Edited by Greg Scott and Charles White. Latest version: <-v3.0https://docs.oasis-open.org/kmip/kmip-spec/v3.0/kmip-spec-v3.0.html>.

[PKCS11-PROF] PKCS #11 Cryptographic Token Interface Profiles Version 3.1. Edited by Tim Hudson. Latest version: <https://docs.oasis-open.org/pkcs11/pkcs11-profiles/v3.1/pkcs11-profiles-v3.1-os.html>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2818] E. Rescorla, HTTP over TLS, IETF RFC 2818, May 2000,<http://www.rfc-editor.org/info/rfc2818>.

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

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

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.

[RFC8446] E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.3, IETF RFC 8446, August 2018, <http://www.rfc-editor.org/info/rfc8446>.

[XML] Bray, Tim, et.al. eds, Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation 26 November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.

1.4 Non-Normative References

[RFC2246] T. Dierks & C. Allen, The TLS Protocol, Version 1.0, IETF RFC 2246, January 1999, <http://www.rfc-editor.org/info/rfc2246>.

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

[TC-PROC] OASIS TC Process. 1 July 2017. 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, <https://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 if versions other than [KMIP-SPEC] are 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 Object Attributes that SHALL be supported

5. Specify the list of Operations that SHALL be supported

6. Specify any other requirements that SHALL be supported

7. Specify the mandatory test cases that SHALL be supported by conforming implementations

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 final 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 SHALL provide assurance of client authenticity

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

When using automated client provisioning, the assurance of server authenticity and client authenticity MAY be provided via means outside of the security channel protocol.

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 servers SHALL support:

· TLS v1.3 [RFC8446]

Conformant KMIP clients SHOULD support:

· TLS v1.3 [RFC8446]

Conformant KMIP servers SHOULD support:

· TLS v1.2 [RFC5246]

Conformant KMIP clients MAY support:

· TLS v1.2 [RFC5246]

Conformant KMIP clients or servers SHALL NOT support:

· TLS v1.1 [RFC4346]

· TLS v1.0 [RFC2246]

· Any version of the SSL protocol

3.1.2 Basic Authentication Cipher Suites

Conformant KMIP servers SHALL support all of the following cipher suites for TLSv1.3 if TLSv1.3 is supported:

TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES-256-GCM-SHA384

Conformant KMIP clients SHALL support at least one of the following cipher suites for TLSv1.3 if TLSv1.3 is supported:

TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES-256-GCM-SHA384

Conformant KMIP clients or servers SHALL support the following cipher suites for TLSv1.2 if TLSv1.2 is supported:

· TLS_RSA_WITH_AES_256_CBC_SHA256

· TLS_RSA_WITH_AES_128_CBC_SHA256

Conformant KMIP clients or servers MAY support the following cipher suites for TLSv1.2 if TLSv1.2 is supported:

· TLS_RSA_WITH_AES_128_CBC_SHA

· TLS_RSA_WITH_AES_256_CBC_SHA

· 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_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 SHOULD require the use of channel (TLS) mutual authentication to provide assurance of client authenticity for all operations.

Conformant KMIP servers SHOULD use the identity derived from the channel mutual authentication to determine the client identity if the KMIP client requests do not contain an Authentication message data structure.

If a KMIP client requests contain an Authentication message data structure (i.e. credentials), then Conformant KMIP servers SHALL use the identity derived from the credentials to determine the client identity.

If a KMIP server omits requiring the use of channel mutual authentication, then the KMIP client SHALL contain an Authentication message data structure and the KMIP server SHALL use the credentials information to determine the client identity and the Authentication message data structure SHALL include some form of authentication (i.e. password or other form of authentication is required and cannot be omitted).

A KMIP server MAY treat the identity determined from the channel mutual authentication as independent from the identity determined from the credentials.

A KMIP server MAY require the identity determined from the channel mutual authentication to be bound to the identity determined from the credentials.

3.1.4 Basic Authentication KMIP Port Number

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

3.2 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.2.1 HTTPS Protocols

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

3.2.2 HTTPS Cipher Suites

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

3.2.3 HTTPS Authenticity

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

3.2.4 HTTPS KMIP Port Number

KMIP servers conformant to this profile SHOULD 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
Short Unique Identifier
Private Key Unique Identifier
Public Key Unique Identifier
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
Build Date
Compromise Date
Compromise Occurrence Date
Deactivation Date
Destroy Date
Initial Date
Last Change Date
Protect StopDate
Process Start Date
Rotate Date
Submission Date
Validity Date
Original Creation Date

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 except when the key format type is specified in the request or there is a default value required in the specification and in which case the value must match.

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 provided that a Digest is always available with the Hashing Algorithm of SHA256 (the default)

b. The Digest Value

Extensions reported in Query for function Query Extension List and Query Extension Map
Application Namespaces reported in Query for function Query Application Namespaces
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:

Vendor 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
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.
Server Information – the contents of the structure returned MAY vary although the structure itself SHALL be present if specified in the response.

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 (where the name includes the test identifier); and
Interop Identifier

A test MAY perform requests with multiple batch items or as multiple requests with a single batch item in each request provided that the sequence of operations are logically equivalent and performed in the same order
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.
A test MAY be preceded by a request containing the Operation Interop with the Interop Function set to Begin
A test MAY be followed by a request containing the Operation Interop with the Interop Function set to End
Use of the Operation Interop is optional (it is not expected that production KMIP clients will support the Interop Operation) however the use of the Interop function during a formal interop test event may be mandatory (depending on the rules of the specific interop event).

5 Base 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 Implementation Conformance clauses [KMIP-SPEC]
Supports the following Attribute Data Structures [KMIP-SPEC]:

Attributes

Supports the following Object Attributes [KMIP-SPEC]:

Activation Date
Deactivation Date
Digest
Initial Date
Last Change Date
Object Type
State
Unique Identifier

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

Get
Get Attributes
Locate
Query

Supports the following Message Data Structures [KMIP-SPEC]:

Asynchronous Indicator
Batch Error Continuation Option
Batch Item
Maximum Response Size
Message Extension
Operation
Protocol Version
Result Reason
Result Status
Server Correlation Value
Time Stamp

Supports the Message Protocols [KMIP-SPEC]

Authentication
Transport
TTLV

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 Implementation Conformance clauses [KMIP-SPEC]
Supports the following System Objects [KMIP-SPEC]:

User
Group
Credentials

i. Password Credential

Supports the following User Objects [KMIP-SPEC]:

Certificate
Group
Credential

Supports the following Attribute Data Structures [KMIP-SPEC]:

Attributes

Supports the following Message Data Structures [KMIP-SPEC]:

Credential

Supports the following Object Data Structures [KMIP-SPEC]:

Key Block
Key Value

Supports the following Operations Data Structures [KMIP-SPEC]:

Capability Information
Credential Information
Defaults Information
Extension Information
Profile Information
RNG Parameters
Server Information
Validation Information

Supports the following Object Attributes [KMIP-SPEC]:

Activation Date
Alternative Name
Always Sensitive
Certificate Attributes

i. All defined Certificate Attributes

Certificate Type
Certificate Length
Comment
Compromise Date
Compromise Occurrence Date
Contact Information
Counters

i. All defined Counter Attributes

Credential Type
Cryptographic Algorithm
Cryptographic Domain Parameters
Cryptographic Length
Cryptographic Parameters
Cryptographic Usage Mask
Deactivation Date
Deactivation Reason
Description
Destroy Date
Digest
Digital Signature Algorithm
Extractable
Fresh
Initial Date
Key Format Type
Key Value Location
Key Value Present
Last Change Date
Lease Time
Links

i. All defined Link Attributes

Name
Never Extractable
NIST Key Type
Object Class
Object Type
Original Creation Date
Process Start Date
Protect Stop Date
Protection Level
Protection Period
Protection Storage Mask
Quantum Safe
Random Number Generator
Revocation Reason
Rotate Automatic
Rotate Date
Rotate Generation
Rotate Interval
Rotate Latest
Rotate Name
Rotate Offset
Sensitive
Short Unique Identifier
State
Unique Identifier
Usage Limits
Vendor Attribute
X.509 Certificate Identifier
X.509 Certificate Issuer
X.509 Certificate Subject

Supports the following Client-to-Server Operations [KMIP-SPEC]

a. Activate

b. Add Attribute

c. Adjust Attribute

d. Create Credential

e. Create Group

f. Create User

g. Check

h. Deactivate

i. Delete Attribute

j. Destroy

k. Discover Versions

l. Export

m. Get

n. Get Attribute List

o. Get Attributes

p. Get Constraints

q. Get Usage Allocation

r. Import

s. Interop

t. Modify Attribute

u. Locate

v. Log

w. Login

x. Logout

y. Obliterate

z. Ping

aa. Query

bb. Register

cc. Revoke

dd. Set Attribute

ee. Set Defaults

ff. Set Endpoint Role

Supports Server-to-Client Operations [KMIP-SPEC]

a. Discover Versions

b. Notify

c. Put

d. Query

e. Set Endpoint Role

Supports the following Message Data Structures [KMIP-SPEC]:

Asynchronous Indicator
Attestation Capable Indicator
Batch Error Continuation Option
Batch Item
Client Correlation Value
Maximum Response Size
Message Extension
Operation
Protocol Version
Result Reason
Result Status
Server Correlation Value
Time Stamp

Supports the Message Protocols [KMIP-SPEC]

Authentication
Transport
TTLV

Optionally supports extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not contradict any KMIP requirements

5.1.3 Baseline Mandatory Test Cases KMIP v3.0

5.1.3.19 BL-M-19-30

5.1.3.20 See test-cases/kmip-v3.0/mandatory/BL-M-19-30.xml.BL-M-20-30

See test-cases/kmip-v3.0/mandatory/BL-M-20-30.xml.

5.1.3.21 BL-M-21-30

See test-cases/kmip-v3.0/mandatory/BL-M-21-30.xml.

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 KMIP Server Implementation Conformance [KMIP-SPEC]
Supports Objects [KMIP-SPEC]
Supports Object Data Structures [KMIP-SPEC]
Supports Object Attributes [KMIP-SPEC]
Supports Attribute Data Structures [KMIP-SPEC]
Supports Operations [KMIP-SPEC]
Supports Operations Data Structures [KMIP-SPEC]
Supports Messages [KMIP-SPEC]
Supports Message Data Structures [KMIP-SPEC]
Supports Message Protocols [KMIP-SPEC]
Supports Enumerations [KMIP-SPEC]
Supports Bit Masks [KMIP-SPEC]
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 v3.0

5.3.3.1 MSGENC-HTTPS-M-1-30

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-v3.0/mandatory/MSGENC-HTTPS-M-1-30.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