kmip-comment

Dear OASIS Members and Interested Parties:

OASIS and the OASIS Key Management Interoperability Protocol (KMIP) TC are pleased to announce that the Key Management Interoperability Protocol Usage Guide Version 3.0 is now available for public review and comment.

The Usage Guide is a Committee Note for developers and architects designing systems and applications that interoperate using the KMIP specification. It explains the assumptions behind the protocol and describes how KMIP functionality is used in practice, giving implementers guidance to use alongside the specification. This is the first public review of the Usage Guide at Version 3.0.

The document and all related files are available here:

Key Management Interoperability Protocol Usage Guide Version 3.0
Committee Note Draft 01, 18 June 2026

• Editable source (Authoritative): kmip-ug-v3.0-cnd01.docx
• HTML: kmip-ug-v3.0-cnd01.html
• PDF: kmip-ug-v3.0-cnd01.pdf
• Complete package (ZIP): kmip-ug-v3.0-cnd01.zip

How to Provide Feedback

OASIS and the KMIP TC value your feedback. We solicit input from developers, users and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work.

The public review is now open and ends 15 August 2026 at 23:59 UTC.

Comments from TC members should be sent to the TC's mailing list. Comments may be submitted by any other person through the project's Comment Facility.

Comments submitted by non-members for this work product are publicly archived and can be viewed by using the link above and clicking on the "Discussions" tab. Please note that you must log in or create a free account to see the material. Comments submitted by any other means cannot be accepted.

Please contact the TC Administrator (tc-admin@oasis-open.org) with any questions on how to submit a comment.

All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review, we call your attention to the OASIS IPR Policy applicable especially to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification.

OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work.

Additional references:

• KMIP TC public home page: www.oasis-open.org/committees/kmip/
• OASIS IPR Policy: www.oasis-open.org/policies-guidelines/ipr/
• KMIP TC IPR Policy page: www.oasis-open.org/committees/kmip/ipr.php

------------------------------
Michael Coletta
Current
OASIS Contractors
------------------------------

Hello, some notes from my side

1. Pages 2 and 6, plus references

The comment paragraph on page 2 appears twice, with the second copy running into the previous sentence. Page 6 still says "remove this note before publication." Also, the RFC 4210 entry calls it RFC 2510, the RFC 4880 URL ends in "txtt," and the revision history has "Editoral."

2. Section 2.2.1.2 – Device Credential

Serial numbers, MAC addresses and machine IDs are identifiers, not proof of identity. If the server trusts them on their own, one device can impersonate another. This needs a secret, client certificate or a trusted assertion from the proxy.

3. Section 3.32.2 – Stateful Cryptographic Operations

The Correlation Value can be associated with a source address or TLS session, but neither is a stable client identity. It should be tied to the authenticated client and authorization checked again for each part. The value also needs to be hard to guess and expire after use.

4. Section 3.56 – Post-Quantum Cryptography

A few references need updating: "NIST publish standards" should be "published," the FIPS 204 link appears twice, and ECDHE-MLKEM still points to draft 03. Linking to the current Datatracker entry would avoid tying the guide to an old draft.

5. Section 4.8 – Cryptographic Erasure

Destroying a key on the KMIP server only erases the server's copy. It doesn't remove copies already returned to clients, and Notify doesn't prove that the client deleted anything. The erasure claim should be limited to storage controlled by the server unless deletion elsewhere is confirmed.

6. Section 4.10 – Key Replication

What happens if one replica says Active and another says Compromised or Destroyed? Last writer or latest timestamp isn't safe here. The restrictive state should win, stale key material shouldn't come back, and the key shouldn't be usable while the conflict is unresolved.

Thx

------------------------------
Aleksei Chirkunov
Public View
------------------------------

Aleksei,

Thank you for your review and comments on the KMIP 3.0 Usage Guide.   We will take these under review and provide our response/disposition to these and other  comments after the public review closes.

Judy Furlong

------------------------------
Judith Furlong
Dell Technologies
------------------------------

Original Message:
Sent: 07-21-2026 10:14
From: Aleksei Chirkunov
Subject: Invitation to Comment on KMIP Usage Guide v3.0 - ends 15 August 2026

