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)?|
VOTING CLOSED: Wednesday, 7 August 2013 @ 3:00 pm EDT
|Open Date||Wednesday, 17 July 2013 @ 8:00 am EDT|
|Close Date||Wednesday, 7 August 2013 @ 3:00 pm EDT|
|DSA 186-3 related changes.||Document||2013-06-21|
|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%|
|Options with highest number of votes are bold|
|Option||# Votes||% of Total|
|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.||--|
|Knight, Mark||Thales e-Security||--|
|Krasnov, Alex||Infineon Technologies AG||--|
|Stevens, Michael||QuintessenceLabs Pty Ltd.||--|
|Turnes, Walter-John||Gemini Security Solutions, Inc.||--|
|Walter, Stef||Red Hat||--|
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.
|Yes||A few typos found:
1) Page 1: "CKM_DSA_SHAWE_TAYLOR_PARAMTER_GEN" in the table should be "CKM_DSA_SHAWE_TAYLOR_PARAMETER_GEN"
2) Page 2: "typedef struct CK_DSA_PARAMTER_GEN_PARAM" should be "typedef struct CK_DSA_PARAMETER_GEN_PARAM"
And, finally, FIPS 186-4 is new, FIPS 186-3 is gone:
|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).
|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).
QuintessenceLabs Pty Ltd.
|No||Proposal needs to be updated to fix typos and address other voters' comments.
|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.
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.
|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).