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

On 03/08/2012 04:58 PM, Jeffrey Hutzelman wrote:
> Points 1, 2, 5, 6, and 7 are blockers; they must be resolved before
> the document can progress.

I believe all points are taken care of in -01, but some may need
confirmation.

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

We have an implementation, awaiting enctype and cksumtype assignments
before becoming part of the default build.  It was, of course, used to
generate the test vectors, so can't be used to verify them.  The
Camellia implementation is off-the-shelf (with off-the-shelf tests) and
the CMAC implementation was verified against RFC 4493 test vectors using
AES as the cipher.

> 2. The IETF Trust copyright and license notice in this document is out
>    of date

I believe I resolved this by updating and re-running xml2rfc, but I
could only detect a one-word difference, so I'm not 100% certain.

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

I added the text, "To separate the ciphertext into C and M components,
use the final final 16 bytes for M and all of the preceding bytes for C."

> 5. The IANA considerations [...]

I moved the Assigned Numbers table into the IANA considerations section
and reworked it to match the registry, as described in RFC 5226.  I also
removed the notes to the RFC editor, since I think it can all be taken
care of in the IANA step.
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg