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

[Paul Hoffman <paul.hoffman@xxxxxxxx>]

At 4:19 PM -0400 6/16/09, Daniel Brown wrote:
>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.

Fully agree.

>  (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?)

There is no practical difference unless someone eventually tries to move this forwards on the standards ladder, which basically never happens.

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

FIPS 186-3 has literally dozens of requirements. It is inappropriate to have to list all of the ones we do not want. For example, this list could debate forever about how needed things such as those in section 4.3.2 are. There are, again, literally dozens of similar examples.

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

<sigh> As discussed earlier, every SHOULD without an explicit explanation of when an implementer can ignore leads to lack of interop or, in many cases worse, lack of security.

If you cannot do the work of picking which of the requirements of FIPS 186-3 and X9.62 you actually want to be mandatory in the IETF sense, it would be better to simply make this an Informational RFC.

--Paul Hoffman, Director
--VPN Consortium