-----Original Message-----
From: Paul Hoffman [mailto:phoffman(_at_)imc(_dot_)org]
Sent: Wednesday, August 06, 2008 11:07 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 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.
Is this in addition to or to replace the para that starts "Larger keys are
not" in 3851bis Sec 5?
spt