Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm
draft-housley-aes-key-wrap-with-pad-04

[Ballot discuss]
Section 7 describes one way how to handle wrapped keys shorter
than 9 octets as an example. Why is this just an example, and
not part of the actual specification in Section 4?

(I'm not sure, but e.g. the work in KEYPROV WG might need less
than 9 octets when the thing wrapped is a PIN of some kind.)

[Ballot discuss]
Section 7., paragraph 5:
>    A previous padding technique was specified for wrapping HMAC keys
>    with AES [OLD-KW].  The technique in this document is preferred, and
>    the technique in this document is not limited to wrapping HMAC keys.

  DISCUSS: I might be missing something, but RFC 3537 is PS and it's not
  being obsoleted by anything. How is it appropriate to say that the
  technique described there is no longer preferred?

[Ballot comment]
INTRODUCTION, paragraph 12:
>    This document specifies a padding convention for use with the AES Key
>    Wrap algorithm specified in RFC 3394.

  RFC 3394 not cited.

[Ballot comment]
I may be wrong, but I suspect that the RFC Editor will point out that you have code fragments in this I-D and need to include a BFD license. But, anyway, that is an issue that you will have to resolve in Auth48 if it still remains a requirement.

Document Shepherd Write-Up for draft-housley-aes-key-wrap-with-pad-02.txt

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

  Russ Housley is the Document Shepherd and co-author.


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

  The document is intended for publication as an Informational RFC.
  It has been reviewed by several experts.  No concerns about the
  algorithm were raised.  All concerns regarding clarity have been
  addressed.  There are no concerns about the depth or breadth of
  the reviews.


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

  No concerns.


(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 interested community has discussed those issues and has
  indicated that it still wishes to advance the document, detail
  those concerns here.

  No concerns.


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

  This document describes a cryptographic algorithm.  The experts
  have not raised any concerns with the algorithm.


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarise 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.)

  No.


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

  Yes; however, ID-Nits reports minor isses.  These issues will be
  corrected in the next draft, which will also address any comments
  raised in AD Review and Last Call.  In addition, ID-Nits reports
  issues that are not really problems:

    = Found possible IPv4 address '2.2.3.2' in position 4; this
      doesn't match RFC3330's suggested 192.0.2.0/24 address range.

      It is not an IP address; it is a reference to section 2.2.3.2.

    = Missing IANA considerations section.

      No IANA actions are needed.  One will be added prior to IETF
      Last Call to ensure there is not confusion.

  There is no need for any formal review from the MIB Doctors or any
  other such group.


(1.h)  Has the document split its references into normative and
  informative?  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].

  References are split.  No Internet-Drafts are referenced.


(1.i)  Has the Document Shepherd verified that the document IANA
  consideration 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 suggested a reasonable name for the new registry?  See
  [RFC5226].  If the document describes an Expert Review process has
  the Shepherd conferred with the Responsible Area Director so that
  the IESG can appoint the needed Expert during the IESG Evaluation?

  No IANA actions are required.


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

  Reviews indicate that the pseudocode is clear.

  ASN.1 object identifiers are specified in the body of the document.


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

  Technical Summary

    This document specifies a padding convention for use with the
    AES Key Wrap algorithm specified in RFC 3394.  This convention
    eliminates the requirement that the length of the key to be
    wrapped is a multiple of 64 bits, allowing a key of any
    practical length to be wrapped.

  Working Group Summary

    This document is not the product of any IETF working group.

  Document Quality

    Expert reviews have not found any concerns.