Re: RSA vs. DSA MUST

["Bonatti, Chris" <BonattiC@xxxxxxxx>]

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.