Re: Ready for Camellia?

David Shaw wrote:
> On Wed, Mar 12, 2008 at 01:29:49PM -0400, Derek Atkins wrote:
> > David Shaw <dshaw(_at_)jabberwocky(_dot_)com> writes:
> >
> > [snip]
> > > I think that is just fine, and thanks for working this out.
> > >
> > > I have a minor process question though: I've done a couple of Camellia
> > > drafts as "draft-ietf-openpgp-camellia".  Do I need to convert that to
> > > "draft-shaw-openpgp-camellia" (i.e. an individual submission) and
> > > re-submit?
> > No, it can stay as 'draft-ietf-openpgp-'.  No need to rename and
> > resubmit as an individual.
> Great, thanks.
>
> 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 just skimmed it.

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.
It would be nice if we could agree on a more unified way of 
treating this.
Personally I prefer the ECC style, as it allows for some 
richness within.  However, there should be a line at the top 
of the document describing the relationship to the mother 
document.  Something like:
   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.


> I would particulary appreciate comments on the choice of 128 and
> 256-bit keys (that is, lacking 192).  I tend to agree with Jon that
> 192 is neither here nor there, but I'm also a major fan of
> consistency.  If we're going to include 192 for the ECC work, then
> it's odd to leave it out here.

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.
The sensible reason for including 192 in ECC was outlined by 
Jon.  There are checkboxes that big corps and big TLAs 
follow when buying this stuff.  They do not understand what 
they are doing, they simply tick boxes (by definition, as if 
they knew what they were doing, they wouldn't have boxes to 
tick).  In that world, you need to have the checkboxes.
However, no case has been made that Camellia is in that 
world.  Camellia is not on Suite B, it isn't going to win 
any USG sales.  So it doesn't need the checkbox, and we can 
revert back to our own judgement.
The rough consensus in this group today (that I see) is that 
we are aiming at two markets at once, being the 
"small/mobile" and the "big/secure" sectors.  Which means 
the biggest and the smallest:  128 + 256.


iang

PS: That rough consensus is what *I* see here today.  Others 
might view it differently!