The Camellia Cipher in OpenPGP
draft-ietf-openpgp-camellia-04

[Ballot discuss]
Lars has suggested to upgrade my comment to DISCUSS:

The document header says:

  Intended status: Standards Track

but the ballot says it is Informational. I think the ballot is correct and I hope this is fixed before the document is published as an RFC.

[Ballot comment]
The document header says:

  Intended status: Standards Track

but the ballot says it is Informational. I think the ballot is correct and I hope this is fixed before the document is published as an RFC.

IANA comments:

Upon approval of this document, IANA will make the following
assignments in the "Symmetric Key Algorithms" registry at
http://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml

ID | Algorithm | Reference
TBD-1 | Camellia with 128 bit key | [RFC-openpgp-camellia-04]
TBD-2 | Camellia with 192 bit key | [RFC-openpgp-camellia-04]
TBD-3 | Camellia with 256 bit key | [RFC-openpgp-camellia-04]

We understand the above to be the only IANA Action for this document.

Proto writeup

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

Derek Atkins
Yes

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

Yes, the document was posted and commented on the openpgp mailing
list with no dissenting responses.  I believe all the key players
had a chance to review the document.

  (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, I have 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.

The only concern is whether the document should be a Proposed Standard
or Informational RFC.  One normative reference (the Camilla Cipher)
is only published as Informational.  The IANA Registries involved
are all based on IETF Review so there is no need to publish as
Proposed Standard.  However this document was taken on as a working
group work item prior to the OpenPGP WG being shut down.

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

More the former than the latter, but the document is just asking for
an IANA Number to enable OpenPGP to use the Camilla cipher.  There was
no dissent about the contents of the draft, even though there was a
(relatively) significant amount of discussion on the list about what
key and block sizes to support.

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

It passed all the nits from when it was submitted.  The nits requirements
have changed since then and it no longer passes all the nits.  In particular
there is a warning about boilerplate and copyright year, and a complaint
about the downref for the camilla cipher.

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

No, there are only normative references to three documents.
There is a downref to Informational RFC 3713

  (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
    [I-D.narten-iana-considerations-rfc2434bis].  If the document
    describes an Expert Review process has Shepherd conferred with the
    Responsible Area Director so that the IESG can appoint the needed
    Expert during the IESG Evaluation?

Yes, the IANA Considerations section is fine.

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

N/A

  (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 presents the necessary information to use the Camellia
  symmetric block cipher in the OpenPGP protocol.

    Working Group Summary

  There was no contention about including the cipher.  The working
  group discussion mostly focused on the set of key sizes to support.
  But in the end I believe that consensus was achieved for the set
  included in the document.

  This document was part of the OpenPGP Working Group and was a
  Work Item of that group prior to the WG being shut down.

    Document Quality

  This document is short, sweet, and to the point.  Its main goal is
  the allocation of three cipher types from the OpenPGP number space.
  It provides ample guidelines for when to use the cipher within
  OpenPGP and has a Normative Reference to the definition of the
  Cipher for implementers to use.