PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors
draft-josefsson-pbkdf2-test-vectors-06

    (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Simon Josefsson  is the Document Shepherd.  He
reviewed the document and believes it is ready.

    (1.b)  Has the document had adequate review both from key WG
          members and from key non-WG members?  Does the Document
          Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The test vectors in the document have been reviewed and confirmed by
three people (including the author) for at least four different
implementations.

The draft has been brought to the attention of the CFRG:
http://www.ietf.org/mail-archive/web/cfrg/current/msg02686.html

While the number of people that have reviewed the document isn't
extensive, the quality of the reviews makes me feel confident that the
document is good to go.

    (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar
          with  AAA, internationalization, or XML?

None.  The document doesn't define a protocol, it just provides test
vectors, so the essential review is to make sure there aren't errors
in the test vectors.  That should be covered already.

    (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document,
          or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has
          indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this
          document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

There are no IPR disclosures file for this document or to the RFC 2898
document:

https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-josefsson-pbkdf2-test-vectors
https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=2898

One obvious concern with a document like this would be that if there is
SHA-1 test vectors, it should also contain test vectors for SHA-2.
However, RFC 2898 does not specify any OIDs for non-HMAC-SHA-1 hashes,
and to my knowledge there is no usage of PBKDF2 with SHA-2.  Thus,
publishing test vectors at this point 1) does not help anyone because
there is no implementations available, and 2) it would be hard to get
good confidence in SHA-2 test vectors because there are no usage and
implementers.  Thus I think it is premature to add SHA-2 to this
document.

One could drive an update of RFC 2898 in parallel to add SHA-2 OIDs,
although I'm not certain there is demand for it.  There are no known
attacks on PBKDF2-HMAC-SHA1.

    (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand
          and
          agree with it?

It is not a WG document, but there are several implementers who have
been helped by this document and others who have reviewed it.  I believe
most people agree with the need for a document like this even if they
didn't take time to double check the test vectors themselves.

    (1.f)  Has anyone threatened an appeal or otherwise indicated
          extreme
          discontent?  If so, please summarize the areas of conflict
          in
          separate email messages to the Responsible Area Director.
          (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

None to my knowledge.

    (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks
          are
          not enough; this check needs to be thorough.  Has the
          document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

I have gone through these lists and checked everything.  Some acronyms
(HMAC and SHA-1) were not expanded on first usage in -02, but I've fixed
that for -03.  PKCS is expanded in the abstract and introduction, but
not in the document title, for consistency with RFC 2898 and to avoid
making the title too long.

    (1.h)  Has the document split its references into normative and
          informative?

Yes.

          Are there normative references to documents that are not
          ready for
          advancement or are otherwise in an unclear state?  If such
          normative references exist, what is the strategy for their
          completion?  Are there normative references that are
          downward
          references, as described in [RFC3967]?  If so, list these
          downward references to support the Area Director in the Last
          Call procedure for them [RFC3967].

The only non-RFC is NIST's SHA-1 document.  I believe it is cited by
many other RFCs already.

On reading -02, i think both HMAC and SHA-1 has to be normative
references.  I have fixed this in -03.

    (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the
          body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If
          the
          document describes an Expert Review process, has the
          Document
          Shepherd conferred with the Responsible Area Director so
          that
          the IESG can appoint the needed Expert during IESG
          Evaluation?

No IANA action is necessary.

    (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly
          in an automated checker?

No formal language is used by the document.

    (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary

This document contains test vectors for the Public-Key Cryptography
Standards (PKCS) #5 Password Based Key Derivation Function 2 (PBKDF2)
with the Hash-based Message Authentication Code (HMAC) Secure Hash
Algorithm (SHA-1) pseudorandom function.

          Working Group Summary

This is not the product of a WG.

          Document Quality

There are at least four known implementations that confirmed these
test vectors.

          Personnel

Simon Josefsson is the Document Shepherd .
Sean Turner is the sponsoring Area Director.