At 2:17 PM +0100 7/28/08, Jim Schaad wrote:
Comments on the draft:
1. We are not currently making any support statements for DSA w/ the
SHA-256 hash algorithms. Should we be doing so?
Yes and no. Yes in the sense that US government users who use DSA
will want DSA-with-SHA-256. No in the sense that there is no
appropriate level of standards support that makes sense: SHOULD is
too strong, given current deployments.
2. For key size support, key of L>1024 are not supported for DSA-SHA-1.
Arrgh. Quite right. Sections 4.2 and 4.3 need to be rewritten to
indicate that anything greater than 1024 is about RSA *only*.
3. I would like to add the following text to the table.
Key size > 4096 MAY NOT (See security considerations on large keys)
This would finish the table entry out and also reference the discussion on
why very large keys are not recommended. It is possible that MAY NOT is not
currently valid 2119 language. In this case I would be happy with ether MAY
or SHOULD NOT. I would not be happy with MUST NOT.
"MAY NOT" is not part of 2119. Further, we do not have enough
evidence to know size key is "too large". Further still, the number
will be different for receivers of RSA and DSA keys, I believe.
"MAY" makes no sense. "SHOULD NOT" is too strong, I believe, without
more than just data-less guessing on our part.
At 4:43 PM +0100 7/31/08, Jim Schaad wrote:
I really feel that we need to have two MUST signature algorithms for safety.
When ECC signatures where present that was fine. Without having the ECC
signature algorithms we really must have one of the DSA algorithms as a must
I disagree. If RSA falls for some reason that cannot be fixed with
longer key sizes, a "SHOULD" on DSA-SHA256 for fallback reasons
assumes that the attack on RSA will not apply to DSA, which seems
like a stretch. Having a "SHOULD" for a fallback seems reasonable.