Ballot Details: Revised AES mechanism proposal (CLOSED)

Ballot Question Do you accept the proposal for revisions to the AES mechanism?
Ballot Description Do you accept the proposal for revisions to the AES mechanism as proposed by Bob Relyea on 21-Jun-2013, posted at https://www.oasis-open.org/apps/org/workgroup/pkcs11/download.php/49655/pkcs11-aes.doc (also attached as reference item)?
Ballot Options
VOTING CLOSED: Wednesday, 7 August 2013 @ 3:00 pm EDT
Yes 21 100
No 0 0
Abstain 0
Open Date Wednesday, 17 July 2013 @ 8:00 am EDT
Close Date Wednesday, 7 August 2013 @ 3:00 pm EDT

Referenced Items

Name Type Date

pkcs11-aes.doc

  • Folder: Documents
  • Group: OASIS PKCS 11 TC
  • State: Draft
  • 105K
  • 48 downloads

AES changes to the draft from the working committee.

page=ballotrefitems&type=document
AES draft proposed changes. Document 2013-06-21

Voting Statistics

Number of votes cast (excluding abstentions) 21
Eligible members who have voted 21 of 33 63 7/11%
Eligible members who have not voted 12 of 33 36 4/11%

Voting Summary by Option

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

Voting Details

Voter Name Company Vote * Time (UTC) Comments
* Burns, Robert Thales e-Security Yes 2013-08-02 13:40:00
* Chao, Hai-May Oracle Yes 2013-08-07 18:33:00
* Cox, Tony Cryptsoft Pty Ltd. Yes 2013-08-06 21:39:00
* Gleeson, Susan Oracle Yes 2013-08-07 16:07:00
* Griffin, Robert EMC Yes 2013-08-02 13:40:00
* Hudson, Tim Cryptsoft Pty Ltd. Yes 2013-08-02 19:17:00
* Krahn, Darren Google Inc. Yes 2013-08-06 22:45:00
* Kurktchi, Dina Oracle Yes 2013-08-07 16:38:00
* Leiseboer, John QuintessenceLabs Pty Ltd. Yes 2013-08-04 20:16:00
* Powers, Mark Oracle Yes 2013-08-07 16:08:00
* Puri, Ajai SafeNet, Inc. Yes 2013-08-07 17:31:00
* Relyea, Robert Red Hat Yes 2013-07-24 18:20:00
* Siravara, Radhika Oracle Yes 2013-08-07 16:16:00
* Smith, David Venafi, Inc. Yes 2013-08-04 17:10:00
* So, Oscar Oracle Yes 2013-07-31 21:42:00
* StJohns, Michael Individual Yes 2013-07-17 20:35:00 1
* Temme, Sander Thales e-Security Yes 2013-08-07 15:26:00
* Turnes, Walter-John Gemini Security Solutions, Inc. Yes 2013-07-24 20:09:00
* Walter, Stef Red Hat Yes 2013-07-24 08:43:00
* Zdunkiewicz, Magda Cryptsoft Pty Ltd. Yes 2013-08-06 21:40:00
* Zimman, Chris Bloomberg Finance L.P. Yes 2013-08-07 16:57:00
* Bartok, Peter Venafi, Inc. --
* Chang, Wan-Teh Google Inc. --
* Cheng, Janice Vormetric, Inc. --
* Cohen, Doron SafeNet, Inc. --
* Duane, Christopher EMC --
* Fenwick, Valerie Oracle --
* Janssen, Gershon Individual --
* Knight, Mark Thales e-Security --
* Krasnov, Alex Infineon Technologies AG --
* Lockhart, Hal Oracle --
* Smith, Ryan Futurex --
* Stevens, Michael QuintessenceLabs Pty Ltd. --

Voter Comments

Submitter Vote Comment
StJohns, Michael
Individual
Yes I'm assuming these can be handled as editorial fixes - they don't gate my vote:

In 1.1.2 the document has 0 < ulCounterBits <= 128, but later in that section has "This construction permits ... up to 2^32-1...". One of these is wrong as you can't have more blocks than the block counter max value.

Both CCM and GCM should probably use the NIST documents as the reference rather than the RFCs.

For CCM, if the counter block format is as defined in appendix A of the NIST document (and it appears to be given the format of the input structure), state that. The base document allows alternate formats, but appendix A is not part of the main standard.

In 1.2.4, in the last bullet under Encrypt the document has C_DecryptUpdate where it should be C_EncryptUpdate.

Finally, if either CCM or GCM prohibits release of data before the MAC tag is checked, it would be useful to state a suggested minimum buffering size. The number I got from Russ Housley was 2x the size of a jumbogram - call it 20K bytes. That may be more a more appropriate statement for a usage guide and does not gate my vote. If that's where this ends up I'd also note that CCM and GCM are designed for data where the length of the data is known specifically packetized network data. From a hardware implementation point of view, I'd probably end up not doing GCM and CCM in hardware due to this buffering requirement - instead doing it as a wraparound to ECB.