Ballot Details: Revised DSA mechanism proposal (CLOSED)

Ballot Question Do you accept the proposal for revisions to the DSA mechanism?
Ballot Description Do you accept the proposal for revisions to the DSA mechanism as proposed by Bob Relyea on 21-Jun-2013, posted at https://www.oasis-open.org/apps/org/workgroup/pkcs11/download.php/49654/pkcs11-dsa-186-3.doc (also attached as reference item)?
Ballot Options
VOTING CLOSED: Wednesday, 7 August 2013 @ 3:00 pm EDT
Yes 10 83 1/3
No 2 16 2/3
Abstain 7
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-dsa-186-3.doc

  • Folder: Documents
  • Group: OASIS PKCS 11 TC
  • State: Draft
  • 146K
  • 44 downloads

With not comments on the original proposal, I simply updated the PKCS #11 document according to the proposal. NOTE: this proposal does not try to deal with the DSA verification parameters.

page=ballotrefitems&type=document
DSA 186-3 related changes. Document 2013-06-21

Voting Statistics

Number of votes cast (excluding abstentions) 12
Eligible members who have voted 19 of 33 57 19/33%
Eligible members who have not voted 14 of 33 42 14/33%

Voting Summary by Option

Options with highest number of votes are bold
Option # Votes % of Total
Yes 10 83 1/3%
No 2 16 2/3%
Abstain 7

Voting Details

Voter Name Company Vote * Time (UTC) Comments
* Burns, Robert Thales e-Security Yes 2013-08-03 16:29:00 1
* Cox, Tony Cryptsoft Pty Ltd. Yes 2013-08-06 21:38:00
* Griffin, Robert EMC Yes 2013-08-03 08:40:00
* Hudson, Tim Cryptsoft Pty Ltd. Yes 2013-08-02 19:33:00 1
* Puri, Ajai SafeNet, Inc. Yes 2013-08-07 17:54:00
* Relyea, Robert Red Hat Yes 2013-07-24 18:19:00 1
* Siravara, Radhika Oracle Yes 2013-08-07 15:54:00
* So, Oscar Oracle Yes 2013-07-31 21:51:00 1
* Temme, Sander Thales e-Security Yes 2013-08-07 14:57:00
* Zdunkiewicz, Magda Cryptsoft Pty Ltd. Yes 2013-08-06 21:40:00
* Leiseboer, John QuintessenceLabs Pty Ltd. No 2013-08-04 20:15:00 1
* StJohns, Michael Individual No 2013-07-25 20:49:00 1
* Chao, Hai-May Oracle Abstain 2013-08-07 18:36:00
* Gleeson, Susan Oracle Abstain 2013-08-07 16:09:00
* Krahn, Darren Google Inc. Abstain 2013-08-06 22:52:00
* Kurktchi, Dina Oracle Abstain 2013-08-07 16:39:00
* Powers, Mark Oracle Abstain 2013-08-07 16:35:00
* Smith, David Venafi, Inc. Abstain 2013-08-04 17:35:00 1
* Zimman, Chris Bloomberg Finance L.P. Abstain 2013-08-07 16:56: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. --
* Turnes, Walter-John Gemini Security Solutions, Inc. --
* Walter, Stef Red Hat --

Voter Comments

Submitter Vote Comment
Hudson, Tim
Cryptsoft Pty Ltd.
Yes Assuming the typos noted by Oscar are fixed this looks good to me - but Mike's comments and Bob's response I think are an item to perhaps go into the usage guide.
So, Oscar
Oracle
Yes A few typos found:

1) Page 1: "CKM_DSA_SHAWE_TAYLOR_P­ARAMTER_GEN" in the table should be "CKM_DSA_SHAWE_TAYLOR_P­ARAMETER_GEN"

2) Page 2: "typedef struct CK_DSA_PARAMTER_GEN_PAR­AM" should be "typedef struct CK_DSA_PARAMETER_GEN_PA­RAM"

And, finally, FIPS 186-4 is new, FIPS 186-3 is gone:
http://www.ofr.gov/OFRU­pload/OFRData/2013-17396­_PI.pdf
Burns, Robert
Thales e-Security
Yes I vote YES with the following recommended corrections to typos/oversights:

