Ballot Details: Cryptographic Services (CLOSED)

Ballot Question Do you approve the cryptographic services proposal?
Ballot Description Do you approve the proposal to support cryptographic services in KMIP, including changes to the KMIP Specification V1.2 and associated profile, as described in “Cryptographic_Services_wd11.pdf” posted 20-March-2013 by Tim Hudson?

Document is included as reference below and is available at
Ballot Options
VOTING CLOSED: Monday, 1 April 2013 @ 11:59 pm CEST
Yes 19 67 6/7
No 9 32 1/7
Abstain 0
Open Date Friday, 22 March 2013 @ 12:00 pm CET
Close Date Monday, 1 April 2013 @ 11:59 pm CEST

Referenced Items

Name Type Date


  • Folder: Drafts
  • Group: OASIS Key Management Interoperability Protocol (KMIP) TC
  • State: Draft
  • 559K
  • Revision 1 of 1

Updated working draft for Cryptographic Services based on Working Draft 05.

cryptographic-services-wd11.pdf Document 2013-03-20

Voting Statistics

Number of votes cast (excluding abstentions) 28
Eligible members who have voted 28 of 37 75 25/37%
Eligible members who have not voted 9 of 37 24 12/37%

Voting Summary by Option

Options with highest number of votes are bold
Option # Votes % of Total
Yes 19 67 6/7%
No 9 32 1/7%
Abstain 0

Voting Details

Voter Name Company Vote * Time (UTC) Comments
* Berglas, Anthony Cryptsoft Pty Ltd. Yes 2013-03-23 00:10:00
* Burgin, Kelley National Security Agency Yes 2013-03-26 18:48:00
* Cox, Tony Cryptsoft Pty Ltd. Yes 2013-03-25 02:36:00
* Feather, Stan Hewlett-Packard Yes 2013-03-28 20:37:00
* Finkelstein, David Symantec Corp. Yes 2013-03-27 18:06:00
* Fitzgerald, Indra Hewlett-Packard Yes 2013-04-01 16:57:00 1
* Furlong, Judith EMC Yes 2013-03-28 15:07:00 1
* Gleeson, Susan Oracle Yes 2013-04-01 12:50:00
* Griffin, Robert EMC Yes 2013-03-22 11:21:00
* Hudson, Tim Cryptsoft Pty Ltd. Yes 2013-03-22 19:26:00
* Kriese, Kathy Symantec Corp. Yes 2013-03-22 12:57:00
* Lambiase, Mark SecureAuth Corporation Yes 2013-03-25 05:29:00
* Luk, Anne Cryptsoft Pty Ltd. Yes 2013-03-22 22:26:00
* Milshtein, Marina SafeNet, Inc. Yes 2013-04-01 20:28:00
* Sankuratripati, Subhash NetApp Yes 2013-03-24 21:53:00
* Smith, David Venafi, Inc. Yes 2013-03-25 02:13:00
* Thota, Kiran VMware, Inc. Yes 2013-03-22 16:49:00
* Yoder, Michael Vormetric, Inc. Yes 2013-03-25 21:43:00
* Zdunkiewicz, Magda Cryptsoft Pty Ltd. Yes 2013-03-22 19:34:00
* Benjamin, Tom IBM No 2013-03-27 15:57:00
* Brown, Alan Thales e-Security No 2013-04-01 19:42:00
* Kenig, Marc SafeNet, Inc. No 2013-03-29 21:17:00
* Knight, Mark Thales e-Security No 2013-04-01 19:38:00
* Leiseboer, John QuintessenceLabs Pty Ltd. No 2013-03-25 00:53:00 1
* Lockhart, Robert Thales e-Security No 2013-04-01 19:34:00 1
* Peck, John IBM No 2013-03-27 19:49:00 1
* Singh, Greg QuintessenceLabs Pty Ltd. No 2013-03-27 03:08:00
* Turajski, Nathan Thales e-Security No 2013-04-01 19:38:00
* Bjorkqvist, Mathias IBM --
* Grojean, Paul Individual --
* Lockhart, Hal Oracle --
* Olson, Bryan Hewlett-Packard --
* Rich, Bruce IBM --
* Robbins, Warren Dell --
* Saha, Saikat SafeNet, Inc. --
* Wierenga, Steven Hewlett-Packard --
* Wong, Jin QuintessenceLabs Pty Ltd. --

Voter Comments

Submitter Vote Comment
Furlong, Judith
Yes As co-editor for the Usage Guide document I'd like to reserve the right to ask the author to contribute UG text - text that will describe why this functionality was being added to KMIP (we may be able to borrow your intro.) and potentially usage scenarios (Note there are use cases content for this proposal).

Also wanted to point our an editorial issue with this WD11 -- Section 2.10.7 Conformance Clauses is at the wrong level. It shoudl be section 2.11 and all the subsequent conf. clause sections should be subsections (e.g. 2.11.x).
Fitzgerald, Indra
Yes SignatureData should be returned in the Sign Response payload. Clarification and guidance should also be added to the Usage Guide.
Lockhart, Robert
Thales e-Security
No I agree with the proposal in principal but as it stands now it is still open to generic encryption operations that are not the purpose of KMIP.

The functions need to be focused on keys, and other objects such that objects to be encrypted should be registered as part of the encrypt operation as a key, secret data or opaque object.

We need to consider the repercussions of any server to server operations in the future that will require these operations as well since sharing a key from one server to another will in all likelihood require an unwrap from an internal key or keys and rewrap with a mutually agreed upon key between the servers.

Sign/Certify and Verify/Validate operations should be focused on keying material for validation AND for use in client registration operations.

The RNG/RBG functions are fine as is.
Peck, John
No I do not feel this belongs in KMIP. Yes, I understand that KMIP needs these, but that is why there are other standards around cryptography. We really need to focus on the issues with key management.
Leiseboer, John
QuintessenceLabs Pty Ltd.
No Security and interop concerns still exist for this proposal as it is currently written. Please see https://www.oasis-open.­org/apps/org/workgroup/k­mip/download.php/48612/C­omments%20on%20crypto%20­proposal%20wd10.pdf for detailed comments on earlier draft. Summary of issues still unresolved in wd11:
- Permitting use of shared RNG and not providing profiles or an RNG implementation query operation can lead to compromised random and managed cryptographic objects
- Questions about precedence of cryptographic parameters are still unanswered. Is a client permitted to force a server to perform operations using cryptographic parameters that contradict the parameters of the keys managed by the server?
- Inconsistency regarding specification of Cryptographic Algorithm: not permitted for Encrypt and Decrypt, but permitted for Sign, verify, MAC, MAC Verify. Why?