At 7:44 PM +1000 8/6/08, Jim Schaad wrote:
> -----Original Message-----
From: Paul Hoffman [mailto:phoffman(_at_)imc(_dot_)org]
Sent: Sunday, August 03, 2008 8:28 AM
To: Jim Schaad; Sean P. Turner; 'Blake Ramsdell'
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
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.
I can deal with a SHOULD+ for this
In retrospect, I agree with Jim and I'm happy with SHOULD+ for
DSA-with-SHA-256 for both sending and receiving. It's not that big of
a change from 3851.
I am perfectly willing to use a non standards word here. For example,
permitted. I thought I saw enough consensus from the list that keys over
this size will have either real-estate constraints or performance
constraints. Either would be covered by referring to a security
considerations discussion to this effect. I don't want to say or imply that
keys longer than 4096 are not to be handled.
Proposed wording:
Receiving agents that validate signatures need to be cautious of CPU
usage when validating signatures larger than those mandated in this
specification. An attacker can send very large, bogus signatures in
order to swamp the CPU of the receiving party. Receiving parties that
verify large signatures are advised to have some sort of resource
management system to prevent such an attack.