1) Replace all occurrences of FIPS PUB 186-2 and 186-3 with FIPS PUB 186-4.

2) Typo: replace all occurrences of 'PROBALISTIC' with 'PROBABILISTIC'

3) Typo: replace all occurrences of 'PARAMTER' with 'PARAMETER'

4) 1.1.6 needs a clarifying statement reflecting the new required parameter CKA_SUBPRIME_BITS. Specifically I recommend replacing the sentence, "The mechanism generates DSA domain parameters with a particular prime length in bits, as specified in the CKA_PRIME_BITS attribute of the template." with "The mechanism generates DSA domain parameters with a particular prime and subprime length in bits, as specified by the CKA_PRIME_BITS and CKA_SUBPRIME_BIT attributes of the template."

5) Correct oversights in 1.1.10 with respect to the new functionality which is no longer tied to 1024/160 bit prime/subprime lengths. Specifically, remove references to 20-byte hash values, or 40-byte strings and make these references generic as reflected in table 4. Mirroring the changes as already completed win section 1.1.11 should be sufficient.

6) Table 4 should refer to bytes, not bits. Also, a 64 byte input length is not supported given that subprime lengths are limited to 384 bits (e.g. 48 bytes max).
Relyea, Robert
Red Hat
Yes Re michael's comment: One of the vargaries of the PKCS #11 spec is that size meanings very by algorithm type. Asymmetric algorithms like RSA and DSA have used bits and symmetric algorithms have use bytes. This proposal keeps

> Is there any relationship between the size of the prime and the size of the subprime? If so, this should be stated.

That's in the referenced external spec. It's not 1 to 1, so we still need to specify subprime size.

RE: CKA_SUBPRIME and CKM_DSA_PARAMETER_GEN..­. there should be no change. CKM_DSA_PARAMETER_GEN still only generates 1024 bit keys in this proposal..

(NOTE: these would have been great comments when I posted the spec several weeks ago).
Leiseboer, John
QuintessenceLabs Pty Ltd.
No Proposal needs to be updated to fix typos and address other voters' comments.
StJohns, Michael
Individual
No [New comments on the NO]

1) FIPS 186-4 is now issued. The document should be updated to reflect this.

2) The values in table 4 are completely wrong. It's bytes not bits, and the values for C_Verify need to be tuples e.g. (20, 40), (28, 56) and (32, 64) reflecting the lengths of the input data and input signature respectively.

3) 1.1.6 has an issue in that I believe that any reasonable person reading this would assume that this mechanism (CKM_DSA_PARAMETER_GEN) could be used with any of the pairs of legal key sizes for a DSA key (prime and subprime length) and not just with the (1024, 160) key size. Two of the valid key sizes are (2048, 224) and (2048, 256) which means you can't just assume that the subprime length can be derived from the prime length. That means that - for at least 2048 bit keys - you need to specify the CKA_SUBPRIME_BITS attribute. But then what do you do about backwards compatibility? If you require this to be specified for all prime lengths, you break backwards compatibility. Recommendation here - provide a subprime bits default for each of the valid key lengths.

[Original comments]
I don't know enough about DSA to comment on the technical aspects. These comments may or may not be accurate as they're made without reference back to the DSA document.

In table 4, the input sizes are defined as bits - but I believe those are probably bytes.

The discussion about the encoding of the r and s values should include fixed length and left padded with zeroes or leading zero truncated - an example would be useful.

Is there any relationship between the size of the prime and the size of the subprime? If so, this should be stated.

What is the error code to identify a bad subprime length? (Say for key pair generation)?

The addition of CKA_SUBPRIME_BITS as a required attribute is a non-backwards compatible change that affects CKM_DSA_PARAMETER_GEN. Instead EITHER change the language to retain 160 as a default for that attribute if not specified (preferred - change the superscript in the domain params table), OR add a new mechanism that understands CKA_SUBPRIME_BITS.
Smith, David
Venafi, Inc.
Abstain I am not sure of the procedural impact of multiple conditional approvals being raised in voting comments; therefore, I feel it prudent to ABSTAIN at this point. Specifically, if the recommended corrections raised in the comments are corrected AND if the suggestion regarding 1.1.6 by Robert Burns is sufficient to resolve the concern raised by Michael StJohns (in his revised comments).