Jon Callas wrote:
On 27 Mar 2006, at 7:44 AM, Daniel A. Nagy wrote:
I agree with David here. The standard's purpose is to ensure
interoperability. It should tell us the sematics behind sequences of
bytes.
It is up to the implementation to make decisions based on these
semantics.
Valid reasons to exclude certain combinations from the standard include
ambiguity of interpretation, inherent insecurity or a wide installed
base of
incompatible implementations, but not the possibility of weird uses,
IMHO.
I agree as well with both Davids.
Well, I can see I've lost the consensus battle on
this one - but I would propose that the purpose of
the ID is security, over and above interoperability,
and that is an entirely valid reason to exclude
"Weird Uses."
In general, with security, the less choice the better.
As an observation, in 2440 one of the things we allowed was deviation
from DSS because the rough consensus had a certain amount of grumpiness
with the US Government. In practice, hardly anyone did anything
different with DSA than DSS. We even removed hash functions.
Many things have changed in the last decade, but toeing the exact NIST
line or even being like them only moreso is going a bit too far. In the
next decade, we're going to see a lot of advancement in hash functions.
Someone is going to want to use those new hash functions with DSA, and
it would be nice to be able to move faster than NIST.
As to the political circumstances of the past, it is
true that the community did certain daft things that
reduced security in response to the USG's own set of
daft things that reduced security. It's definately
not good to follow either lead...
Let's suppose someone comes up with a new hash function that is 251
bits. (I picked 251 because it's prime and less than 256.) We don't
want a constitutional crisis over using it. We want to be flexible
enough that it's pretty obvious how to extend OpenPGP to use new hash
functions with DSA.
It seems that PGP's design bends over backwards
to be flexible. It's a lot of fun for crypto-
plumbers; in fact it looks like it has been
designed as a toykit for programmers to muck
around with algorithms.
In practice, though, this flexibility seems to
rarely be used in any sensible way.
And, again, in practice, this flexibility causes
endless discussions on this mailgroup - as seen
this week - and other places where implementors
and users try and figure what goes with what.
It all takes up time from other important things.
So I guess what I'm saying is ... all this
flexibility ... how many times has it been used
to advantage, and how many times to disadvantage?
What's the cost-benefit analysis here?
iang