Here's a small set of comments on x942-05, following discussion re x942-04.
In sec. 2.1.2, description of "algorithm": suggest adding the following
sentence at end: "As an implication, it may be appropriate for algorithms
employing variable parameters other than key size to be represented with
different OIDs corresponding to different parameter combinations, if
parameter values cannot be unambiguously determined from usage context". As
a related point, would it be acceptable to state that the structure of
suppPubInfo may be defined on a per-algorithm basis? For the case of RC2
usage in S/MIME, where the key length is fixed to 128 bits, it seems to
offer more protective value to represent the variable effective key length
within suppPubInfo than to represent the fixed 128 bit length.
In 2.1.2, last paragraph, suggest rewriting "the security of the data is
limited ... even if a string longer than ZZ is generated" as "even if a
string longer than ZZ is generated, the effective key space of the KEK is
limited by the size of ZZ, in addition to any security level considerations
imposed by the parameters p and q."
In 2.2, 2nd paragraph, suggest changing "...m MUST be >=160" -> "...m MUST
be >= 160 bits in length". Later in the paragraph, is 160 bits intended as
the appropriate minimum length for p? (Note, by comparison, that X9.42
requires a multiple of 256 bits with a minimum of 512.)
In 2.3 and 2.4, suggest adding references to [LL97] for discussion of
additional means for generating keys which are not subject to small subgroup
attacks.
In the last paragraph of security considerations, suggest rewriting in terms
of security levels provided, rather than key sizes required. This makes the
discussion more relevant to particular key sizes selected, rather than
imposing recommended key sizes. In particular, suggest:
The security level provided by these methods depends on several factors. It
depends on the length of the symmetric key (typically, a 2^l security level
if the length is l bits); the size of the prime q (a 2^{m/2} security
level); and the size of the prime p (where the security level grows as a
subexponential function of the size in bits). A good design principle is to
have a balanced system, where all three security levels are approximately
the same. If many keys are derived from a given pair of primes p and q, it
may be prudent to have higher levels for the primes. In any case, the
overall security is limited by the lowest of the three levels.
Editorial:
In 2.1.1, the description of h says "... h(p-1)/q mod p ..."; should be "...
h^{(p-1)/q} mod p ...".
In 2.2, first paragraph, FIPS-186-1 is cited as [DSS], which doesn't appear
in the references. Given that FIPS-186-1 is currently in a review comment
period, it may be appropriate to shift this citation to point to the
finalized [FIPS-186], as included in the references section. In the same
paragraph, there's an unmatched opening parenthesis.
In 2.2, 2nd paragraph, "... consequently, q MUST each be ..." -> "...
consequently, q MUST be ...".
Sec. 2.4 and the security considerations section each have cross-references
as "S" rather than "Section".
--jl