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

[Stefan Santesson <stefan@xxxxxxxxxxx>]

In general I agree with Paul here. Regardless of what we define, it should
be said in a way that is clear and unambiguous. We should also be clear
about what requirements we state. A simple open reference to all
requirements of another standard is not a good way to specify IETF
requirements. 

I personally dislike standards stating requirements on algorithm support for
any reason other than to increase interoperability. The choices of adequate
and secure algorithms is a constantly moving target and is ideally better
stated in BCP documents if the rationale is purely security driven.

We have to remember that our protocols may be used under vastly different
security policies. Without knowing them, it is almost impossible to define
what is appropriate, unless when something is completely broken.

/Stefan

On 09-06-15 9:28 PM, "Paul Hoffman" <paul.hoffman@xxxxxxxx> wrote:

> 
> 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
>