RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

[Tom Gindin <tgindin@xxxxxxxxxx>]

        I'm not in charge of this draft, of course, but my draft paragraph 
is more a citation of others' reasonably informed opinion than an explicit 
recommendation.  It doesn't need either a SHOULD or a MUST.  If we need to 
give firmer guidance, I myself would suggest a pair of SHOULD's, but no 
MUST's.
        The first appropriate SHOULD implied is "An implementor in an 
environment where a symmetric key of length L bits is often used SHOULD 
NOT use a hash algorithm with an output length of less than 2L bits for 
digital signatures".  That's an implication of NIST's analysis, and I see 
no reason not to use it.  The other is "Signatures expected to be verified 
more than a few weeks after they are produced SHOULD NOT use any hash 
algorithm with an output length of 160 bits or less".  Long-term 
verification naturally calls for a margin of safety above other 
signatures, and I would not want to present a signature for long-term 
verification that NIST has already declared too short (as they will do to 
SHA-1 at the end of 2009), unless I had concrete reasons for doubting 
their judgement.

                Tom Gindin





Paul Hoffman <paul.hoffman@xxxxxxxx> 
06/18/2009 11:43 AM

To
Tom Gindin/Watson/IBM@IBMUS, Daniel Brown <dbrown@xxxxxxxxxxxx>
cc
"ietf-pkix@xxxxxxx" <ietf-pkix@xxxxxxx>
Subject
RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt






At 9:14 PM -0400 6/17/09, Tom Gindin wrote:
>        Would it be simple enough to just say that NIST SP 800-57 part 1
>table 3 implies that its authors consider the use of a given hash
>algorithm of the SHA family in digital signatures with an output length 
of
>2L bits to have roughly comparable strength (presumably against known
>cryptographic attacks) to the use of a symmetric key of L bits?  We can
>also say that NIST has given its own summaries of appropriate key lengths
>for use after a given date in table 4 of that same document, instead of
>referencing multiple long documents and expecting implementors to read
>them.

That definitely works for me, assuming that you mean "replace the SHOULDs 
and MUSTs" with the above wording.

--Paul Hoffman, Director
--VPN Consortium