review of draft-ietf-krb-wg-camellia-cts-00.txt

Below is my review of the Camellia document.  These are all editorial
and process issues, and I would like to see all of them resolved before
we move on.  Points 1, 2, 5, 6, and 7 are blockers; they must be
resolved before the document can progress.

I would like to hear from any implementors who plan to implement
this enctype or who have already done so, as well as from anyone
who has verified the test vectors in section 11.

-- Jeff


1. The document header does not include an intended status.  Since we
   have not yet seen consensus to request publication on the standards
   track, please add "Intended Status: Informational" to the document
   header.

   The abstract should include an explicit mention of RFC3961 (but
   without a citation, since the abstract must stand alone).  For
   example:

   OLD
     This document specifies two encryption types and two corresponding
     checksum types for the Kerberos cryptosystem suite.  The new types
     use the Camellia block cipher in CBC-mode with ciphertext stealing
     and the CMAC algorithm for integrity protection.

   NEW
     This document specifies two encryption types and two corresponding
     checksum types for the Kerberos cryptosystem frameworkd defined
     in RFC3961.  The new types use the Camellia block cipher in CBC
     mode with ciphertext stealing and the CMAC algorithm for integrity
     protection.


2. The IETF Trust copyright and license notice in this document is out
   of date, and must be updated to reflect the current version of the
   Trust Legal Provisions, which went into effect Dec 28, 2009.  See
   http://trustee.ietf.org/license-info/ and particularly section 6.b
   of the current (4.0) TLP.


3. The last paragraph of the introduction incorporates requirements
   keywords from RFC2119 by reference, but then does not use them.
   This paragraph should be removed.


4. In section 6, the description of the decryption operation does not
   spell out how separate the MAC and ciphertext parts of the incoming
   "ciphertext".  It also does not specify how to remove the confounder
   from P to obtain the actual plaintext.  These operations should be
   obvious, but it's better to be specific.


5. The IANA considerations section should fully identify the namespace
   into which each value is registered, preferably not only by name
   but also including a URL to the registry and a mention of RFC3961
   where the registries are defined.  Also, this section should list
   each value to be assigned and give each a unique reference (TBD1,
   TBD2, etc); those references should be used instead of plain "TBD"
   in the rest of the document, in order to aid the RFC-Editor in
   making the correct substitutions.  For more details, please see
   RFC5226 section 5.1.


6. References must be split into separate sections for normative and
   informative references.  So far as I can tell, the references to
   RFCs 3713, 3961, and 3962 and to NIST special pubs 800-38B and
   800-108 are all normative, while the references to Schneier's book
   and to the IPA and Mala, et.al. papers and the NESSIE project are
   all informative.  This document contains no RFC2119 requirements
   language, so the reference to RFC2119 is not needed.


7. There is no section acknowledging authors and other contributors to
   this document.


_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg