KMIP Opaque Managed Object Store Profile Version 1.0
OASIS Standard
19 May 2015
Specification URIs
This version:
http://docs.oasis-open.org/kmip/kmip-opaque-obj-profile/v1.0/os/kmip-opaque-obj-profile-v1.0-os.doc
(Authoritative)
http://docs.oasis-open.org/kmip/kmip-opaque-obj-profile/v1.0/os/kmip-opaque-obj-profile-v1.0-os.html
http://docs.oasis-open.org/kmip/kmip-opaque-obj-profile/v1.0/os/kmip-opaque-obj-profile-v1.0-os.pdf
Previous version:
http://docs.oasis-open.org/kmip/kmip-opaque-obj-profile/v1.0/csprd01/kmip-opaque-obj-profile-v1.0-csprd01.doc
(Authoritative)
http://docs.oasis-open.org/kmip/kmip-opaque-obj-profile/v1.0/csprd01/kmip-opaque-obj-profile-v1.0-csprd01.html
http://docs.oasis-open.org/kmip/kmip-opaque-obj-profile/v1.0/csprd01/kmip-opaque-obj-profile-v1.0-csprd01.pdf
Latest version:
http://docs.oasis-open.org/kmip/kmip-opaque-obj-profile/v1.0/kmip-opaque-obj-profile-v1.0.doc
(Authoritative)
http://docs.oasis-open.org/kmip/kmip-opaque-obj-profile/v1.0/kmip-opaque-obj-profile-v1.0.html
http://docs.oasis-open.org/kmip/kmip-opaque-obj-profile/v1.0/kmip-opaque-obj-profile-v1.0.pdf
Technical Committee:
OASIS Key Management Interoperability
Protocol (KMIP) TC
Chairs:
Saikat Saha (saikat.saha@oracle.com), Oracle
Tony Cox (tjc@cryptsoft.com),
Cryptsoft Pty Ltd.
Editors:
Tim Hudson (tjh@cryptsoft.com),
Cryptsoft Pty Ltd.
Robert Lockhart (Robert.Lockhart@thalesesec.com),
Thales e-Security
Related work:
This specification is related to:
·
Key Management Interoperability Protocol Profiles Version 1.0.
Edited by Robert Griffin and Subhash Sankuratripati. Latest version: http://docs.oasis-open.org/kmip/profiles/v1.0/kmip-profiles-1.0.html.
·
Key Management Interoperability Protocol Profiles Version 1.1.
Edited by Robert Griffin and Subhash Sankuratripati. Latest version: http://docs.oasis-open.org/kmip/profiles/v1.1/kmip-profiles-v1.1.html.
·
Key Management Interoperability Protocol Profiles Version 1.2.
Edited by Tim Hudson and Robert Lockhart. Latest version: http://docs.oasis-open.org/kmip/profiles/v1.2/kmip-profiles-v1.2.html.
·
Key Management Interoperability Protocol Specification Version
1.1. Edited by Robert Haas and Indra Fitzgerald. Latest version: http://docs.oasis-open.org/kmip/spec/v1.1/kmip-spec-v1.1.html.
·
Key Management Interoperability Protocol Specification Version
1.2. Edited by Kiran Thota and Kelley Burgin. Latest version: http://docs.oasis-open.org/kmip/spec/v1.2/kmip-spec-v1.2.html.
·
Key Management Interoperability Protocol Test Cases Version
1.2. Edited by Tim Hudson and Faisal Faruqui. Latest version: http://docs.oasis-open.org/kmip/testcases/v1.2/kmip-testcases-v1.2.html.
·
Key Management Interoperability Protocol Usage Guide Version
1.2. Edited by Indra Fitzgerald and Judith Furlong. Latest version: http://docs.oasis-open.org/kmip/ug/v1.2/kmip-ug-v1.2.html.
Abstract:
Describes a profile for a KMIP server performing opaque
managed object storage operations based on requests received from a KMIP
client.
Status:
This document was last revised or approved by the membership
of OASIS on the above date. The level of approval is also listed above. Check
the “Latest version” location noted above for possible later revisions of this
document. Any other numbered Versions and other technical work produced by the
Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip#technical.
Technical Committee members should send comments on this
specification to the Technical Committee’s email list. Others should send
comments to the Technical Committee by using the “Send
A Comment” button on the Technical Committee’s web page at https://www.oasis-open.org/committees/kmip/.
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 Technical Committee web page (https://www.oasis-open.org/committees/kmip/ipr.php.
Citation format:
When referencing this specification the following citation
format should be used:
[kmip-opaque-obj-v1.0]
KMIP Opaque Managed Object Store Profile
Version 1.0. Edited by Tim Hudson and Robert Lockhart. 19 May 2015. OASIS
Standard. http://docs.oasis-open.org/kmip/kmip-opaque-obj-profile/v1.0/os/kmip-opaque-obj-profile-v1.0-os.html.
Latest version: http://docs.oasis-open.org/kmip/kmip-opaque-obj-profile/v1.0/kmip-opaque-obj-profile-v1.0.html.
Copyright © OASIS Open 2015. All Rights Reserved.
All capitalized terms in the following text have the
meanings assigned to them in the OASIS Intellectual Property Rights Policy (the
"OASIS IPR Policy"). The full Policy may be
found at the OASIS website.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, published, and
distributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this section are included on all such
copies and derivative works. However, this document itself may not be modified
in any way, including by removing the copyright notice or references to OASIS,
except as needed for the purpose of developing any document or deliverable
produced by an OASIS Technical Committee (in which case the rules applicable to
copyrights, as set forth in the OASIS IPR Policy, must be followed) or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that
believes it has patent claims that would necessarily be infringed by
implementations of this OASIS Committee Specification or OASIS Standard, to
notify OASIS TC Administrator and provide an indication of its willingness to
grant patent licenses to such patent claims in a manner consistent with the IPR
Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC
Administrator if it is aware of a claim of ownership of any patent claims that
would necessarily be infringed by implementations of this specification by a
patent holder that is not willing to provide a license to such patent claims in
a manner consistent with the IPR Mode of the OASIS Technical Committee that
produced this specification. OASIS may include such claims on its website, but
disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed to pertain to
the implementation or use of the technology described in this document or the
extent to which any license under such rights might or might not be available;
neither does it represent that it has made any effort to identify any such
rights. Information on OASIS' procedures with respect to rights in any document
or deliverable produced by an OASIS Technical Committee can be found on the
OASIS website. Copies of claims of rights made available for publication and
any assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such proprietary
rights by implementers or users of this OASIS Committee Specification or OASIS
Standard, can be obtained from the OASIS TC Administrator. OASIS makes no
representation that any information or list of intellectual property rights
will at any time be complete, or that any claims in such list are, in fact,
Essential Claims.
The name "OASIS" is a trademark of OASIS, the owner and developer of this
specification, and should be used only to refer to the organization and its
official outputs. OASIS welcomes reference to, and implementation and use of,
specifications, while reserving the right to enforce its marks against
misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark
for above guidance.
1 Introduction. 5
1.1
Terminology. 5
1.2
Normative References. 5
2 Opaque
Managed Object Store Profile. 6
2.1
Authentication Suite. 6
2.2 Opaque
Managed Object Store – Client 6
2.3 Opaque
Managed Object Store – Server 6
3 Opaque
Managed Object Store Profile - Test Cases. 8
3.1
Mandatory Test Cases KMIP 1.0. 8
3.1.1
OMOS-M-1-10. 8
3.2
Mandatory Test Cases KMIP 1.1. 10
3.2.1
OMOS-M-1-11. 10
3.3
Mandatory Test Cases KMIP 1.2. 11
3.3.1
OMOS-M-1-12. 11
3.4 Optional
Test Cases KMIP 1.0. 13
3.4.1
OMOS-O-1-10. 13
3.5 Optional
Test Cases KMIP 1.1. 17
3.5.1
OMOS-O-1-11. 17
3.6 Optional
Test Cases KMIP 1.2. 21
3.6.1
OMOS-O-1-12. 21
4 Conformance. 27
4.1 Opaque
Managed Object Store Client KMIP v1.0 Profile. 27
4.2 Opaque
Managed Object Store Client KMIP v1.1 Profile. 27
4.3 Opaque
Managed Object Store Client KMIP v1.2 Profile. 27
4.4 Opaque
Managed Object Store Server KMIP v1.0 Profile. 27
4.5 Opaque
Managed Object Store Server KMIP v1.1 Profile. 27
4.6 Opaque
Managed Object Store Server KMIP v1.2 Profile. 27
4.7
Permitted Test Case Variations. 27
4.7.1
Variable Items. 28
4.7.2
Variable behavior 29
Appendix A. Acknowledgments. 30
Appendix B. KMIP
Specification Cross Reference. 33
Appendix C. Revision
History. 38
For
normative definition of the elements of KMIP see the KMIP Specification [KMIP-SPEC]
and the KMIP Profiles [KMIP-PROF].
This profile defines the necessary KMIP functionality that
a KMIP implementation conforming to this profile SHALL support in order to
interoperate in conformance with this profile.
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].
[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.
[KMIP-ENCODE] KMIP Additional Message Encodings Version 1.0. Edited by Tim Hudson. Latest version: http://docs.oasis-open.org/kmip/kmip-addtl-msg-enc/v1.0/kmip-addtl-msg-enc-v1.0.doc.
[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. Edited by
Kiran Thota and Kelley Burgin. Latest version: http://docs.oasis-open.org/kmip/spec/v1.2/kmip-spec-v1.2.doc.
[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 Profiles 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 Profiles 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 Profiles Version 1.2. Edited by Tim Hudson and
Robert Lockhart. Latest version: http://docs.oasis-open.org/kmip/profiles/v1.2/kmip-profiles-v1.2.doc.
The Opaque Managed Object Store Profile is a KMIP server
performing storage related operations on opaque objects based on requests
received from a KMIP client.
Implementations conformant to this profile SHALL support at least
one of the Authentication Suites defined within section 3 of [KMIP-PROF. The
establishment of the trust relationship between the KMIP client and the KMIP
server is the same as the defined base profiles.
KMIP clients conformant to this profile under
[KMIP-SPEC-1_0]:
- SHALL conform to the [KMIP-SPEC-1_0]
KMIP clients conformant to this profile under
[KMIP-SPEC-1_1]:
- SHALL conform to the Baseline Client Clause
(section 5.12) of [KMIP-PROF-1_1]
KMIP clients conformant to this profile under
[KMIP-SPEC-1_2]:
- SHALL conform to the Baseline Client (section 5.2) of
[KMIP-PROF-1_2]
KMIP clients conformant to this profile:
- 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 contradict any
KMIP requirements.
KMIP servers conformant to this profile under
[KMIP-SPEC-1_0]:
- SHALL conform to the [KMIP-SPEC-1_0]
KMIP servers conformant to this profile under
[KMIP-SPEC-1_1]:
- SHALL conform to the Baseline Server of
[KMIP-PROF-1_1]
KMIP servers conformant to this profile under
[KMIP-SPEC-1_2]:
- SHALL conform to the Baseline Server of [KMIP-PROF-1_2]
KMIP servers conformant to this profile:
- SHALL support the following Objects [KMIP-SPEC]
- Opaque Object [KMIP-SPEC]
- SHALL support the following Attributes [KMIP-SPEC]
a. Object
Type [KMIP-SPEC]
- SHALL support the following Client-to-Server
[KMIP-SPEC] operations:
a. Register
[KMIP-SPEC]
- SHALL support the following Message Encoding
[KMIP-SPEC]:
a. Opaque
Data Type [KMIP-SPEC]
b. Object Type
[KMIP-SPEC] with value:
i. Opaque
Object
- MAY support any clause within [KMIP-SPEC] provided it does
not conflict with any other clause within this section 2.3
- MAY support extensions outside the scope of this standard
(e.g., vendor extensions, conformance clauses) that do not contradict any
KMIP requirements.
The test cases define a number of request-response pairs for
KMIP operations. Each test case is provided in the XML format specified in
[KMIP-ENCODE] intended to be both human-readable and usable by automated tools.
The time sequence (starting from 0) for each request-response pair is noted and
line numbers are provided for ease of cross-reference for a given test
sequence.
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.
Note: the values for the returned items and the custom
attributes are illustrative. Actual values from a real client system may vary
as specified in section 4.7.
Register small opaque object
|
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
|
# TIME 0
<RequestMessage>
<RequestHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="0"/>
</ProtocolVersion>
<BatchCount type="Integer" value="1"/>
</RequestHeader>
<BatchItem>
<Operation type="Enumeration" value="Register"/>
<RequestPayload>
<ObjectType type="Enumeration" value="OpaqueObject"/>
<TemplateAttribute>
<Attribute>
<AttributeName type="TextString" value="Name"/>
<AttributeValue>
<NameValue type="TextString" value="OMOS-M-1-10"/>
<NameType type="Enumeration"
value="UninterpretedTextString"/>
</AttributeValue>
</Attribute>
</TemplateAttribute>
<OpaqueObject>
<OpaqueDataType type="Enumeration" value="0x80000001"/>
<OpaqueDataValue type="ByteString"
value="53656372657450617373776f7264"/>
</OpaqueObject>
</RequestPayload>
</BatchItem>
</RequestMessage>
|
|
0029
0030
0031
0032
0033
0034
0035
0036
0037
0038
0039
0040
0041
0042
0043
0044
0045
|
<ResponseMessage>
<ResponseHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="0"/>
</ProtocolVersion>
<TimeStamp type="DateTime" value="2012-04-27T08:12:24+00:00"/>
<BatchCount type="Integer"
value="1"/>
</ResponseHeader>
<BatchItem>
<Operation type="Enumeration" value="Register"/>
<ResultStatus type="Enumeration"
value="Success"/>
<ResponsePayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</ResponsePayload>
</BatchItem>
</ResponseMessage>
|
|
0046
0047
0048
0049
0050
0051
0052
0053
0054
0055
0056
0057
0058
0059
0060
|
# TIME 1
<RequestMessage>
<RequestHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="0"/>
</ProtocolVersion>
<BatchCount type="Integer" value="1"/>
</RequestHeader>
<BatchItem>
<Operation type="Enumeration" value="Destroy"/>
<RequestPayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</RequestPayload>
</BatchItem>
</RequestMessage>
|
|
0061
0062
0063
0064
0065
0066
0067
0068
0069
0070
0071
0072
0073
0074
0075
0076
0077
|
<ResponseMessage>
<ResponseHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="0"/>
</ProtocolVersion>
<TimeStamp type="DateTime" value="2012-04-27T08:12:24+00:00"/>
<BatchCount type="Integer"
value="1"/>
</ResponseHeader>
<BatchItem>
<Operation type="Enumeration" value="Destroy"/>
<ResultStatus type="Enumeration"
value="Success"/>
<ResponsePayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</ResponsePayload>
</BatchItem>
</ResponseMessage>
|
Register small opaque object
|
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
|
# TIME 0
<RequestMessage>
<RequestHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="1"/>
</ProtocolVersion>
<BatchCount type="Integer" value="1"/>
</RequestHeader>
<BatchItem>
<Operation type="Enumeration" value="Register"/>
<RequestPayload>
<ObjectType type="Enumeration" value="OpaqueObject"/>
<TemplateAttribute>
<Attribute>
<AttributeName type="TextString" value="Name"/>
<AttributeValue>
<NameValue type="TextString" value="OMOS-M-1-11"/>
<NameType type="Enumeration"
value="UninterpretedTextString"/>
</AttributeValue>
</Attribute>
</TemplateAttribute>
<OpaqueObject>
<OpaqueDataType type="Enumeration" value="0x80000001"/>
<OpaqueDataValue type="ByteString"
value="53656372657450617373776f7264"/>
</OpaqueObject>
</RequestPayload>
</BatchItem>
</RequestMessage>
|
|
0029
0030
0031
0032
0033
0034
0035
0036
0037
0038
0039
0040
0041
0042
0043
0044
0045
|
<ResponseMessage>
<ResponseHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="1"/>
</ProtocolVersion>
<TimeStamp type="DateTime" value="2012-04-27T08:12:24+00:00"/>
<BatchCount type="Integer"
value="1"/>
</ResponseHeader>
<BatchItem>
<Operation type="Enumeration" value="Register"/>
<ResultStatus type="Enumeration"
value="Success"/>
<ResponsePayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</ResponsePayload>
</BatchItem>
</ResponseMessage>
|
|
0046
0047
0048
0049
0050
0051
0052
0053
0054
0055
0056
0057
0058
0059
0060
|
# TIME 1
<RequestMessage>
<RequestHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="1"/>
</ProtocolVersion>
<BatchCount type="Integer" value="1"/>
</RequestHeader>
<BatchItem>
<Operation type="Enumeration" value="Destroy"/>
<RequestPayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</RequestPayload>
</BatchItem>
</RequestMessage>
|
|
0061
0062
0063
0064
0065
0066
0067
0068
0069
0070
0071
0072
0073
0074
0075
0076
0077
|
<ResponseMessage>
<ResponseHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="1"/>
</ProtocolVersion>
<TimeStamp type="DateTime" value="2012-04-27T08:12:24+00:00"/>
<BatchCount type="Integer"
value="1"/>
</ResponseHeader>
<BatchItem>
<Operation type="Enumeration" value="Destroy"/>
<ResultStatus type="Enumeration"
value="Success"/>
<ResponsePayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</ResponsePayload>
</BatchItem>
</ResponseMessage>
|
Register small opaque object
|
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
|
# TIME 0
<RequestMessage>
<RequestHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="2"/>
</ProtocolVersion>
<BatchCount type="Integer" value="1"/>
</RequestHeader>
<BatchItem>
<Operation type="Enumeration" value="Register"/>
<RequestPayload>
<ObjectType type="Enumeration" value="OpaqueObject"/>
<TemplateAttribute>
<Attribute>
<AttributeName type="TextString" value="Name"/>
<AttributeValue>
<NameValue type="TextString" value="OMOS-M-1-12"/>
<NameType type="Enumeration"
value="UninterpretedTextString"/>
</AttributeValue>
</Attribute>
</TemplateAttribute>
<OpaqueObject>
<OpaqueDataType type="Enumeration" value="0x80000001"/>
<OpaqueDataValue type="ByteString"
value="53656372657450617373776f7264"/>
</OpaqueObject>
</RequestPayload>
</BatchItem>
</RequestMessage>
|
|
0029
0030
0031
0032
0033
0034
0035
0036
0037
0038
0039
0040
0041
0042
0043
0044
0045
|
<ResponseMessage>
<ResponseHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="2"/>
</ProtocolVersion>
<TimeStamp type="DateTime" value="2012-04-27T08:12:24+00:00"/>
<BatchCount type="Integer"
value="1"/>
</ResponseHeader>
<BatchItem>
<Operation type="Enumeration" value="Register"/>
<ResultStatus type="Enumeration"
value="Success"/>
<ResponsePayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</ResponsePayload>
</BatchItem>
</ResponseMessage>
|
|
0046
0047
0048
0049
0050
0051
0052
0053
0054
0055
0056
0057
0058
0059
0060
|
# TIME 1
<RequestMessage>
<RequestHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="2"/>
</ProtocolVersion>
<BatchCount type="Integer" value="1"/>
</RequestHeader>
<BatchItem>
<Operation type="Enumeration" value="Destroy"/>
<RequestPayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</RequestPayload>
</BatchItem>
</RequestMessage>
|
|
0061
0062
0063
0064
0065
0066
0067
0068
0069
0070
0071
0072
0073
0074
0075
0076
0077
|
<ResponseMessage>
<ResponseHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="2"/>
</ProtocolVersion>
<TimeStamp type="DateTime" value="2012-04-27T08:12:24+00:00"/>
<BatchCount type="Integer"
value="1"/>
</ResponseHeader>
<BatchItem>
<Operation type="Enumeration" value="Destroy"/>
<ResultStatus type="Enumeration"
value="Success"/>
<ResponsePayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</ResponsePayload>
</BatchItem>
</ResponseMessage>
|
Register larger (>10k) opaque object
|
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
|
# TIME 0
<RequestMessage>
<RequestHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="0"/>
</ProtocolVersion>
<BatchCount type="Integer" value="1"/>
</RequestHeader>
<BatchItem>
<Operation type="Enumeration" value="Register"/>
<RequestPayload>
<ObjectType type="Enumeration" value="OpaqueObject"/>
<TemplateAttribute>
<Attribute>
<AttributeName type="TextString" value="Name"/>
<AttributeValue>
<NameValue type="TextString" value="OMOS-O-1-10"/>
<NameType type="Enumeration"
value="UninterpretedTextString"/>
</AttributeValue>
</Attribute>
</TemplateAttribute>
<OpaqueObject>
<OpaqueDataType type="Enumeration" value="0x80000001"/>
<OpaqueDataValue type="ByteString"
value="168392816fd71b3d1c5d9cecfacf61f4e396374ede655d9d15305d6a0a04e5f0beab1de8be60fb716de00456c0b4adaadd5e1f4e72879251dbf7d25ca9f81076daa0b6464ae989a76a6f6710ea9560a60b99cb4f697cd075cd799cb7dbcfffab4c2aba5a19529f14307f6d217b1c84114eab50855b623d2e2a7602cdd230778939cce2a03550b0e0c9a4ff7e0ad2af805a92bbe4a41ba3405565ca050c38c6d5b92d902c30544b1460e2360459ee2ef3376b66caf91e0e0980d12ea6c19b5623cf03ad065652cf247ee2be155deacfda3d96b35f21d2f97fe4fd28244dec67f61c32250f5fc93dc515c1b5c7004f212b7c1d60972f3aa0372789364a3a762f80fda1d58389ea3cb3d204db887b0db62623350d4ea7d1bfd91e6d522fab6942abe5ab9f76278e4cb280fed409268c2731552c8292829a47355852d5780388a4e13691f8ec654226ce52e213fff30b0b3de7ffb7444c7748f7e90dd893276d526a657bdf42ea588721788feb605e5d3443ebe0691be98af902a3d6a459f1e160df7dc3a7507b05a238d49c6d5ef6803ffb964cd813db90f549c2393fae94fcfc8c05ddb62a71bfc031074f4d32ada48491c970dedf57c139cb04c94112fcef3eec9fdd7487eecd1470741f780e0d9e99ba68e97945b7ab7970f8003f80ca9622c94192281c13380894dc1f6c6d88848ffe81fd994862d2c60db1b651dbf12a245d34fc0e2a1b7cf36428c1e481890607a4df45ea20619ea02946af0c7c41fc16bc620159871659c8105506fb0d4017921ea79ac082afad5cb9bf703a49ac79fd1f428fdca5a8f693990bfbca9640a44bf43e5786111f624369d1d33a08cd7247be07f9bad26e531a2f3f9aea66536682296348cf86291af9c2521bc6196747986d02b3a465dfbbe9468c3b364a8048441e32dc8ff190f0ad62b2c0f6a6d4aa715580b1fb2cab038560259981eee6f59f850c076c29507e9efd9cca183f5bd8a0a876820ed173f884f6a9773c8102859b59b286002147b86428c18537590ff9b3cbe3dd2f7607f2b7d84227c5d9ca6e6f272631672960f0da9c69d6b31eb499d50d724e3e3d4f0c98242438915de54f1a600acd13f9ce483c01dcd8c5d36a7cc57ead5f4066b849b8a5e00cc56019bebb2e8129a6481e9f4b234154808236538c500ccd597a273068dc442f3c12050050209538cb1ea3194a18278b55d589d34e7680f565ed411359eaddf12c0bdfe907b16377827d6ca46460d19f703c7b17fd3b7be9f45c162a34502f507673d304487e11c27c9827cbc9cc5e3992514aa6e62d3163e338af19e99fcddec6ee17f70af7c9644a297af3ec237619b8580bd20ae8ada4ce7dfe834711560b598f5aab65eac8fd2a8d66f574c79e4f19faa08dda5823ddc4f532f3053841dc52213dc147b325599a4b5969fa2642fb50c01030b14253d0f23fd34f663581e95da9bfb0e3f52a010b2f5911ff063ac2a826c94a8789445bc229a1ef1fe74fd8b5f672e8ffa671a5c69d19a4d7611c149cd5268d590788aa3e44e949beb46f38a8fa51a301824e88c220ae41ba4b036c672342c043ebc6db91035b70ae68d58f558a3a5d1a788a6694c4f74278a204743fae6d947b502e29552ba65507e91b684a3955aafb43530f02ccccaeded9a6d1f877da2470f36c26014653493c970613f25de9c21f0682062881de0fc6ce2712e6f924408e7d29d368c43ed198f14f5e947bb2f721084e6c22f750a6cd2400c49b9689e4e0f5d3d52005c5e42a6aa0ecdc237f7b1868b7e77bce2c0d8f160a061f0de6529967e82586fe854bc89ed68dc7d9ac521aa2f40e1c4c3835ad8c2881ec579975d4cf9d9beb69d0f2c4b4f1e69ace6da5b9f6e49801ac9e1c5922176e3c72b8f0b73629d457a10456d9c8f0ae56e40cb01f64ba0b49ea69f23728cffa532fd01b966ff31c30fedc9a52b7b0a5fe6a2e3bd53c87560cf74b12143696e52343317c408d8e13bdb1fbd2758aaa3cf8aa3fd229bb65a9e41228372889147470cee02ae4acb89d52e31f8da66543fc8a6c02a6b337ce10d0f41f464a44509c245476be1e5b11df8dbb867664cec0882beee6e21a022abcb89ded8a17cf6f17da33c094e42be30a3c070950ff300993abb40fac22f0ecf7d155c9261516796cb1de4c0d6bfc21e716b04d23dbb8b465708204a3b96af8e46042e8205e7df92b9e01c7794c94a5036b7f85fe0967515cc05ea460c7810c0c551d8fd94f7ad7d1a641e73a1471e9364bf4e2b4687c7700381d46d39a3159f486d0323de59c5f555d323e5c072fbfc0758e22aa6a1df04d13bf4bfe6632853424984d56d16ed61402a640c7e1b07d9439d1fdc2df147df02639575b50da6cd769cb367dbfe3316e03939e85880f8b19f2689d5504f25200560dd815fd4535a1b5f70c8332c95c9d292c75e971df28ec6ff6d70a52ad78d236a51ec4a12243a650285fbd6aa4632fab8fa56eb26f638855147d72efcdd8a0b4367122f8e2210d39ffc87ac29ab5c5f1226bea04693e0b5c671269d96ac0c665fbd4f5fdb04ffcd7b76f0f8c1960e7a47c88226d6bd360e4dd65d70ed687e2fea04822f7c8394007ee085a9362a35506696c44e531786472a3db4bddd2b63ae1a448d0442d11f28dfed4de000c820e40174e216d274ab1321be6f21d1e4eb7e22430c131b2050c1fcb9ebb2823dd6fb4f4972ea4167795f911fb8a3c7f14ecf71a0e675657263c2f4b5eb72369d9d2d457999dc15392ccc10d98308830dd9b64d95427381afa9549c5df5081de88849126197154968d96797c573901e80bc638bc4126c01dea36a56c1afe01021a21a776f6b4e375dd42156cce98998bd3036401550b501fac4ad653bcf098db8f6d9ef76429a60137e0f507c67b57ddf829c5ed88f4369a6cc7287683fa225515697cc2e43ffd8108e7f1564736d043b6323ae17bda3031fab7712f886ac12afbeb2686700c1133017f64363293f93ab3c4e096aff76751377e5b6e5ead512a2f3d36635fcac28bf7fcf5c565bcf51bf650e7e3c80194a34b7348e7517fd4301f9986cdcbbe27392291da368ca699d90bca1b49122b20649f6b95529a72ba8217546042cb975720b3c6e08ea2ed9faf23f975524a3857f5d20f76f6df0b5cf16fe7b054f4c996042728c8b41326f7edf94fe04b0c084762ecc7c604c3375d3e3f572afad8d27eb06a98a99e9af63c5ee3ed2b5d20cb910eb29596ccb8391f06c376083247fc940598bd3d888bc579a9496eba784dfea823a0a1a28cecc20951e4bef35596147f53d4957fa965e071d5a5c80b982ea26b6500b9a63e2a1c1196cde4deb61a0358ef822a0e00849e807b110d036d268480089e21d4f07ce43d9fcf233ec0e7044460410a6cc7254becfb27d31679a63e4285632d7477561e4af332f2cc622443f8a94e7f03a93c8ca4b10871a562ad9f6a00e9f70c273fd4bef730201d3bcd75e2bbfeac22d98c6667d7b8d0cb965b94d1be33c5329821a6292239ac93a896d7086e435c249c484a66bf002b1b99a2f633bc8fb9ffc8c7aeb4ed95301f4bc51441802ca28f56257e77efb556ea385e086c6e9c3fe901b9bfa034ef9a5202d29030e5e962635baf5b878cc2b7f7414e6b68fcfd26066084e936eed103a4073bca9cfb6a209251aa59fc6caead3faef33ed547d47876656a55cebb5cb6cba8b294081540f627f2235588f69eef2c4b029781a31a5884f20bd3699ff71a0726ee9a9e41caa19bd9ad50660dd9cda8852f2c555d1f4162e13ab0dfa63d6661f28d856838ef093286447c277aba2b4d05a6559f1f214bc73bed5f47e1e73465c58718904618ebcb16b6a3feb719c2f3ff4e5409d1aece9aca7bba3019d5def920e2b78512f74e44326d23a42f78b7eece89296ed9315d7bc097eace97dc3691aad6b3d7d79885d4e1def2800e6f3e94685e66b234daeef3d2d6c638e961408892941cafed16ccdf523a91d2ae4b871250ed0b9b53e5e0e93837ca400f9d5f11030ef1536e39592a23ee10ec0f568cc373b1d65fe424cc9382fb653fb5f347acc6dab0998ee6f9f9d26bf93c6909d88fb0b0d05298c7424a7d30dc3f54b1bbb2b9d33903b3faf133f21aa7234917269fefe6a2691526dfa7647bce8758598524c2532b695eb174ab4c08405a7532374167317eef95d7b2044e6409e2bdc70b9463b5a50c8647692b334904e5906405766c7f3f6fb5e07786c6fa37c2e8d96dcf0a3b65ed4d4f031b627920586b8c23092dcc1f99e6267ef25b0a75a00a48070a92032e9ed0a58eb7adc4b4571e85165b50449b4441416e550ecd612b55ef2cc6a3f8036351b00db614c248c11a1a8b7d945ed719f2fb0d0855cea744cb637e3e709a55274d9f41b9a9026a857c1c6c30257391e5b510cf06254fcb85c3992634a50eba9f58974de34dfa65dceca9ac467b4efa9706fb5dc196d277f07cd46e7431b785591c39387f6671542d9ab5caf9ef97aa43f7b46bb75a4fc8661b14513f13609bae9722f3b4b0d03d039e5e1ae3cddd29e729e6afa7ab605be00f7dae13d874349affad716385139c14f90296b2bab2bef5ac8a1086660701bd4b574e9c3cc1b5999a3f5eb67ec10c1ab025a4d621955010e44dca1a08032f12478c65755678da26e411890e6bcddb30c1bce42d40d036c390e6a8a63ecbd6b1b6ca3be45d4dcc82bb8c4b3c05a66ef039c2c22f733a6531a5cf8374db73ab67b4c50d4efd000e6346f345f1c469813505683f67ebb120c9ce5f96d1b3476ddc8e320dde1ca0e0ccfba2f2922195b4f73defcd2dc45b7f72a5f2cba86fc0b67587d317944acc3cee8f7461571137690bca0c62f4df293348c1cb86e41abf55d90acdb1862bac1378b1f3e04b3d0a3fa8a28115b2ec08103eb70e0bbd8c9c6a1b6597d06e14dab1b20b6a60020f061c1ab5380e400b27a583c22ea32a7b481dd855c2a26096020c40e0d0f20ed75052afb7f6bebe83a794ea0662e149306d0b03083297ef6ac920a065805d96232715ca161271c33370a71835bbe31b722b04168a20012953f425ced6ca60fe9926a510b879376508008c8bcb1af5a97064c2309c809ff153ff242267b44dd0075e4bd9e0ece58516cc41fda213f21a6cb40ad2f4395ccd100f985eaaada93cf9e3964e9ca23f6f9b5ae8d72a40a4d534ea6fea998a2726615c72d86757a6c5946c45871850709855d5bd3c1683b476e21fd3afdffe94eca83e48c283fc8462f1a618481676ff987e12fc63a19feafcf54aa9754cc39511c2750eb0ed6ec6e059810d3f0a49f7fd47830450b1d26d4db70a18d1d76e8877dc24e1e89bb448cdf24d5664b2228bd4c8bfb6f344ac1f1c3f535ad6dc77641bad188d67eedbe34b42389708d6007bdd591a5dec58663f0c75c956d7e8dd1552639d8313a5ddbf10aefbd2f1f153971f0ad1ed0a767c9ab66d4deffb1271eb4760d280899cdafec6de7d13cd298cddf4e8450be0e7d63c9afa51139c9cc3c780557f659e37301e0f268ff4811f8c04cd65adf3d676cee7e9c3fac68d792edb1af47edd08460fec81ae29dbeb3c3b4fe17f87be656102b4e654b67bff33b4e60e04171d8cd0795d58a93914df26b6f6bcd94838e9f563e19202d2ebd12544ac97a15ba32db7d8f449f36d512622e4054364c1e68df0f48688a6f9d66f3caca4651a4811d6562ebcb624e22d7bd8468e7aa4451883b9e5421c4b849e07a52d5c4e686f19ebae0c75df57375d2f56bde33c6c9715a4cf6f1272a0f18e88ff99eb9f79b5e48a20e1bd99a719b724c96d2c8ca07fb1645aed79289dde7586aa9a8e219e02872c1f40c0107a2290ea950b3893273358f02301594d918a527555a8018786d357dfb348ce626c17cafb9b88905678b120a8d6c54a9840e99dfb56d22e12ff7f09c2883058cfa106b54a289e02be522a0a4d19178fd772383ed9cfe3433bcd20c4f512d01d44ee734c71acae9785fef664de661535d1c1e4ae59bbb702727d07567c4266023072e3ec300322300dc601f6de9cb009bd9df68d0b54f4adb2951af99b8d45d157d78b9bb908c079509ba3d3680e4cc4ed1ce990ba9a261cdd1064a7755c18b67293350d2cc57a28ef1b9432326483b9c2020a1a7bf07178528b7fcc0072eeb31019ba0cac461a55c46f7a30dd1554e2861ceb98ca52d0106c09bbfd6e2d9c2061d797199846119294f293679740bfb06626974f93382e9e854df29bc8aef4dc3bc1122dbabd3cc1ae646bafa5d5b5824fffc22860e737419800f8037f3d0ac05bd041345e94e597817ff15a5f2332b697a97507954a664eed19e925daba33c575773ebdbaf42babf42d17073e1d595fb612519ccc560451c66c82cf2f2b220d58fd6d666a089b843f993c784e4b07027ccbb72437a69ce1b8e34050b254d3f9d195750edfaf92f5cff1140ea202cbc489b32ab4d78f6cbc7205cdd9ec64db4dba9477e141f1bb54aaf929e9fb766711eaa7b802818e03c2576bc5fbd54a8daf64fa8907a50b81db4b53f87ad894342ba54304ff013586aadba30f40f8c62c127287f2ef26303fbb0be86f581f51881686d3ee672a567c887c88122eddf9ea2e75ce4788b8b07b7bf30bd68ab766d336d3de479d3b7b738873b53fb367af51e26e098d9f60b2ff9eb364db4847adb19f45a6644298dda56b1fa62857a55aeed02fd4b7ad11dabf45cc94b92e797c4d8e53646da4847e0f84372466d6503cea856f000274afd00fd97b69d185fc14ab25a5cb9d897b85f5e22f8f881b113b60e89b05f2717fe29a8c3eccba97755e827ef02cd95ad52a1de25ae6deefa3f150c61f39256f3dc2959c4f0ad94ccab130c9f69642534484ba82733bfc102aaffbd86103975cfb8146df3ffe895e462fabac9ab8e49ba900e7ddb63fd32e2b6487fe52d1e2c42ec16da300214992fc45dbeb39474e2edce031c153c0ff88d970c71707bde5eeb5a8cec19b79558d8cf6ba7d1fd6c6e6361fc4f4245850166cb3ed529ba0f75c9eab38298cbbc1d365644633ad610c8bb4c82bf5d6f9eed300df18d84f0244965c8df4df535f6e0e63dea6fe49e439f97aad7c74acc77887a35aeb46e4f7cb648dd53b96350913d14c97106a528df78de8166c37dfc175eb8cd290b4eeafe4c0347c2f691e41d30e0aceb7eb25d58aa81b05fe8f5300a1e38dee028cdfe196210fbe6aa2cdcd1b426aafcf3bf086e1d34f930a1bb9ee32b575f4ae3b82ef52f44d86543539c358a7079b18c7178635fc1fb54f7ed6b51ad603293d21523f62b4d1978ac4014d507268c830c621995daf0a8937a7a820ef6ddba82a53503bd8c2e48d0863ecdfc28c4fe15029337e1c7caf29e5dc05d447"/>
</OpaqueObject>
</RequestPayload>
</BatchItem>
</RequestMessage>
|
|
0029
0030
0031
0032
0033
0034
0035
0036
0037
0038
0039
0040
0041
0042
0043
0044
0045
|
<ResponseMessage>
<ResponseHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="0"/>
</ProtocolVersion>
<TimeStamp type="DateTime" value="2012-04-27T08:12:24+00:00"/>
<BatchCount type="Integer"
value="1"/>
</ResponseHeader>
<BatchItem>
<Operation type="Enumeration" value="Register"/>
<ResultStatus type="Enumeration"
value="Success"/>
<ResponsePayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</ResponsePayload>
</BatchItem>
</ResponseMessage>
|
|
0046
0047
0048
0049
0050
0051
0052
0053
0054
0055
0056
0057
0058
0059
0060
|
# TIME 1
<RequestMessage>
<RequestHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="0"/>
</ProtocolVersion>
<BatchCount type="Integer" value="1"/>
</RequestHeader>
<BatchItem>
<Operation type="Enumeration" value="Destroy"/>
<RequestPayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</RequestPayload>
</BatchItem>
</RequestMessage>
|
|
0061
0062
0063
0064
0065
0066
0067
0068
0069
0070
0071
0072
0073
0074
0075
0076
0077
|
<ResponseMessage>
<ResponseHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="0"/>
</ProtocolVersion>
<TimeStamp type="DateTime" value="2012-04-27T08:12:24+00:00"/>
<BatchCount type="Integer"
value="1"/>
</ResponseHeader>
<BatchItem>
<Operation type="Enumeration" value="Destroy"/>
<ResultStatus type="Enumeration"
value="Success"/>
<ResponsePayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</ResponsePayload>
</BatchItem>
</ResponseMessage>
|
This section documents the test cases that a client or
server conformant to the Opaque Managed Object Store Profile SHALL support
under KMIP Specification 1.1.
Register larger (>10k) opaque object
|
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
|
# TIME 0
<RequestMessage>
<RequestHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="1"/>
</ProtocolVersion>
<BatchCount type="Integer" value="1"/>
</RequestHeader>
<BatchItem>
<Operation type="Enumeration" value="Register"/>
<RequestPayload>
<ObjectType type="Enumeration" value="OpaqueObject"/>
<TemplateAttribute>
<Attribute>
<AttributeName type="TextString" value="Name"/>
<AttributeValue>
<NameValue type="TextString" value="OMOS-O-1-11"/>
<NameType type="Enumeration"
value="UninterpretedTextString"/>
</AttributeValue>
</Attribute>
</TemplateAttribute>
<OpaqueObject>
<OpaqueDataType type="Enumeration" value="0x80000001"/>
<OpaqueDataValue type="ByteString"
value="168392816fd71b3d1c5d9cecfacf61f4e396374ede655d9d15305d6a0a04e5f0beab1de8be60fb716de00456c0b4adaadd5e1f4e72879251dbf7d25ca9f81076daa0b6464ae989a76a6f6710ea9560a60b99cb4f697cd075cd799cb7dbcfffab4c2aba5a19529f14307f6d217b1c84114eab50855b623d2e2a7602cdd230778939cce2a03550b0e0c9a4ff7e0ad2af805a92bbe4a41ba3405565ca050c38c6d5b92d902c30544b1460e2360459ee2ef3376b66caf91e0e0980d12ea6c19b5623cf03ad065652cf247ee2be155deacfda3d96b35f21d2f97fe4fd28244dec67f61c32250f5fc93dc515c1b5c7004f212b7c1d60972f3aa0372789364a3a762f80fda1d58389ea3cb3d204db887b0db62623350d4ea7d1bfd91e6d522fab6942abe5ab9f76278e4cb280fed409268c2731552c8292829a47355852d5780388a4e13691f8ec654226ce52e213fff30b0b3de7ffb7444c7748f7e90dd893276d526a657bdf42ea588721788feb605e5d3443ebe0691be98af902a3d6a459f1e160df7dc3a7507b05a238d49c6d5ef6803ffb964cd813db90f549c2393fae94fcfc8c05ddb62a71bfc031074f4d32ada48491c970dedf57c139cb04c94112fcef3eec9fdd7487eecd1470741f780e0d9e99ba68e97945b7ab7970f8003f80ca9622c94192281c13380894dc1f6c6d88848ffe81fd994862d2c60db1b651dbf12a245d34fc0e2a1b7cf36428c1e481890607a4df45ea20619ea02946af0c7c41fc16bc620159871659c8105506fb0d4017921ea79ac082afad5cb9bf703a49ac79fd1f428fdca5a8f693990bfbca9640a44bf43e5786111f624369d1d33a08cd7247be07f9bad26e531a2f3f9aea66536682296348cf86291af9c2521bc6196747986d02b3a465dfbbe9468c3b364a8048441e32dc8ff190f0ad62b2c0f6a6d4aa715580b1fb2cab038560259981eee6f59f850c076c29507e9efd9cca183f5bd8a0a876820ed173f884f6a9773c8102859b59b286002147b86428c18537590ff9b3cbe3dd2f7607f2b7d84227c5d9ca6e6f272631672960f0da9c69d6b31eb499d50d724e3e3d4f0c98242438915de54f1a600acd13f9ce483c01dcd8c5d36a7cc57ead5f4066b849b8a5e00cc56019bebb2e8129a6481e9f4b234154808236538c500ccd597a273068dc442f3c12050050209538cb1ea3194a18278b55d589d34e7680f565ed411359eaddf12c0bdfe907b16377827d6ca46460d19f703c7b17fd3b7be9f45c162a34502f507673d304487e11c27c9827cbc9cc5e3992514aa6e62d3163e338af19e99fcddec6ee17f70af7c9644a297af3ec237619b8580bd20ae8ada4ce7dfe834711560b598f5aab65eac8fd2a8d66f574c79e4f19faa08dda5823ddc4f532f3053841dc52213dc147b325599a4b5969fa2642fb50c01030b14253d0f23fd34f663581e95da9bfb0e3f52a010b2f5911ff063ac2a826c94a8789445bc229a1ef1fe74fd8b5f672e8ffa671a5c69d19a4d7611c149cd5268d590788aa3e44e949beb46f38a8fa51a301824e88c220ae41ba4b036c672342c043ebc6db91035b70ae68d58f558a3a5d1a788a6694c4f74278a204743fae6d947b502e29552ba65507e91b684a3955aafb43530f02ccccaeded9a6d1f877da2470f36c26014653493c970613f25de9c21f0682062881de0fc6ce2712e6f924408e7d29d368c43ed198f14f5e947bb2f721084e6c22f750a6cd2400c49b9689e4e0f5d3d52005c5e42a6aa0ecdc237f7b1868b7e77bce2c0d8f160a061f0de6529967e82586fe854bc89ed68dc7d9ac521aa2f40e1c4c3835ad8c2881ec579975d4cf9d9beb69d0f2c4b4f1e69ace6da5b9f6e49801ac9e1c5922176e3c72b8f0b73629d457a10456d9c8f0ae56e40cb01f64ba0b49ea69f23728cffa532fd01b966ff31c30fedc9a52b7b0a5fe6a2e3bd53c87560cf74b12143696e52343317c408d8e13bdb1fbd2758aaa3cf8aa3fd229bb65a9e41228372889147470cee02ae4acb89d52e31f8da66543fc8a6c02a6b337ce10d0f41f464a44509c245476be1e5b11df8dbb867664cec0882beee6e21a022abcb89ded8a17cf6f17da33c094e42be30a3c070950ff300993abb40fac22f0ecf7d155c9261516796cb1de4c0d6bfc21e716b04d23dbb8b465708204a3b96af8e46042e8205e7df92b9e01c7794c94a5036b7f85fe0967515cc05ea460c7810c0c551d8fd94f7ad7d1a641e73a1471e9364bf4e2b4687c7700381d46d39a3159f486d0323de59c5f555d323e5c072fbfc0758e22aa6a1df04d13bf4bfe6632853424984d56d16ed61402a640c7e1b07d9439d1fdc2df147df02639575b50da6cd769cb367dbfe3316e03939e85880f8b19f2689d5504f25200560dd815fd4535a1b5f70c8332c95c9d292c75e971df28ec6ff6d70a52ad78d236a51ec4a12243a650285fbd6aa4632fab8fa56eb26f638855147d72efcdd8a0b4367122f8e2210d39ffc87ac29ab5c5f1226bea04693e0b5c671269d96ac0c665fbd4f5fdb04ffcd7b76f0f8c1960e7a47c88226d6bd360e4dd65d70ed687e2fea04822f7c8394007ee085a9362a35506696c44e531786472a3db4bddd2b63ae1a448d0442d11f28dfed4de000c820e40174e216d274ab1321be6f21d1e4eb7e22430c131b2050c1fcb9ebb2823dd6fb4f4972ea4167795f911fb8a3c7f14ecf71a0e675657263c2f4b5eb72369d9d2d457999dc15392ccc10d98308830dd9b64d95427381afa9549c5df5081de88849126197154968d96797c573901e80bc638bc4126c01dea36a56c1afe01021a21a776f6b4e375dd42156cce98998bd3036401550b501fac4ad653bcf098db8f6d9ef76429a60137e0f507c67b57ddf829c5ed88f4369a6cc7287683fa225515697cc2e43ffd8108e7f1564736d043b6323ae17bda3031fab7712f886ac12afbeb2686700c1133017f64363293f93ab3c4e096aff76751377e5b6e5ead512a2f3d36635fcac28bf7fcf5c565bcf51bf650e7e3c80194a34b7348e7517fd4301f9986cdcbbe27392291da368ca699d90bca1b49122b20649f6b95529a72ba8217546042cb975720b3c6e08ea2ed9faf23f975524a3857f5d20f76f6df0b5cf16fe7b054f4c996042728c8b41326f7edf94fe04b0c084762ecc7c604c3375d3e3f572afad8d27eb06a98a99e9af63c5ee3ed2b5d20cb910eb29596ccb8391f06c376083247fc940598bd3d888bc579a9496eba784dfea823a0a1a28cecc20951e4bef35596147f53d4957fa965e071d5a5c80b982ea26b6500b9a63e2a1c1196cde4deb61a0358ef822a0e00849e807b110d036d268480089e21d4f07ce43d9fcf233ec0e7044460410a6cc7254becfb27d31679a63e4285632d7477561e4af332f2cc622443f8a94e7f03a93c8ca4b10871a562ad9f6a00e9f70c273fd4bef730201d3bcd75e2bbfeac22d98c6667d7b8d0cb965b94d1be33c5329821a6292239ac93a896d7086e435c249c484a66bf002b1b99a2f633bc8fb9ffc8c7aeb4ed95301f4bc51441802ca28f56257e77efb556ea385e086c6e9c3fe901b9bfa034ef9a5202d29030e5e962635baf5b878cc2b7f7414e6b68fcfd26066084e936eed103a4073bca9cfb6a209251aa59fc6caead3faef33ed547d47876656a55cebb5cb6cba8b294081540f627f2235588f69eef2c4b029781a31a5884f20bd3699ff71a0726ee9a9e41caa19bd9ad50660dd9cda8852f2c555d1f4162e13ab0dfa63d6661f28d856838ef093286447c277aba2b4d05a6559f1f214bc73bed5f47e1e73465c58718904618ebcb16b6a3feb719c2f3ff4e5409d1aece9aca7bba3019d5def920e2b78512f74e44326d23a42f78b7eece89296ed9315d7bc097eace97dc3691aad6b3d7d79885d4e1def2800e6f3e94685e66b234daeef3d2d6c638e961408892941cafed16ccdf523a91d2ae4b871250ed0b9b53e5e0e93837ca400f9d5f11030ef1536e39592a23ee10ec0f568cc373b1d65fe424cc9382fb653fb5f347acc6dab0998ee6f9f9d26bf93c6909d88fb0b0d05298c7424a7d30dc3f54b1bbb2b9d33903b3faf133f21aa7234917269fefe6a2691526dfa7647bce8758598524c2532b695eb174ab4c08405a7532374167317eef95d7b2044e6409e2bdc70b9463b5a50c8647692b334904e5906405766c7f3f6fb5e07786c6fa37c2e8d96dcf0a3b65ed4d4f031b627920586b8c23092dcc1f99e6267ef25b0a75a00a48070a92032e9ed0a58eb7adc4b4571e85165b50449b4441416e550ecd612b55ef2cc6a3f8036351b00db614c248c11a1a8b7d945ed719f2fb0d0855cea744cb637e3e709a55274d9f41b9a9026a857c1c6c30257391e5b510cf06254fcb85c3992634a50eba9f58974de34dfa65dceca9ac467b4efa9706fb5dc196d277f07cd46e7431b785591c39387f6671542d9ab5caf9ef97aa43f7b46bb75a4fc8661b14513f13609bae9722f3b4b0d03d039e5e1ae3cddd29e729e6afa7ab605be00f7dae13d874349affad716385139c14f90296b2bab2bef5ac8a1086660701bd4b574e9c3cc1b5999a3f5eb67ec10c1ab025a4d621955010e44dca1a08032f12478c65755678da26e411890e6bcddb30c1bce42d40d036c390e6a8a63ecbd6b1b6ca3be45d4dcc82bb8c4b3c05a66ef039c2c22f733a6531a5cf8374db73ab67b4c50d4efd000e6346f345f1c469813505683f67ebb120c9ce5f96d1b3476ddc8e320dde1ca0e0ccfba2f2922195b4f73defcd2dc45b7f72a5f2cba86fc0b67587d317944acc3cee8f7461571137690bca0c62f4df293348c1cb86e41abf55d90acdb1862bac1378b1f3e04b3d0a3fa8a28115b2ec08103eb70e0bbd8c9c6a1b6597d06e14dab1b20b6a60020f061c1ab5380e400b27a583c22ea32a7b481dd855c2a26096020c40e0d0f20ed75052afb7f6bebe83a794ea0662e149306d0b03083297ef6ac920a065805d96232715ca161271c33370a71835bbe31b722b04168a20012953f425ced6ca60fe9926a510b879376508008c8bcb1af5a97064c2309c809ff153ff242267b44dd0075e4bd9e0ece58516cc41fda213f21a6cb40ad2f4395ccd100f985eaaada93cf9e3964e9ca23f6f9b5ae8d72a40a4d534ea6fea998a2726615c72d86757a6c5946c45871850709855d5bd3c1683b476e21fd3afdffe94eca83e48c283fc8462f1a618481676ff987e12fc63a19feafcf54aa9754cc39511c2750eb0ed6ec6e059810d3f0a49f7fd47830450b1d26d4db70a18d1d76e8877dc24e1e89bb448cdf24d5664b2228bd4c8bfb6f344ac1f1c3f535ad6dc77641bad188d67eedbe34b42389708d6007bdd591a5dec58663f0c75c956d7e8dd1552639d8313a5ddbf10aefbd2f1f153971f0ad1ed0a767c9ab66d4deffb1271eb4760d280899cdafec6de7d13cd298cddf4e8450be0e7d63c9afa51139c9cc3c780557f659e37301e0f268ff4811f8c04cd65adf3d676cee7e9c3fac68d792edb1af47edd08460fec81ae29dbeb3c3b4fe17f87be656102b4e654b67bff33b4e60e04171d8cd0795d58a93914df26b6f6bcd94838e9f563e19202d2ebd12544ac97a15ba32db7d8f449f36d512622e4054364c1e68df0f48688a6f9d66f3caca4651a4811d6562ebcb624e22d7bd8468e7aa4451883b9e5421c4b849e07a52d5c4e686f19ebae0c75df57375d2f56bde33c6c9715a4cf6f1272a0f18e88ff99eb9f79b5e48a20e1bd99a719b724c96d2c8ca07fb1645aed79289dde7586aa9a8e219e02872c1f40c0107a2290ea950b3893273358f02301594d918a527555a8018786d357dfb348ce626c17cafb9b88905678b120a8d6c54a9840e99dfb56d22e12ff7f09c2883058cfa106b54a289e02be522a0a4d19178fd772383ed9cfe3433bcd20c4f512d01d44ee734c71acae9785fef664de661535d1c1e4ae59bbb702727d07567c4266023072e3ec300322300dc601f6de9cb009bd9df68d0b54f4adb2951af99b8d45d157d78b9bb908c079509ba3d3680e4cc4ed1ce990ba9a261cdd1064a7755c18b67293350d2cc57a28ef1b9432326483b9c2020a1a7bf07178528b7fcc0072eeb31019ba0cac461a55c46f7a30dd1554e2861ceb98ca52d0106c09bbfd6e2d9c2061d797199846119294f293679740bfb06626974f93382e9e854df29bc8aef4dc3bc1122dbabd3cc1ae646bafa5d5b5824fffc22860e737419800f8037f3d0ac05bd041345e94e597817ff15a5f2332b697a97507954a664eed19e925daba33c575773ebdbaf42babf42d17073e1d595fb612519ccc560451c66c82cf2f2b220d58fd6d666a089b843f993c784e4b07027ccbb72437a69ce1b8e34050b254d3f9d195750edfaf92f5cff1140ea202cbc489b32ab4d78f6cbc7205cdd9ec64db4dba9477e141f1bb54aaf929e9fb766711eaa7b802818e03c2576bc5fbd54a8daf64fa8907a50b81db4b53f87ad894342ba54304ff013586aadba30f40f8c62c127287f2ef26303fbb0be86f581f51881686d3ee672a567c887c88122eddf9ea2e75ce4788b8b07b7bf30bd68ab766d336d3de479d3b7b738873b53fb367af51e26e098d9f60b2ff9eb364db4847adb19f45a6644298dda56b1fa62857a55aeed02fd4b7ad11dabf45cc94b92e797c4d8e53646da4847e0f84372466d6503cea856f000274afd00fd97b69d185fc14ab25a5cb9d897b85f5e22f8f881b113b60e89b05f2717fe29a8c3eccba97755e827ef02cd95ad52a1de25ae6deefa3f150c61f39256f3dc2959c4f0ad94ccab130c9f69642534484ba82733bfc102aaffbd86103975cfb8146df3ffe895e462fabac9ab8e49ba900e7ddb63fd32e2b6487fe52d1e2c42ec16da300214992fc45dbeb39474e2edce031c153c0ff88d970c71707bde5eeb5a8cec19b79558d8cf6ba7d1fd6c6e6361fc4f4245850166cb3ed529ba0f75c9eab38298cbbc1d365644633ad610c8bb4c82bf5d6f9eed300df18d84f0244965c8df4df535f6e0e63dea6fe49e439f97aad7c74acc77887a35aeb46e4f7cb648dd53b96350913d14c97106a528df78de8166c37dfc175eb8cd290b4eeafe4c0347c2f691e41d30e0aceb7eb25d58aa81b05fe8f5300a1e38dee028cdfe196210fbe6aa2cdcd1b426aafcf3bf086e1d34f930a1bb9ee32b575f4ae3b82ef52f44d86543539c358a7079b18c7178635fc1fb54f7ed6b51ad603293d21523f62b4d1978ac4014d507268c830c621995daf0a8937a7a820ef6ddba82a53503bd8c2e48d0863ecdfc28c4fe15029337e1c7caf29e5dc05d447"/>
</OpaqueObject>
</RequestPayload>
</BatchItem>
</RequestMessage>
|
|
0029
0030
0031
0032
0033
0034
0035
0036
0037
0038
0039
0040
0041
0042
0043
0044
0045
|
<ResponseMessage>
<ResponseHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="1"/>
</ProtocolVersion>
<TimeStamp type="DateTime" value="2012-04-27T08:12:24+00:00"/>
<BatchCount type="Integer"
value="1"/>
</ResponseHeader>
<BatchItem>
<Operation type="Enumeration" value="Register"/>
<ResultStatus type="Enumeration"
value="Success"/>
<ResponsePayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</ResponsePayload>
</BatchItem>
</ResponseMessage>
|
|
0046
0047
0048
0049
0050
0051
0052
0053
0054
0055
0056
0057
0058
0059
0060
|
# TIME 1
<RequestMessage>
<RequestHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="1"/>
</ProtocolVersion>
<BatchCount type="Integer" value="1"/>
</RequestHeader>
<BatchItem>
<Operation type="Enumeration" value="Destroy"/>
<RequestPayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</RequestPayload>
</BatchItem>
</RequestMessage>
|
|
0061
0062
0063
0064
0065
0066
0067
0068
0069
0070
0071
0072
0073
0074
0075
0076
0077
|
<ResponseMessage>
<ResponseHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="1"/>
</ProtocolVersion>
<TimeStamp type="DateTime" value="2012-04-27T08:12:24+00:00"/>
<BatchCount type="Integer"
value="1"/>
</ResponseHeader>
<BatchItem>
<Operation type="Enumeration" value="Destroy"/>
<ResultStatus type="Enumeration"
value="Success"/>
<ResponsePayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</ResponsePayload>
</BatchItem>
</ResponseMessage>
|
Register larger (>10k) opaque object
|
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
|
# TIME 0
<RequestMessage>
<RequestHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="2"/>
</ProtocolVersion>
<BatchCount type="Integer" value="1"/>
</RequestHeader>
<BatchItem>
<Operation type="Enumeration" value="Register"/>
<RequestPayload>
<ObjectType type="Enumeration" value="OpaqueObject"/>
<TemplateAttribute>
<Attribute>
<AttributeName type="TextString" value="Name"/>
<AttributeValue>
<NameValue type="TextString" value="OMOS-O-1-12"/>
<NameType type="Enumeration"
value="UninterpretedTextString"/>
</AttributeValue>
</Attribute>
</TemplateAttribute>
<OpaqueObject>
<OpaqueDataType type="Enumeration" value="0x80000001"/>
<OpaqueDataValue type="ByteString"
value="168392816fd71b3d1c5d9cecfacf61f4e396374ede655d9d15305d6a0a04e5f0beab1de8be60fb716de00456c0b4adaadd5e1f4e72879251dbf7d25ca9f81076daa0b6464ae989a76a6f6710ea9560a60b99cb4f697cd075cd799cb7dbcfffab4c2aba5a19529f14307f6d217b1c84114eab50855b623d2e2a7602cdd230778939cce2a03550b0e0c9a4ff7e0ad2af805a92bbe4a41ba3405565ca050c38c6d5b92d902c30544b1460e2360459ee2ef3376b66caf91e0e0980d12ea6c19b5623cf03ad065652cf247ee2be155deacfda3d96b35f21d2f97fe4fd28244dec67f61c32250f5fc93dc515c1b5c7004f212b7c1d60972f3aa0372789364a3a762f80fda1d58389ea3cb3d204db887b0db62623350d4ea7d1bfd91e6d522fab6942abe5ab9f76278e4cb280fed409268c2731552c8292829a47355852d5780388a4e13691f8ec654226ce52e213fff30b0b3de7ffb7444c7748f7e90dd893276d526a657bdf42ea588721788feb605e5d3443ebe0691be98af902a3d6a459f1e160df7dc3a7507b05a238d49c6d5ef6803ffb964cd813db90f549c2393fae94fcfc8c05ddb62a71bfc031074f4d32ada48491c970dedf57c139cb04c94112fcef3eec9fdd7487eecd1470741f780e0d9e99ba68e97945b7ab7970f8003f80ca9622c94192281c13380894dc1f6c6d88848ffe81fd994862d2c60db1b651dbf12a245d34fc0e2a1b7cf36428c1e481890607a4df45ea20619ea02946af0c7c41fc16bc620159871659c8105506fb0d4017921ea79ac082afad5cb9bf703a49ac79fd1f428fdca5a8f693990bfbca9640a44bf43e5786111f624369d1d33a08cd7247be07f9bad26e531a2f3f9aea66536682296348cf86291af9c2521bc6196747986d02b3a465dfbbe9468c3b364a8048441e32dc8ff190f0ad62b2c0f6a6d4aa715580b1fb2cab038560259981eee6f59f850c076c29507e9efd9cca183f5bd8a0a876820ed173f884f6a9773c8102859b59b286002147b86428c18537590ff9b3cbe3dd2f7607f2b7d84227c5d9ca6e6f272631672960f0da9c69d6b31eb499d50d724e3e3d4f0c98242438915de54f1a600acd13f9ce483c01dcd8c5d36a7cc57ead5f4066b849b8a5e00cc56019bebb2e8129a6481e9f4b234154808236538c500ccd597a273068dc442f3c12050050209538cb1ea3194a18278b55d589d34e7680f565ed411359eaddf12c0bdfe907b16377827d6ca46460d19f703c7b17fd3b7be9f45c162a34502f507673d304487e11c27c9827cbc9cc5e3992514aa6e62d3163e338af19e99fcddec6ee17f70af7c9644a297af3ec237619b8580bd20ae8ada4ce7dfe834711560b598f5aab65eac8fd2a8d66f574c79e4f19faa08dda5823ddc4f532f3053841dc52213dc147b325599a4b5969fa2642fb50c01030b14253d0f23fd34f663581e95da9bfb0e3f52a010b2f5911ff063ac2a826c94a8789445bc229a1ef1fe74fd8b5f672e8ffa671a5c69d19a4d7611c149cd5268d590788aa3e44e949beb46f38a8fa51a301824e88c220ae41ba4b036c672342c043ebc6db91035b70ae68d58f558a3a5d1a788a6694c4f74278a204743fae6d947b502e29552ba65507e91b684a3955aafb43530f02ccccaeded9a6d1f877da2470f36c26014653493c970613f25de9c21f0682062881de0fc6ce2712e6f924408e7d29d368c43ed198f14f5e947bb2f721084e6c22f750a6cd2400c49b9689e4e0f5d3d52005c5e42a6aa0ecdc237f7b1868b7e77bce2c0d8f160a061f0de6529967e82586fe854bc89ed68dc7d9ac521aa2f40e1c4c3835ad8c2881ec579975d4cf9d9beb69d0f2c4b4f1e69ace6da5b9f6e49801ac9e1c5922176e3c72b8f0b73629d457a10456d9c8f0ae56e40cb01f64ba0b49ea69f23728cffa532fd01b966ff31c30fedc9a52b7b0a5fe6a2e3bd53c87560cf74b12143696e52343317c408d8e13bdb1fbd2758aaa3cf8aa3fd229bb65a9e41228372889147470cee02ae4acb89d52e31f8da66543fc8a6c02a6b337ce10d0f41f464a44509c245476be1e5b11df8dbb867664cec0882beee6e21a022abcb89ded8a17cf6f17da33c094e42be30a3c070950ff300993abb40fac22f0ecf7d155c9261516796cb1de4c0d6bfc21e716b04d23dbb8b465708204a3b96af8e46042e8205e7df92b9e01c7794c94a5036b7f85fe0967515cc05ea460c7810c0c551d8fd94f7ad7d1a641e73a1471e9364bf4e2b4687c7700381d46d39a3159f486d0323de59c5f555d323e5c072fbfc0758e22aa6a1df04d13bf4bfe6632853424984d56d16ed61402a640c7e1b07d9439d1fdc2df147df02639575b50da6cd769cb367dbfe3316e03939e85880f8b19f2689d5504f25200560dd815fd4535a1b5f70c8332c95c9d292c75e971df28ec6ff6d70a52ad78d236a51ec4a12243a650285fbd6aa4632fab8fa56eb26f638855147d72efcdd8a0b4367122f8e2210d39ffc87ac29ab5c5f1226bea04693e0b5c671269d96ac0c665fbd4f5fdb04ffcd7b76f0f8c1960e7a47c88226d6bd360e4dd65d70ed687e2fea04822f7c8394007ee085a9362a35506696c44e531786472a3db4bddd2b63ae1a448d0442d11f28dfed4de000c820e40174e216d274ab1321be6f21d1e4eb7e22430c131b2050c1fcb9ebb2823dd6fb4f4972ea4167795f911fb8a3c7f14ecf71a0e675657263c2f4b5eb72369d9d2d457999dc15392ccc10d98308830dd9b64d95427381afa9549c5df5081de88849126197154968d96797c573901e80bc638bc4126c01dea36a56c1afe01021a21a776f6b4e375dd42156cce98998bd3036401550b501fac4ad653bcf098db8f6d9ef76429a60137e0f507c67b57ddf829c5ed88f4369a6cc7287683fa225515697cc2e43ffd8108e7f1564736d043b6323ae17bda3031fab7712f886ac12afbeb2686700c1133017f64363293f93ab3c4e096aff76751377e5b6e5ead512a2f3d36635fcac28bf7fcf5c565bcf51bf650e7e3c80194a34b7348e7517fd4301f9986cdcbbe27392291da368ca699d90bca1b49122b20649f6b95529a72ba8217546042cb975720b3c6e08ea2ed9faf23f975524a3857f5d20f76f6df0b5cf16fe7b054f4c996042728c8b41326f7edf94fe04b0c084762ecc7c604c3375d3e3f572afad8d27eb06a98a99e9af63c5ee3ed2b5d20cb910eb29596ccb8391f06c376083247fc940598bd3d888bc579a9496eba784dfea823a0a1a28cecc20951e4bef35596147f53d4957fa965e071d5a5c80b982ea26b6500b9a63e2a1c1196cde4deb61a0358ef822a0e00849e807b110d036d268480089e21d4f07ce43d9fcf233ec0e7044460410a6cc7254becfb27d31679a63e4285632d7477561e4af332f2cc622443f8a94e7f03a93c8ca4b10871a562ad9f6a00e9f70c273fd4bef730201d3bcd75e2bbfeac22d98c6667d7b8d0cb965b94d1be33c5329821a6292239ac93a896d7086e435c249c484a66bf002b1b99a2f633bc8fb9ffc8c7aeb4ed95301f4bc51441802ca28f56257e77efb556ea385e086c6e9c3fe901b9bfa034ef9a5202d29030e5e962635baf5b878cc2b7f7414e6b68fcfd26066084e936eed103a4073bca9cfb6a209251aa59fc6caead3faef33ed547d47876656a55cebb5cb6cba8b294081540f627f2235588f69eef2c4b029781a31a5884f20bd3699ff71a0726ee9a9e41caa19bd9ad50660dd9cda8852f2c555d1f4162e13ab0dfa63d6661f28d856838ef093286447c277aba2b4d05a6559f1f214bc73bed5f47e1e73465c58718904618ebcb16b6a3feb719c2f3ff4e5409d1aece9aca7bba3019d5def920e2b78512f74e44326d23a42f78b7eece89296ed9315d7bc097eace97dc3691aad6b3d7d79885d4e1def2800e6f3e94685e66b234daeef3d2d6c638e961408892941cafed16ccdf523a91d2ae4b871250ed0b9b53e5e0e93837ca400f9d5f11030ef1536e39592a23ee10ec0f568cc373b1d65fe424cc9382fb653fb5f347acc6dab0998ee6f9f9d26bf93c6909d88fb0b0d05298c7424a7d30dc3f54b1bbb2b9d33903b3faf133f21aa7234917269fefe6a2691526dfa7647bce8758598524c2532b695eb174ab4c08405a7532374167317eef95d7b2044e6409e2bdc70b9463b5a50c8647692b334904e5906405766c7f3f6fb5e07786c6fa37c2e8d96dcf0a3b65ed4d4f031b627920586b8c23092dcc1f99e6267ef25b0a75a00a48070a92032e9ed0a58eb7adc4b4571e85165b50449b4441416e550ecd612b55ef2cc6a3f8036351b00db614c248c11a1a8b7d945ed719f2fb0d0855cea744cb637e3e709a55274d9f41b9a9026a857c1c6c30257391e5b510cf06254fcb85c3992634a50eba9f58974de34dfa65dceca9ac467b4efa9706fb5dc196d277f07cd46e7431b785591c39387f6671542d9ab5caf9ef97aa43f7b46bb75a4fc8661b14513f13609bae9722f3b4b0d03d039e5e1ae3cddd29e729e6afa7ab605be00f7dae13d874349affad716385139c14f90296b2bab2bef5ac8a1086660701bd4b574e9c3cc1b5999a3f5eb67ec10c1ab025a4d621955010e44dca1a08032f12478c65755678da26e411890e6bcddb30c1bce42d40d036c390e6a8a63ecbd6b1b6ca3be45d4dcc82bb8c4b3c05a66ef039c2c22f733a6531a5cf8374db73ab67b4c50d4efd000e6346f345f1c469813505683f67ebb120c9ce5f96d1b3476ddc8e320dde1ca0e0ccfba2f2922195b4f73defcd2dc45b7f72a5f2cba86fc0b67587d317944acc3cee8f7461571137690bca0c62f4df293348c1cb86e41abf55d90acdb1862bac1378b1f3e04b3d0a3fa8a28115b2ec08103eb70e0bbd8c9c6a1b6597d06e14dab1b20b6a60020f061c1ab5380e400b27a583c22ea32a7b481dd855c2a26096020c40e0d0f20ed75052afb7f6bebe83a794ea0662e149306d0b03083297ef6ac920a065805d96232715ca161271c33370a71835bbe31b722b04168a20012953f425ced6ca60fe9926a510b879376508008c8bcb1af5a97064c2309c809ff153ff242267b44dd0075e4bd9e0ece58516cc41fda213f21a6cb40ad2f4395ccd100f985eaaada93cf9e3964e9ca23f6f9b5ae8d72a40a4d534ea6fea998a2726615c72d86757a6c5946c45871850709855d5bd3c1683b476e21fd3afdffe94eca83e48c283fc8462f1a618481676ff987e12fc63a19feafcf54aa9754cc39511c2750eb0ed6ec6e059810d3f0a49f7fd47830450b1d26d4db70a18d1d76e8877dc24e1e89bb448cdf24d5664b2228bd4c8bfb6f344ac1f1c3f535ad6dc77641bad188d67eedbe34b42389708d6007bdd591a5dec58663f0c75c956d7e8dd1552639d8313a5ddbf10aefbd2f1f153971f0ad1ed0a767c9ab66d4deffb1271eb4760d280899cdafec6de7d13cd298cddf4e8450be0e7d63c9afa51139c9cc3c780557f659e37301e0f268ff4811f8c04cd65adf3d676cee7e9c3fac68d792edb1af47edd08460fec81ae29dbeb3c3b4fe17f87be656102b4e654b67bff33b4e60e04171d8cd0795d58a93914df26b6f6bcd94838e9f563e19202d2ebd12544ac97a15ba32db7d8f449f36d512622e4054364c1e68df0f48688a6f9d66f3caca4651a4811d6562ebcb624e22d7bd8468e7aa4451883b9e5421c4b849e07a52d5c4e686f19ebae0c75df57375d2f56bde33c6c9715a4cf6f1272a0f18e88ff99eb9f79b5e48a20e1bd99a719b724c96d2c8ca07fb1645aed79289dde7586aa9a8e219e02872c1f40c0107a2290ea950b3893273358f02301594d918a527555a8018786d357dfb348ce626c17cafb9b88905678b120a8d6c54a9840e99dfb56d22e12ff7f09c2883058cfa106b54a289e02be522a0a4d19178fd772383ed9cfe3433bcd20c4f512d01d44ee734c71acae9785fef664de661535d1c1e4ae59bbb702727d07567c4266023072e3ec300322300dc601f6de9cb009bd9df68d0b54f4adb2951af99b8d45d157d78b9bb908c079509ba3d3680e4cc4ed1ce990ba9a261cdd1064a7755c18b67293350d2cc57a28ef1b9432326483b9c2020a1a7bf07178528b7fcc0072eeb31019ba0cac461a55c46f7a30dd1554e2861ceb98ca52d0106c09bbfd6e2d9c2061d797199846119294f293679740bfb06626974f93382e9e854df29bc8aef4dc3bc1122dbabd3cc1ae646bafa5d5b5824fffc22860e737419800f8037f3d0ac05bd041345e94e597817ff15a5f2332b697a97507954a664eed19e925daba33c575773ebdbaf42babf42d17073e1d595fb612519ccc560451c66c82cf2f2b220d58fd6d666a089b843f993c784e4b07027ccbb72437a69ce1b8e34050b254d3f9d195750edfaf92f5cff1140ea202cbc489b32ab4d78f6cbc7205cdd9ec64db4dba9477e141f1bb54aaf929e9fb766711eaa7b802818e03c2576bc5fbd54a8daf64fa8907a50b81db4b53f87ad894342ba54304ff013586aadba30f40f8c62c127287f2ef26303fbb0be86f581f51881686d3ee672a567c887c88122eddf9ea2e75ce4788b8b07b7bf30bd68ab766d336d3de479d3b7b738873b53fb367af51e26e098d9f60b2ff9eb364db4847adb19f45a6644298dda56b1fa62857a55aeed02fd4b7ad11dabf45cc94b92e797c4d8e53646da4847e0f84372466d6503cea856f000274afd00fd97b69d185fc14ab25a5cb9d897b85f5e22f8f881b113b60e89b05f2717fe29a8c3eccba97755e827ef02cd95ad52a1de25ae6deefa3f150c61f39256f3dc2959c4f0ad94ccab130c9f69642534484ba82733bfc102aaffbd86103975cfb8146df3ffe895e462fabac9ab8e49ba900e7ddb63fd32e2b6487fe52d1e2c42ec16da300214992fc45dbeb39474e2edce031c153c0ff88d970c71707bde5eeb5a8cec19b79558d8cf6ba7d1fd6c6e6361fc4f4245850166cb3ed529ba0f75c9eab38298cbbc1d365644633ad610c8bb4c82bf5d6f9eed300df18d84f0244965c8df4df535f6e0e63dea6fe49e439f97aad7c74acc77887a35aeb46e4f7cb648dd53b96350913d14c97106a528df78de8166c37dfc175eb8cd290b4eeafe4c0347c2f691e41d30e0aceb7eb25d58aa81b05fe8f5300a1e38dee028cdfe196210fbe6aa2cdcd1b426aafcf3bf086e1d34f930a1bb9ee32b575f4ae3b82ef52f44d86543539c358a7079b18c7178635fc1fb54f7ed6b51ad603293d21523f62b4d1978ac4014d507268c830c621995daf0a8937a7a820ef6ddba82a53503bd8c2e48d0863ecdfc28c4fe15029337e1c7caf29e5dc05d447"/>
</OpaqueObject>
</RequestPayload>
</BatchItem>
</RequestMessage>
|
|
0029
0030
0031
0032
0033
0034
0035
0036
0037
0038
0039
0040
0041
0042
0043
0044
0045
|
<ResponseMessage>
<ResponseHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="2"/>
</ProtocolVersion>
<TimeStamp type="DateTime" value="2012-04-27T08:12:24+00:00"/>
<BatchCount type="Integer"
value="1"/>
</ResponseHeader>
<BatchItem>
<Operation type="Enumeration" value="Register"/>
<ResultStatus type="Enumeration"
value="Success"/>
<ResponsePayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</ResponsePayload>
</BatchItem>
</ResponseMessage>
|
|
0046
0047
0048
0049
0050
0051
0052
0053
0054
0055
0056
0057
0058
0059
0060
|
# TIME 1
<RequestMessage>
<RequestHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="2"/>
</ProtocolVersion>
<BatchCount type="Integer" value="1"/>
</RequestHeader>
<BatchItem>
<Operation type="Enumeration" value="Destroy"/>
<RequestPayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</RequestPayload>
</BatchItem>
</RequestMessage>
|
|
0061
0062
0063
0064
0065
0066
0067
0068
0069
0070
0071
0072
0073
0074
0075
0076
0077
|
<ResponseMessage>
<ResponseHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer"
value="2"/>
</ProtocolVersion>
<TimeStamp type="DateTime" value="2012-04-27T08:12:24+00:00"/>
<BatchCount type="Integer"
value="1"/>
</ResponseHeader>
<BatchItem>
<Operation type="Enumeration" value="Destroy"/>
<ResultStatus type="Enumeration"
value="Success"/>
<ResponsePayload>
<UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>
</ResponsePayload>
</BatchItem>
</ResponseMessage>
|
KMIP client implementations conformant to this profile:
- SHALL support the Authentication Suite conditions (2.1) and;
- SHALL support the Opaque Managed Object Store – Client conditions
(2.2) and;
- SHALL support all Mandatory Test Cases (3.1).
KMIP client implementations conformant to this profile:
- SHALL support the Authentication Suite conditions (2.1) and;
- SHALL support the Opaque Managed Object Store – Client conditions
(2.2) and;
- SHALL support all Mandatory Test Cases (3.2).
KMIP client implementations conformant to this profile:
- SHALL support the Authentication Suite conditions (2.1) and;
- SHALL support the Opaque Managed Object Store – Client conditions
(2.2) and;
- SHALL support all Mandatory Test Cases (3.3).
KMIP server implementations conformant to this profile:
- SHALL support the Authentication Suite conditions (2.1) and;
- SHALL support the Opaque Managed Object Store – Server conditions
(2.3) and;
- SHALL support all Mandatory Test Cases (3.1).
KMIP server implementations conformant to this profile:
- SHALL support the Authentication Suite conditions (2.1) and;
- SHALL support the Opaque Managed Object Store – Server conditions
(2.3) and;
- SHALL support all Mandatory Test Cases (3.2).
KMIP server implementations conformant to this profile:
- SHALL support the Authentication Suite conditions (2.1) and;
- SHALL support the Opaque Managed Object Store – Server conditions
(2.3) and;
- SHALL support all Mandatory Test Cases (3.3).
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.
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.
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
- 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 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.
|
|
Revision
|
Date
|
Editor
|
Changes Made
|
|
wd01
|
26-June-2013
|
Tim Hudson /
Bob Lockhart
|
Updated conformance wording style. Updated test case
style. Included test cases for 1.0, 1.1 and 1.2. Applied new OASIS template.
|
|
wd02
|
6-August-2013
|
Tim Hudson / Bob Lockhart
|
Updated to include Permitted Test Case Variations and
updated Test Cases based on July 2013 Interop
|
|
wd03
|
10-August-2013
|
Tim Hudson
|
Updated Permitted Test Case Variations
|
|
wd03a
|
24-October-2013
|
Tim Hudson
|
Editorial update to include VendorIdentification in the
list of allowed variations as per TC motion.
|
|
pr01update
|
11-June-2014
|
Tim Hudson
|
Updated following Public Review
|
