This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Key Management Interoperability Protocol Profiles Version 1.3. Edited by Tim Hudson and Robert Lockhart. Latest version: http://docs.oasis-open.org/kmip/profiles/v1.3/kmip-profiles-v1.3.html.
Key Management Interoperability Protocol Specification Version 1.3. Edited by Tony Cox and Kiran Thota. Latest version: http://docs.oasis-open.org/kmip/spec/v1.3/kmip-spec-v1.3.html.
Abstract: Describes a profile for KMIP clients and KMIP servers using post-quantum cryptography long
term security as recommended.
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.
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.
2.1 Authentication Suite ............................................................................................................................ 6
For normative definition of the elements of KMIP see the KMIP Specification [KMIP-SPEC] and the KMIP 2 Profiles [KMIP-PROF]. 3
Implementations conforming to this profile will allow users to switch to post-quantum cryptography: 4 cryptographic systems that are not merely secure for today but that should also remain secure long-term 5 against attacks by quantum computers. 6
Post-quantum cryptographic primitives include: 7
8
Encryption
SHOULD ChaCha20 (with 256-bit key)
MAY AES-256
Digital Signature SHOULD SPHINCS-256 (stateless)
SHOULD XMSS (statefull)
Key Exchange SHALL McEliece (with binary Goppa codes using length n = 6960, dimension k = 5413 and adding t = 119 errors).
Encryption with Authentication SHOULD ChaCha20Poly1305 (with 256-bit key)
MAY AES-256 (with 96 bit nonce in GCM)
Hashes SHOULD SHA3-384 or SHA3-512
MAY SHA-384 or SHA-512
9
1.1 Terminology 10
The key words “MUST”, “SHALL”, “SHOULD”, and “MAY” in this document are to be interpreted as 11 described in [RFC2119]. 12
1.2 Normative References 13
[CHACHA] D. J. Bernstein. ChaCha, a variant of Salsa20. https://cr.yp.to/chacha/chacha-14 20080128.pdf 15
[KMIP-SPEC] Key Management Interoperability Protocol Specification Version 1.3. Edited by 16 Tony Cox and Kiran Thota. Latest version: http://docs.oasis-17 open.org/kmip/spec/v1.3/kmip-spec-v1.3.html. 18
[KMIP-PROF] Key Management Interoperability Protocol Profiles Version 1.3. Edited by Tim 19 Hudson and Robert Lockhart. Latest version: http://docs.oasis-20 open.org/kmip/profiles/v1.3/kmip-profiles-v1.3.html. 21
[POLY1305] Daniel J. Bernstein. The Poly1305-AES Message-Authentication Code. In Henri 22 Gilbert and Helena Handschuh, editors, Fast Software Encryption: 12th 23 International Workshop, FSE 2005, Paris, France, February 21-23, 2005, 24 Revised Selected Papers, volume 3557 of Lecture Notes in Computer Science, 25 pages 32–49. Springer, 2005. 26
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 27 14, RFC 2119, March 1997, http://www.ietf.org/rfc/rfc2119.txt. 28
[RFC5246] Dierks, T. and E. Rescorla, The Transport Layer Security (TLS) Protocol Version 29 1.2, IETF RFC 5246, August 2008, http://www.ietf.org/rfc/rfc5246.txt. 30
[RFC8032] Josefsson, S. and Liusvaara, I, Edwards-Curve Digital Signature Algorithm 31 (EdDSA), IETF RFC 8032, January 2017, http://www.ietf.org/rfc/rfc8032.txt. 32
33
[SPHINCS] Daniel J. Bernstein, Daira Hopwood, Andreas Hülsing, Tanja Lange, Ruben 34 Niederhagen, Louiza Papachristodoulou, Michael Schneider, Peter Schwabe, 35 and Zooko Wilcox-O’Hearn. SPHINCS: Practical Stateless Hash-Based 36 Signatures. In Elisabeth Oswald and Marc Fischlin, editors, Advances in 37 Cryptology - EUROCRYPT 2015 - 34th Annual International Conference on the 38 Theory and Applications of Cryptographic Techniques, Sofia, Bulgaria, April 26-39 30, 2015, Proceedings, Part I, volume 9056 of Lecture Notes in Computer 40 Science, pages 368–397. Springer, 2015. 41
[XMSS] Johannes A. Buchmann, Erik Dahmen, and Andreas Hülsing. XMSS - A Practical 42 Forward Secure Signature Scheme Based on Minimal Security Assumptions. In 43 BoYin Yang, editor, Post-Quantum Cryptography - 4th International Workshop, 44 PQCrypto 2011, Taipei, Taiwan, November 29 - December 2, 2011. 45 Proceedings, volume 7071 of Lecture Notes in Computer Science, pages 117–46 129. Springer, 2011. 47 48
The Post-Quantum Cryptography Profile describes a KMIP client interacting with a KMIP server in a 50 manner that should also remain secure long-term against attacks by quantum computers, whilst providing 51 a more flexible set of options for handling known or suspected PQC vulnerabilities. 52
2.1 Authentication Suite 53
Implementations conformant to this profile SHALL use TLS to negotiate a mutually-authenticated 54 connection. 55
2.1.1 Protocols 56
Conformant KMIP clients and servers SHOULD support: 57
TLS v1.3 [RFC-PENDING] 58
Conformant KMIP clients and servers MAY support: 59
TLS v1.2 [RFC5246] 60
Conformant KMIP clients and servers SHALL NOT support: 61
Any other TLS or SSL protocol version 62
2.1.2 Cipher Suites 63
Conformant KMIP servers SHALL support the following cipher suites for TLSv1.3 if TLSv1.3 is supported: 64
TLS13-CHACHA20-POLY1305-SHA256 65
TLS13-AES-256-GCM-SHA384 66
Conformant KMIP servers SHALL support the following cipher suites for TLSv1.2 if TLSv1.2 is supported: 67
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 68
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 69
2.1.3 Client Authenticity 70
Conformant KMIP servers and clients SHALL handle client authenticity in accordance with section 3.1.3 71 of the Basic Authentication Suite [KMIP-PROF]. 72
2.1.4 KMIP Port Number 73
Conformant KMIP servers and clients SHALL handle the KMIP port number in in accordance with section 74 3.1.4 of the Basic Authentication Suite [KMIP-PROF]. 75
2.2 Post-Quantum Cryptography - Client 76
KMIP clients conformant to this profile under [KMIP-SPEC]: 77
1. SHALL conform to the Baseline Client (section 5.1) of [KMIP-PROF] 78
2. SHALL restrict use of the enumerated types listed in item 5 of the server list in section 2.3 to the 79 values noted against each item 80
3. MAY support any clause within [KMIP-SPEC] provided it does not conflict with any other clause 81 within this section 2.2. 82
4. MAY support extensions outside the scope of this standard (e.g., vendor extensions, 83 conformance clauses) that do not conflict with any KMIP requirements. 84
f. Key Format Type Enumeration [KMIP-SPEC] value: 134
i. Raw 135
ii. X.509 136
g. Digital Signature Algorithm Enumeration [KMIP-SPEC] value: 137
i. ECDSA with SHA384 (on P-384) 138
ii. Ed25519 with Ed25519 139
7. MAY support any clause within [KMIP-SPEC] provided it does not conflict with any other clause 140 within this section 2.3. 141
8. MAY support extensions outside the scope of this standard (e.g., vendor extensions, 142 conformance clauses) that do not conflict with any KMIP requirements. 143
The test cases define a number of request-response pairs for KMIP operations. Each test case is 145 provided in the XML format specified in [KMIP-PROF] intended to be both human-readable and usable by 146 automated tools. The time sequence (starting from 0) for each request-response pair is noted and line 147 numbers are provided for ease of cross-reference for a given test sequence. 148
Each test case has a unique label (the section name) which includes indication of mandatory (-M-) or 149 optional (-O-) status and the protocol version major and minor numbers as part of the identifier. 150
The test cases may depend on a specific configuration of a KMIP client and server being configured in a 151 manner consistent with the test case assumptions. 152
Where possible the flow of unique identifiers between tests, the date-time values, and other dynamic 153 items are indicated using symbolic identifiers – in actual request and response messages these dynamic 154 values will be filled in with valid values. 155
Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real 156 client or server system may vary as specified in section 4.2 157
3.1 Mandatory Post-Quantum Cryptography Test Cases - KMIP v2.0 158
This section documents the test cases that a client or server conformant to this profile SHALL support. 159
3.1.1 PQC-M-1-12 - Query 160
Perform a Query operation, querying the Operations and Objects supported by the server, and get a 161 successful response. 162
The specific list of operations and object types returned in the response MAY vary. 163
The TLS protocol version and cipher suite SHALL be as specified in section 2.1 164
Perform a Create operation, stating the period the key must be able to offer protection (Protection Period) 167 and the relative sensitivity of the information (Protection Type). 168
The specific list of operations and object types returned in the response MAY vary. 169
The TLS protocol version and cipher suite SHALL be as specified in section 2.1 170
KMIP client implementations conformant to this profile: 175
1. SHALL support the Authentication Suite conditions as specified in Section 2.1 of this profile. 176
2. SHALL support the conditions as specified in Section 2.2 of this profile. 177
3. SHALL support one or more of the Mandatory Post-Quantum Cryptography Test Cases - KMIP v 178 (3.1) 179
4.2 Post-Quantum Cryptography Server KMIP V2.0 Profile 180
Conformance 181
KMIP server implementations conformant to this profile: 182
1. SHALL support the Authentication Suite conditions as specified in Section 2.1 of this profile. 183
2. SHALL support the conditions as specified in Section 2.3 of this profile. 184
3. SHALL support all the Mandatory Post-Quantum Cryptography Test Cases - KMIP v (3.1) 185
4.3 Permitted Test Case Variations 186
Conformant KMIP servers and clients SHALL handle permitted test case variations in accordance with 187 section 4.1 Permitted Test Case Variations of [KMIP-PROF]. 188