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

[Paul Hoffman <paul.hoffman@xxxxxxxx>]

At 1:59 PM -0400 5/28/09, Daniel Brown wrote:
>Paul,
>
>Regarding your comment 3) below about validation requirements, I suggest that this RFC 3279 update mandate SHA2 as a "SHOULD" (rather than a MUST as it is in the WGLC draft). 
>
>Not making it a MUST avoids making existing implementations non-conformant.  Making it a SHOULD alerts implementers to the security issues and to the NIST compliance/interoperability issues.

Please be more specific. What exact wording are you proposing? If you were simply going to replace "MUST" with "SHOULD" in the last paragraph of section 3, how would an implementer know when it is OK not to follow the mandate?

As you can tell, this whole train of thought still bothers me. It is fine for us to list the issues and to make recommendations about them; that is quite different than invoking RFC 2119 language, particularly in a vague fashion.

>Regarding your comment 2) below about key sizes and lifetimes, I suggest this RFC 3279 update make the associated NIST recommendations a SHOULD.  Again, this is for security reasons and better NIST compliance/interoperability issues. 

And I fully disagree for the same reasons. NIST makes it clear that their recommendations are for one particular market, not the entire world. If we want to make them world-wide, then we should help NIST come up with more consistent and readable recommendations that match the new mandate; so far, NIST has not asked for that type of help, and I would not expect them to do so in the future.

>Generally, the DSA/ECDSA and SHA-1/2 algorithms come from NIST and ANSI, and have some normative security requirements about key sizes.  Completely dropping some of the normative security requirements should require strong justification.

The IETF attempts to create standards that implementers can understand. Mandating the NIST logic, which conflates different sizes and strengths for reasons that make sense for NIST but not for us, does not lead to such standards.

Again, it is a good idea to point to the NIST documents as guidance for implementers. If there were competing documents with different guidance, pointing to them would be good as well (I'm not aware of any such competing documents). That's quite different than mandating compliance with the NIST specs that were written for different purposes than we have.

I would still like comment on my greatly-shortened version of this document, as well as on the other concerns expressed on this thread.


--Paul Hoffman, Director
--VPN Consortium