Hello, some notes from my side

1. Pages 2 and 6, plus references

The comment paragraph on page 2 appears twice, with the second copy running into the previous sentence. Page 6 still says "remove this note before publication." Also, the RFC 4210 entry calls it RFC 2510, the RFC 4880 URL ends in "txtt," and the revision history has "Editoral."

2. Section 2.2.1.2 – Device Credential

Serial numbers, MAC addresses and machine IDs are identifiers, not proof of identity. If the server trusts them on their own, one device can impersonate another. This needs a secret, client certificate or a trusted assertion from the proxy.

3. Section 3.32.2 – Stateful Cryptographic Operations

The Correlation Value can be associated with a source address or TLS session, but neither is a stable client identity. It should be tied to the authenticated client and authorization checked again for each part. The value also needs to be hard to guess and expire after use.

4. Section 3.56 – Post-Quantum Cryptography

A few references need updating: "NIST publish standards" should be "published," the FIPS 204 link appears twice, and ECDHE-MLKEM still points to draft 03. Linking to the current Datatracker entry would avoid tying the guide to an old draft.

5. Section 4.8 – Cryptographic Erasure

Destroying a key on the KMIP server only erases the server's copy. It doesn't remove copies already returned to clients, and Notify doesn't prove that the client deleted anything. The erasure claim should be limited to storage controlled by the server unless deletion elsewhere is confirmed.

6. Section 4.10 – Key Replication

What happens if one replica says Active and another says Compromised or Destroyed? Last writer or latest timestamp isn't safe here. The restrictive state should win, stale key material shouldn't come back, and the key shouldn't be usable while the conflict is unresolved.

Thx

------------------------------
Aleksei Chirkunov
Public View
------------------------------

Aleksei,

Thanks again for your review and comments on the KMIP 3.0 Usage Guide Committee Note Draft 01

We have reviewed your comments and have incorporated necessary changes into the next revision of the Usage Guide [KMIP 3.0 Usage Guide Committee Note Draft (CND)02]

Please see https://groups.oasis-open.org/higherlogic/ws/public/document?document_id=73520&wg_id=39d0c648-0a66-4f46-b343-018dc7d3f19c for details on the resolution to the comments you provided.

Judy Furlong

------------------------------
Judith Furlong
Dell Technologies
------------------------------

Original Message:
Sent: 07-21-2026 10:14
From: Aleksei Chirkunov
Subject: Invitation to Comment on KMIP Usage Guide v3.0 - ends 15 August 2026

Hello, some notes from my side

1. Pages 2 and 6, plus references

The comment paragraph on page 2 appears twice, with the second copy running into the previous sentence. Page 6 still says "remove this note before publication." Also, the RFC 4210 entry calls it RFC 2510, the RFC 4880 URL ends in "txtt," and the revision history has "Editoral."

2. Section 2.2.1.2 – Device Credential

Serial numbers, MAC addresses and machine IDs are identifiers, not proof of identity. If the server trusts them on their own, one device can impersonate another. This needs a secret, client certificate or a trusted assertion from the proxy.

3. Section 3.32.2 – Stateful Cryptographic Operations

The Correlation Value can be associated with a source address or TLS session, but neither is a stable client identity. It should be tied to the authenticated client and authorization checked again for each part. The value also needs to be hard to guess and expire after use.

4. Section 3.56 – Post-Quantum Cryptography

A few references need updating: "NIST publish standards" should be "published," the FIPS 204 link appears twice, and ECDHE-MLKEM still points to draft 03. Linking to the current Datatracker entry would avoid tying the guide to an old draft.

5. Section 4.8 – Cryptographic Erasure

Destroying a key on the KMIP server only erases the server's copy. It doesn't remove copies already returned to clients, and Notify doesn't prove that the client deleted anything. The erasure claim should be limited to storage controlled by the server unless deletion elsewhere is confirmed.

6. Section 4.10 – Key Replication

What happens if one replica says Active and another says Compromised or Destroyed? Last writer or latest timestamp isn't safe here. The restrictive state should win, stale key material shouldn't come back, and the key shouldn't be usable while the conflict is unresolved.

Thx

------------------------------
Aleksei Chirkunov
Public View
------------------------------