There are two separate issues here:
1. Proprietary nature of the algorithm
and
2. Key length of 40 bit
One argument says, 'No RC2 at any length' key because it's owned by someone
charging some type of royalty. Don't care if it's 128 bit RC2, it's still RC2.
The other argument is, 'Don't want no weak crypto'. Don't care if you're
talking CAST(_at_)40, DES(_at_)40, RC2(_at_)40 or ROT13. This is the 'US
export' problem.
The answer is simple, Let's have strong open algorithms !
-------------------
At 04:18 PM 4/17/97 -0700, you wrote:
At 3:45 PM -0700 4/17/97, Steve Dusse wrote:
If there is agreement, then I
will stand by my earlier conviction; the goals of the IETF are out of
step with US companies' business needs.
I disagree strongly with your wording. There is no "need" for expidited
export of a product; there is a strong desire. To be more specific, there
is a strong desire for a small number of companies (mail client
manufacturers) for expeditied export.
There is a strong need for strong cryptography in all US companies for
their messaging. This is why RSA included tripleDES in the original S/MIME
spec. Thus, the goals of the IETF are exactly step with US companies'
business needs, with the exception of a few companies.
As such, we should find a way
to separate the non-business protocol portions of the S/MIME spec from
the US business-needs-centric profiling information.
Again, I disagree with your wording. In my mind, a better way to say this
is "we need a spec that meets US companies' business needs, and we need to
also at least acknowledge the strong desires of US mail client vendors."
Further, I'd like to point out to the group as a whole that just because
other countries don't have export controls today, they might tomorrow. The
lame ideas of the US government are often imported gleefully by other
governments. Thus, the 40-bit crypto problem is temporarily US-only. It
could go away in the US, it could appear in other major software-exporting
countries, or both.
--Paul E. Hoffman, Director
--Internet Mail Consortium