A question about Camellia

[Robert J. Hansen]

David Shaw wrote:
> But then, once we have algorithm agility, that means we must have a 
> means for dealing with that agility (preference lists being the
> defined OpenPGP mechanism for that).  And then, having such means,
> why do we care all that much whether an algorithm is present or not?

To quote one of the best, most promising, and most vastly underused,
statements in engineering:

Hmm.  I need to think about that...

> Do we want to add every cipher that comes down the pike?  Certainly 
> not.  Do we want to add well designed ciphers that have strong
> evidence behind them?  Maybe, but still, why bother?   We have that
> already.  Do we want to add well designed ciphers with strong
> evidence behind them that people actually want to use (as opposed to
> the oft-heard "Yeah, it would be neat if OpenPGP had the new BLAH-256
> cipher")?  Sure we do.  Or at least, I do.

This doesn't explain Twofish, Blowfish, RIPEMD160, etc., etc.  These are
well-designed algorithms that very few people use, and they're still
littering the standard.  I don't think it's at all unreasonable to say
"Camellia has users supporting it, sure, but before we go about adding
new algorithms, let's prune out old ones."  The cruft needs to be
removed, and I don't see the WG addressing the problem.  (I'm on the WG
mailing list, although I rarely speak up there.)

> I think the 4880 language here is very clear:  you MUST support 3DES
> (the protocol requires it), you SHOULD support AES and CAST5 (we
> recommend this, but you're free to disagree, and the protocol will
> work just fine either way), and you MAY support anything else you
> like (i.e. completely optional, do what you like).

Clear to you, yes.  Clear to me, yes.  It seems that it is not clear to
others.  People say "well, CAST5 is in the RFC, so I'll use it," not
"well, CAST5 isn't a MUST, so I shouldn't depend on it being present."

> My understanding is that you do not favor Camellia in OpenPGP

I favor it being defined for the people who need it.  I also favor
putting in forty-eight-point boldface type "don't depend on other people
supporting this because they probably won't and it's probably a good
idea not to support it unless you have a pressing need."

You say this is already conveyed by the fact it's optional.  I disagree.

> How?  You don't think they'd have just asked for all of the
> algorithms in "Appendix A" rather than "Section 9.2" ?

My counterargument of, "it's a conformant implementation that matches
all the MUSTs of the RFC, that's what I said I'd do, that's what I did,"
fell on deaf ears.  After all, how could be be a conformant
implementation if it didn't have double-width SHA or HAVAL?  They're
right there in the spec, after all.

If I had said, "I have total coverage of the entire spec, the appendices
are optional, that's why they're in appendices," I think it would have
gone over better.  However, counterfactuals being historical fiction, I
can't definitively say it would have helped, only that I think it would
have.

As simple as we tend to think MUST, MAY, SHOULD, etc., are, Management
is often not capable of understanding those words.