> 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. Great. For ideal interoperability and security, this draft should be as a well-defined as possible. In particular, it could specify what is meant by DSA, SHA-2, etc., which can be done by normative reference to other specifications, such as ANSI/NIST documents. (Perhaps, past PKIX practice has been to cite a crypto algorithm by informative reference, but wouldn't it be better to use a normative reference?) This draft can explicitly exempt any requirements in the normative references that PKIX deems unsuitable, or only require certain parts of the normative references, whichever is clearer. Please suggest a solution along these lines if you have one. If these approaches are too impractical, I suggest a compromise: apply a blanket SHOULD to all the requirements (not recommendations) in the corresponding NIST/ANSI documents either with a few explicit exceptions for the requirements PKIX deems unsuitable - I again ask for a suggested list of exceptions - or with a blanket exemption MAY with reasons similar to the reason above for continuing to use SHA-1. Best regards, Dan -----Original Message----- From: Stefan Santesson [mailto:stefan@xxxxxxxxxxx] Sent: Tuesday, June 16, 2009 1:27 PM To: Paul Hoffman; Daniel Brown; ietf-pkix@xxxxxxx Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt 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 >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature