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

[Paul Hoffman <paul.hoffman@xxxxxxxx>]

At 11:35 AM -0400 6/12/09, Daniel Brown wrote:
>***
>Conforming CA implementations SHOULD use SHA-224, SHA-256, SHA-384 or
>SHA-512 when generating certificates, but MAY use SHA-1.
>***

I strongly dislike SHOULDs that don't come with reasons: how is an implementer supposed to know what to do? How about: Conforming CA implementations SHOULD use SHA-224, SHA-256, SHA-384 or SHA-512 when generating certificates, but MAY use SHA-1 if they have a stated policy that requires the use of this weaker algorithm.


>***
>Conforming CA implementations that generate DSA signatures for certificates
>or CRLs MUST generate such DSA signature in accordance with all the
>requirements in [FIPS 186-3].  Similarly, such DSA signatures SHOULD also be
>generated in accordance with all the recommendations in [FIPS 186-3].
>***

Here you are  saying "in order to conform with this RFC under the IETF standard track rules, you must conform to that FIPS document under NIST's rules." Of course, you do not list all the requirements from FIPS 186-3 that you mean. For example, some of those rules in fact don't live in FIPS 186-3, but instead in NIST SP 800-89, and others live in other documents, some of which are now under revision.

This kind of requirement is fine for a NIST document because NIST can make their own rules and enforce them as they see fit. This kind of requirement is also fine for an Informational RFC, but is completely inappropriate for a standards-track RFC. The requirement should be removed, or the intended status of this document should be Informational RFC. I would prefer the former, but others may prefer the latter.

>***
>Conforming CA implementations that generate ECDSA signatures in certificates
>or CRLs MUST generate such ECDSA signatures in accordance with all the
>requirements specified in [X9.62].  Similarly, such ECDSA signatures SHOULD
>be generated in accordance with all the recommendations in [X9.62].
>***

Ditto, except that now it's s/NIST/ANSI/.

>5.    Security Considerations
>
>NIST has defined appropriate use of the hash functions in terms of the
>algorithm strengths and expected time frames for secure use in Special
>Publications (SPs) 800-78-1 [SP 800-78-1], 800-57 [SP 800-57] and 800-107
>[SP 800-107]. These documents can be used as guides to choose appropriate
>key sizes for various security scenarios.
>
>***
>ANSI also provides security considerations for ECDSA in [X9.62]. These
>security considerations may be used as a guide.
>***   

This is very good wording for the security considerations.

--Paul Hoffman, Director
--VPN Consortium