Re: Ready for Camellia?

[David Shaw <[e-mail]>]

On Fri, Mar 14, 2008 at 03:04:13PM +0100, Ian G wrote:
>> I think we're ready for the final push on Camellia.  All of the
>> suggested changes have been incorporated, and if folks could give it a
>> final read, I'd appreciate it:
>>   http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-01.txt

> I am confused about one language difference between Camellia doc and ECC 
> doc.  In Camellia, there are MAYs.  In ECC, there are MUSTs, SHOULDs, MAYs.
>
> The way I interpret it, Camellia is *incorporated within* RFC4880 and adds 
> MAY algorithms.  But ECC is *appended as a MAY* ... the entire appendix is 
> a MAY, within which there are choices guided by RFC2119.
>
> Maybe I'm wrong about my interpretation, and if so, stop reading here.

I disagree with that interpretation.  There is nothing special about
Camellia here.  Both Camellia and ECC are the same: new RFCs that
specify new functionality.  Whatever they may specify, they can only
specify that in regards to themselves.

>    This document is an optional appendix to [RFC4880] which
>    makes the entire Camellia addition a MAY.  If you do add
>    Camellia then you must follow the recommendations below
>    using the normal language of [RFC2119].
>
> OK, that's really crappy language but I hope you get the idea.

The draft more or less says that:

   OpenPGP applications MAY implement Camellia.  If implemented,
   Camellia may be used in any place in OpenPGP where a symmetric
   cipher is usable, and is subject to the same usage requirements
   (such as its presence in the Preferred Symmetric Algorithms
   signature subpacket) as the other symmetric ciphers in OpenPGP.

Note that the whole draft has only one "MAY" (and no MUSTs, SHOULDs,
etc) with regards to Camellia.  That is appropriate for a simple
algorithm RFC.  It's "you MAY implement this, but doing so doesn't get
you out of the various MUSTs and other rules from 4880."

> I agree with dropping 192.  I see no consistency argument here, the notion 
> of having consistent sets across algorithms seems esthetic only.  Real 
> users won't understand these notions of esthetics.

I just thought of another reason to leave Camellia-192 out: if we
leave it out and then change our minds, it's pretty easy to add it
later (just write a tiny RFC and get an algorithm number for it).  If
we do put it in now and then change our minds, it's nearly impossible
to get rid of it later.

David