The reason only 256-bit keys were proposed was due to
Hironobu SUZUKI's initial request:
http://www.imc.org/ietf-openpgp/mail-archive/msg15591.html
key-length discussions happened here:
http://www.imc.org/ietf-openpgp/mail-archive/msg15674.html
http://www.imc.org/ietf-openpgp/mail-archive/msg15677.html
http://www.imc.org/ietf-openpgp/mail-archive/msg15678.html
http://www.imc.org/ietf-openpgp/mail-archive/msg15679.html
the final message likened the situation with only 256-bit key
Twofish.
HOWEVER, in addition to Daniel's technical comment in:
http://www.imc.org/ietf-openpgp/mail-archive/msg20265.html
I personally wonder if we also should take this opportunity
to add a 128-bit key+length alternative to AES in OpenPGP,
just because there currently isn't one.
One could argue about adding 128-bit Twofish as well/instead,
as it's been around longer and also went through the deep AES
process scrutiny. However, on Camellia's side, it is a post-AES
cipher, and so benefits from more recent insights / design
trade-offs, PLUS it has gone through the scrutiny of both
NESSIE and CRYPTREC. In addition it's already implemented
(in both 128-bit and 256-bit lengths) in applications (e.g. the
Linux kernel and Firefox 3.0 [beta]).
One outstanding question I see: have we ever had a reply back
from NTT giving an IPR statement SPECIFICALLY for OpenPGP, as
requested by Hironobu SUZUKI here?
http://www.imc.org/ietf-openpgp/mail-archive/msg15676.html
This was intended to clarify the general statement given here:
http://www.imc.org/ietf-openpgp/mail-archive/msg15607.html