Ballot Details: Split Key proposal (CLOSED)

Ballot Question Do you approve the Proposal for Split Key operations, including associated Usage Guide text?
Ballot Description Do you approve the Proposal for Split Key operation (including associated Usage Guide text) in “Split_Key_Proposal_v0.6.docx” for inclusion in KMIP V1.2, as posted 30-Apr-2013 by Kelley Burgin?
Ballot Options
VOTING CLOSED: Wednesday, 15 May 2013 @ 6:00 pm EDT
Yes 25 100
No 0 0
Abstain 0
Open Date Sunday, 5 May 2013 @ 1:30 pm EDT
Close Date Wednesday, 15 May 2013 @ 6:00 pm EDT

Referenced Items

Name Type Date

Split_Key_Proposal_v0.6.docx

  • Folder: Drafts
  • Group: OASIS Key Management Interoperability Protocol (KMIP) TC
  • State: Draft
  • 37K
  • 24 downloads

Added optional Secret Data Type to Join Split Key request.

page=ballotrefitems&type=document
Split_Key_Proposal_v0.6.docx Document 2013-04-30

Voting Statistics

Number of votes cast (excluding abstentions) 25
Eligible members who have voted 25 of 38 65 15/19%
Eligible members who have not voted 13 of 38 34 4/19%

Voting Summary by Option

Options with highest number of votes are bold
Option # Votes % of Total
Yes 25 100%
No 0 0%
Abstain 0

Voting Details

Voter Name Company Vote * Time (UTC) Comments
* Berglas, Anthony Cryptsoft Pty Ltd. Yes 2013-05-10 00:09:00
* Burgin, Kelley National Security Agency Yes 2013-05-06 11:57:00
* Castleton, Chuck Venafi, Inc. Yes 2013-05-09 20:01:00
* Cox, Tony Cryptsoft Pty Ltd. Yes 2013-05-06 19:09:00
* Feather, Stan Hewlett-Packard Yes 2013-05-13 15:14:00
* Furlong, Judith EMC Yes 2013-05-08 13:40:00
* Griffin, Robert EMC Yes 2013-05-05 20:09:00
* Hudson, Tim Cryptsoft Pty Ltd. Yes 2013-05-05 20:32:00
* Kenig, Marc SafeNet, Inc. Yes 2013-05-14 17:31:00
* Kriese, Kathy Symantec Corp. Yes 2013-05-06 14:34:00
* Leiseboer, John QuintessenceLabs Pty Ltd. Yes 2013-05-05 23:08:00 1
* Lockhart, Robert Thales e-Security Yes 2013-05-09 20:35:00
* Milshtein, Marina Individual Yes 2013-05-06 23:18:00
* Peck, John IBM Yes 2013-05-13 18:38:00
* Rich, Bruce IBM Yes 2013-05-06 15:47:00
* Saha, Saikat SafeNet, Inc. Yes 2013-05-06 03:43:00
* Sankuratripati, Subhash NetApp Yes 2013-05-06 15:52:00
* Smith, David Venafi, Inc. Yes 2013-05-09 20:04:00
* Stevens, Michael QuintessenceLabs Pty Ltd. Yes 2013-05-06 22:54:00
* Thota, Kiran VMware, Inc. Yes 2013-05-09 20:36:00
* Wierenga, Steven Hewlett-Packard Yes 2013-05-14 15:30:00
* Wong, Jin QuintessenceLabs Pty Ltd. Yes 2013-05-06 22:57:00
* Yellepeddy, Krishna IBM Yes 2013-05-08 14:47:00
* Yoder, Michael Vormetric, Inc. Yes 2013-05-13 16:07:00
* Zdunkiewicz, Magda Cryptsoft Pty Ltd. Yes 2013-05-09 22:26:00
* Benjamin, Tom IBM --
* Bjorkqvist, Mathias IBM --
* Brown, Alan Thales e-Security --
* Chong, Kenli QuintessenceLabs Pty Ltd. --
* Finkelstein, David Symantec Corp. --
* Fitzgerald, Indra Hewlett-Packard --
* Gleeson, Susan Oracle --
* Knight, Mark Thales e-Security --
* Lambiase, Mark SecureAuth Corporation --
* Lockhart, Hal Oracle --
* Olson, Bryan Hewlett-Packard --
* Robbins, Warren Dell --
* Ying, Catherine SafeNet, Inc. --

Voter Comments

Submitter Vote Comment
Leiseboer, John
QuintessenceLabs Pty Ltd.
Yes I support the proposal, but there are still details to be worked out: "The client may want to add link attributes ...". I'm not sure that this is a good idea. I'd be concerned at non-interoperable implementations when, for example, keys in a linked chain are destroyed. There is also the question of how to handle individually compromised splits. And what happens when sufficient splits are destroyed or compromised such that there are not enough left to join for the full key? Is there a need to manage the aggregate set of splits to ensure consistency of state, and to make sure that we don't end up with "dangling" split keys?