Re: [pkcs11] Groups - Ballot reminder: "Proposal for changes to DSA mechanism"

[Michael StJohns <msj@nthpermutation.com>]

On 9/11/2013 12:15 PM, Tim Hudson wrote:

I've been traveling so slower to respond on this ballot than usual - but I note a whole pile of issues with the proposed text.
I also note Mike's comment that he thinks this replaces the previous ballot. My understanding was this was meant to be a proposal about FIPS186-4 and how to handle the SUBPRIME backwards compatibility issue - but as usual it includes more than that I was expecting.

This document replaces in its entirety the document already passed proposed by Bob and having a specific Subprime backwards compatibility issue.  That document should not have gone to ballot and should not have been passed because of the group agreement on backwards compatibility, but was passed against the rules. 

Between then and this document, FIP 186-4 was released and it made sense to update the text appropriately (basically incorporating the changes proposed by Oscar but in a manner that worked with the rest of the text).

Why does this proposal elect to preclude choices of any subprime size other than the fixed list noted and also precludes the use of prime sizes other than the specific fixed value?

Um... because FIP186-4 restricts those?  And note that the already passed 186-4 text (proposed by Oscar that you voted for) notes these permitted combinations.

The text you voted for was:

2.2.9 FIPS 186-4
When CKM_DSA is operated in FIPS mode, only the following bit lengths of p and q, represented by L
and N, SHALL be used:
L = 1024, N = 160
L = 2048, N = 224
L = 2048, N = 256
L = 3072, N = 256
pkcs11-

This is a pretty substantial change.

No, not actually.  The old values are still permitted (which I pointed out at least once in a previous message).  The new values are constrained by what's permitted by FIPS 186-4.


The specific text in the new ballot is:

1.1.1 DSA Key Restrictions

FIPS PUB 186-4 specifies permitted combinations of prime and sub-prime lengths.  They are:

• Prime: 1024 bits, Subprime: 160
• Prime: 2048 bits, Subprime: 224
• Prime: 2048 bits, Subprime: 256
• Prime: 3072 bits, Subprime: 256

Earlier versions of FIPS 186 permitted smaller prime lengths, and those are included here for backwards compatibility. A implementation that is compliant to FIPS 186-4 does not permit the use of primes of any length less than 1024 bits.

It doesn't actually restrict the previous lengths as a matter of implementation.  You can implement the old values, you then just can't claim compliance with FIPS 186-4

Why is there is a list of manifest constants included in this document?

Blame Bob - he was trying to make things easier for the editor. 

Why is the list incomplete?
Why does it contain a value which differs from v2.30?
Why does it contain two overlapping definitions?

Why does it matter?  We've already agreed (on the call after discussion), that the values of the manifest constants are the purview of the editor, not the proposer.   All of these are subject to change and correction by the editor.

That is also departing from the previous approaches used and departing the from the previous ballot as well in terms of including manifest constants.

#define CKM_AES_CMAC_GENERAL                         0x0000108B
#define CKM_AES_CMAC_GENERAL                         0x00001089

Why does it contain two overlapping definitions?

#define CKM_AES_CMAC_GENERAL                         0x00001089
#define CKM_AES_CTS                                  0x00001089

As it stands that ballot simply cannot be passed including that information.

As it stands, Tim is objecting based on information that is irrelevant.

The manifest constants should not have been included in the proposal.

Yup - but again, so what?

I suggest those who have already voted yes to this proposal and don't have a clear answer to the above questions change their votes from yes to no.

I suggest that there is no actual problem with the proposal, and that the above comment lacks foundation.

Mike

Tim.