Rich Salz wrote:
To be algorithm independant, you make sure you always identify the algorithm,
and don't mistakenly say "encrypted data" without specifying the mechanism.
During development of the standards, a good way to do that is to make sure
multiple mechanisms are specified. In this case, the theoretical (DSA) and the
practical (RSA).
I had the sense that what Dave was alluding to was something more. It sounds
like
an algorithm independent infrastructure, or maybe a multi-algorithm
infrastructure
is a better way to say it. (Dave, I don't want to put words in your mouth, but
it
seemed to me this is what your 11/28 message was saying.) This strikes me as a
good idea from a robustness point of view as has already been stated. It seems
like we're saying on the one hand that this is a good idea, yet on the other
that
everybody building to a lowest common denominator is all we're willing to do.
That seems a little disconnected to me.
Peter Gutman said it best a few weeks ago, shortly after RSA expired.
Something along the lines of "we all pretended to do DSA, but in reality
everyone did RSA." For political reasons, the IETF bent over backwards to
avoid mandating patented technology.
I missed this statement the first time around, but I think it's probably
accurate. However, consider just what it says about IETF's overall impact on
industry. I think we take the whole MUST/SHOULD/MAY debate way too seriously.
Industry does what it wants.
Personally, I favor products that support LOTS of interoperability modes.
That's nonsensical. Do you prefer BER over DER? :)
For some things, yes. It's better for one-pass processing for instance.
The marketplace has decided and the common crypto mechanism is RSA, and
practically nobody cares about DSA. Certainly, making DSA not MUST will not
hurt the DSA-using community.
It's not the IETF's job to raise the bar. It's the IETF's job to make sure we
all speak the same language, and clearly that language is mod-exp.
/r$
I agree on these points.
Cheers,
Chris B.