On Mar 18, 2008, at 9:00 AM, Ian G wrote:
Jon Callas wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
As much as I think that 192-bit encryption is stupid, many people
have impressed upon me reasons it exists, none of which are
technical.
I grit my teeth and hold my nose as I say this, but we have to have
it.
I can understand this for Suite B because there is a defined and
controlled market for it, so the non-technical domain does rule.
But for Camellia? As far as I can see this is a boutique algorithm
that someone is adding for the love of it.
Well, ok, so if it is in, how does it go in?
Is it possible to put 192-bit encryption in under some sort of
"COMPLIANCE-ONLY" label that means that you should only implement
this is if you've moved out of the technical domain?
E.g., something below MUST, SHOULD, MAY, that suggests there are
issues here which are well outside the spec.
That overloads additional semantics into the simple and elegant RFC
keyword system. We already have a concept of "You don't have to do
this. The spec doesn't require it. If you do choose do to it,
however, do it like this." That's MAY. We don't need another way to
say the same thing.
David