On Jan 24, 2009, at 1:29 PM, Robert J. Hansen wrote:
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.
Why do Twofish, Blowfish, etc, need to be removed? Mind you, I don't
care very much if they are, but we're drifting away from the "what to
do about new algorithms" question, to the "what do we do with old
algorithms once their useful life has passed" question. Who do these
algorithms hurt? Remember - they're all optional, all still
considered strong, and we have a robust system for choosing algorithms
so that nobody is ever forced to use them.
OpenPGP inherited some algorithms from PGP 5, before there was a
standard. All of these algorithms were grandfathered in. Some others
were added because people needed them. If I recall, Twofish was added
to the spec before AES was finalized. Twofish has a block size of 128
bits, which was needed, and at the time, no other ciphers in the
standard had that block size.
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.)
Adding new algorithms has nothing whatsoever to do with removing old
ones. If Camellia is useful and needed, it is useful and needed
whether (say) Blowfish exists or not. If someone wants to pursue
removing Blowfish, go right ahead, but they mustn't expect all forward
momentum to stop while the removal is discussed. This is not an
algorithm swap.
Again, though: we have the means for people to remove the "cruft" on
their own. I don't see people doing it. One user's cruft is another
user's vital part of the system.
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."
Who are the "others"? Who is "people"? Implementers aren't
confused. We all know how to read a standards document. The RFC
isn't meant for end users. If the goal was a user manual, that's a
different document.
As simple as we tend to think MUST, MAY, SHOULD, etc., are, Management
is often not capable of understanding those words.
Management is not the target of a message format document, and we
cannot redefine how the thousands of RFCs are written just for them.
You can't make everyone happy with the same document, and trying is
frequently a fool's errand.
David
_______________________________________________
Gnupg-users mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
